CISA SBOM Minimum Elements

CISA's 2026 Minimum Elements for a Software Bill of Materials define seventeen data fields every SBOM should carry: nine describing the document, eight describing its components. kunnus writes sixteen of them. The seventeenth is the author's digital signature, which is less a value to fill in than a property the finished document has to have — it must be signed and verifiable. This page is the field-by-field account, and how to get that last property.

The 2026 revision is a substantial update to the 2021 NTIA elements: ten fields are new, including the author signature, the data format name and version, the generation context, the tool name and version, component hashes and component licences. Four more were materially clarified. The list below follows CISA's own grouping, document level first.

Document-level fields

• SBOM Author — the entity operating the scanner. From --author (env KUNNUS_AUTHOR); lands in metadata.authors and metadata.manufacturer. Unset, the document carries a placeholder and the CLI warns.
• SBOM Author Signature — not written by the scanner. Sign the finished file; the recipe is below.
• SBOM Data Format Name and Version — CycloneDX and 1.6, recorded in the document itself. No flag.
• SBOM Generation Context — metadata.lifecycles: pre-build for sbom repo (source analysis, before anything is built), post-build for sbom os and sbom container (analysis of a built artifact). The scan mode decides; no flag.
• SBOM Timestamp — metadata.timestamp, the moment the document was generated.
• SBOM Tool Name and Version — both kunnus and the linked osv-scalibr appear under metadata.tools, each with its own version, so a consumer can tell which engine produced which claim.
• SBOM Version — the document version. For members of a serial-number series it is the generation timestamp in epoch seconds, which orders rescans without the scanner keeping state.

Component-level fields

• Component Name and Version — from the extractor that found the package. A component with no version carries an explicit unknown marker rather than a guess.
• Component Producer — the supplier, derived for every ecosystem in the corpus. Vendored C/C++ copies deliberately carry none: a local vendored directory has no upstream supplier to assert.
• Component Identifiers — a package URL, plus a CPE where one is derivable. Kernel modules are backfilled with pkg:generic purls so no component ships without a machine-processable identifier.
• Component Hash Algorithm and Value — from lockfile digests, OS package databases, the chisel manifest, and a SHA-256 of the file itself for classifier-detected binaries.
• Component License — normalized to SPDX from offline package data; --online-licenses fills the remaining gaps via deps.dev.
• Component Dependency Relationship — real edges mined from six lockfile formats into dependencies[], with compositions[] declaring the graph incomplete where no lockfile pins it.

Explicitly identifying unknown information

Beyond the data fields, CISA asks an author to state that a value is unknown rather than silently omit it. CycloneDX 1.6 has no native field-level marker, so kunnus stamps kunnus:unknown:producer, kunnus:unknown:version, kunnus:unknown:hash and kunnus:unknown:license on any component still missing that field after every enrichment stage has run. A marker always means unknown to the SBOM author, never known-but-redacted — kunnus withholds nothing. The root component is exempt: its identity is your statement, made through the identity flags.

Signed and verifiable: the SBOM Author Signature

This element is not really a value the scanner could compute: CISA describes it as a place for the author to include information giving the recipient assurance that the SBOM is as the author created it, and says implementation should use existing software signing infrastructure, tools and key management. A scanner holds none of your keys, so kunnus signs nothing and rolls no crypto of its own. Sign the emitted file with a keyless cosign signature instead — the bundle travels next to the SBOM.

cosign sign-blob --yes \
  --bundle sbom.cdx.json.sigstore.json \
  sbom.cdx.json

cosign verify-blob sbom.cdx.json \
  --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity-regexp '^https://github.com/acme/widget/.github/workflows/release.yml@refs/tags/v.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

In GitHub Actions the same thing can ride along as an artifact attestation, which stores a Sigstore-signed in-toto statement against the artifacts the SBOM describes:

- uses: actions/attest@v4
  with:
    subject-path: dist/widget_linux_amd64.tar.gz
    sbom-path: sbom.cdx.json

Consumers then verify with gh attestation verify <artifact> -R <owner>/<repo> --predicate-type https://cyclonedx.org/bom. kunnus-scanner's own releases work exactly this way: every release carries a CycloneDX SBOM of the released source tree with a detached cosign bundle, attested against the archives and packages it describes. One honest caveat: a detached bundle signs the document from outside rather than filling a signature block inside it. That is how signing is normally done and it delivers the assurance the element exists for, but a consumer who insists on an in-document signature will not find one today.