Supplier SBOM Requirements

These are requirements on our suppliers. Without them, no tool — OCSA included — can produce a defensible verdict, because the missing data cannot be reconstructed downstream.

Put them in the supplier quality agreement. They are listed here in a form you can paste.

#	Requirement	Rationale
S-1	SPDX 2.2 or 2.3 JSON	Format baseline
S-2	licenseConcluded populated, not NOASSERTION	The only field that carries a legal conclusion
S-3	purl in externalRefs for every package	Stable identity across releases; enables enrichment
S-4	STATIC_LINK / DYNAMIC_LINK relationships	The LGPL verdict depends entirely on linkage
S-5	hasExtractedLicensingInfos for every LicenseRef-	Otherwise custom licenses are unreadable
S-6	filesAnalyzed: true with licenseInfoFromFiles	Catches per-file license divergence
S-7	creationInfo.creators and created	NTIA minimum elements
S-8	One SBOM per distributed unit (executable / ECU image), not per repository	Copyleft is assessed per shipped artefact

:::danger S-8 is the one most often missed Suppliers naturally produce one SBOM per repository, because that is what their tooling emits. But copyleft attaches to the shipped work. A repository-level SBOM has no notion of what ended up in which binary, so propagation and compatibility cannot be assessed correctly. Insist on one SBOM per executable or ECU image. :::

Element-by-element reference

SPDX element	Required	Used for
spdxVersion, name, creationInfo	Yes	Document identity, NTIA-6/7
packages[]	Yes	Component inventory
packages[].licenseConcluded	Preferred	Primary license source
packages[].licenseDeclared	Fallback	Secondary license source
packages[].licenseInfoFromFiles	Fallback	Tertiary source
packages[].externalRefs (purl)	Strongly preferred	NTIA-4, stable cross-release identity
packages[].checksums	Preferred	AUD-1
packages[].copyrightText	Preferred	AUD-3, LIC-008, NOTICE file
packages[].downloadLocation	Preferred	AUD-2
packages[].supplier	Preferred	NTIA-1, supplier inquiry
relationships[]	Yes	Dependency graph, NTIA-5
relationships[].relationshipType	Strongly preferred	AUD-5, propagation verdict
hasExtractedLicensingInfos[]	Yes when LicenseRef- is used	LIC-004
documentDescribes	Preferred	Root / distributed unit identification

What happens when they are not met

OCSA does not refuse to analyse an incomplete SBOM — it analyses it and tells you the evidence is weak. Concretely:

Missing	Consequence
licenseConcluded	Falls back to declared, then to from-files; licenseSource records which was used
purl	Identity falls back to lowercased name; renamed components look like add + remove
Linkage	Assumed static — over-reports copyleft reach, every finding says so
hasExtractedLicensingInfos	The custom license is unreadable; LIC-003 fires as a release blocker
filesAnalyzed / licenseInfoFromFiles	Per-file divergence is invisible; declared license is taken at face value

Every one of these degrades confidence rather than producing a wrong number, which is the point: a compliance tool should fail loudly towards more caution, never towards less.

Closing the loop

The inquiry command drafts the letter: numbered items, each with a blank for the supplier's response. Use it at intake, before the milestone review — not after.