CISA-SBOM-Mindestangaben

Die CISA-Mindestangaben für eine Software Bill of Materials (Fassung 2026) definieren siebzehn Datenfelder, die jede SBOM tragen sollte: neun beschreiben das Dokument, acht seine Komponenten. kunnus schreibt sechzehn davon. Das siebzehnte ist die digitale Signatur des Autors — weniger ein einzutragender Wert als eine Eigenschaft, die das fertige Dokument haben muss: Es muss signiert und verifizierbar sein. Diese Seite geht Feld für Feld durch und zeigt, wie diese letzte Eigenschaft dazukommt.

Die Fassung 2026 ist eine deutliche Überarbeitung der NTIA-Mindestangaben von 2021: Zehn Felder sind neu, darunter die Autorensignatur, Name und Version des Datenformats, der Erzeugungskontext, Name und Version des Werkzeugs sowie Komponenten-Hashes und -Lizenzen. Vier weitere wurden inhaltlich präzisiert. Die folgende Liste folgt CISAs eigener Gliederung, Dokumentebene zuerst.

Felder auf Dokumentebene

• SBOM Author — die Organisation, die den Scanner betreibt. Aus --author (Env KUNNUS_AUTHOR); landet in metadata.authors und metadata.manufacturer. Ohne das Flag trägt das Dokument einen Platzhalter, und die CLI warnt.
• SBOM Author Signature — wird vom Scanner nicht geschrieben. Das fertige Dokument wird signiert; das Rezept steht unten.
• SBOM Data Format Name und Version — CycloneDX und 1.6, im Dokument selbst verzeichnet. Kein Flag nötig.
• SBOM Generation Context — metadata.lifecycles: pre-build bei sbom repo (Quellcode-Analyse, vor dem Build), post-build bei sbom os und sbom container (Analyse eines gebauten Artefakts). Der Scan-Modus entscheidet; kein Flag.
• SBOM Timestamp — metadata.timestamp, der Zeitpunkt der Erzeugung.
• SBOM Tool Name und Version — sowohl kunnus als auch das eingebundene osv-scalibr stehen unter metadata.tools, jeweils mit eigener Version. So ist erkennbar, welche Engine welche Aussage erzeugt hat.
• SBOM Version — die Dokumentversion. Für Mitglieder einer Seriennummern-Serie ist das der Erzeugungszeitstempel in Epoch-Sekunden, wodurch Rescans ohne gespeicherten Zustand geordnet bleiben.

Felder auf Komponentenebene

• Component Name und Version — aus dem Extraktor, der das Paket gefunden hat. Eine Komponente ohne Version trägt einen expliziten Unknown-Marker statt einer Vermutung.
• Component Producer — der Supplier, für jedes Ökosystem im Korpus abgeleitet. Vendorte C/C++-Kopien tragen bewusst keinen: Ein lokal vendortes Verzeichnis hat keinen Upstream-Lieferanten, den man behaupten könnte.
• Component Identifiers — eine Package-URL, plus eine CPE, wo ableitbar. Kernel-Module bekommen pkg:generic-purls nachgetragen, damit keine Komponente ohne maschinenlesbaren Identifier ausgeliefert wird.
• Component Hash Algorithm und Value — aus Lockfile-Digests, OS-Paketdatenbanken, dem chisel-Manifest und einem SHA-256 der Datei selbst bei klassifikator-erkannten Binaries.
• Component License — nach SPDX normalisiert aus offline verfügbaren Paketdaten; --online-licenses schließt verbleibende Lücken via deps.dev.
• Component Dependency Relationship — echte Kanten aus sechs Lockfile-Formaten in dependencies[], wobei compositions[] den Graphen dort als unvollständig erklärt, wo kein Lockfile ihn pinnt.

Unbekannte Angaben explizit kennzeichnen

Über die Datenfelder hinaus verlangt CISA, dass ein Autor einen unbekannten Wert ausspricht, statt ihn stillschweigend wegzulassen. CycloneDX 1.6 kennt dafür keinen Marker auf Feldebene, also setzt kunnus kunnus:unknown:producer, kunnus:unknown:version, kunnus:unknown:hash und kunnus:unknown:license auf jede Komponente, der das Feld nach allen Anreicherungsstufen noch fehlt. Ein Marker bedeutet immer „dem SBOM-Autor unbekannt“, nie „bekannt, aber zurückgehalten“ — kunnus hält nichts zurück. Die Root-Komponente ist ausgenommen: Ihre Identität ist Ihre Aussage, getroffen über die Identitäts-Flags.

Signiert und verifizierbar: die SBOM Author Signature

Dieses Element ist kein Wert, den ein Scanner berechnen könnte: CISA beschreibt es als Ort, an dem der Autor Informationen hinterlegt, die dem Empfänger die Gewissheit geben, dass die SBOM so ist, wie der Autor sie erstellt hat — und sagt, die Umsetzung solle vorhandene Signatur-Infrastruktur, Werkzeuge und Schlüsselverwaltung nutzen. Ein Scanner hält keine Ihrer Schlüssel, also signiert kunnus nichts und baut keine eigene Krypto. Signieren Sie stattdessen die erzeugte Datei mit einer Keyless-cosign-Signatur; das Bundle liegt neben der 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 lässt sich dasselbe als Artifact Attestation mitführen — ein Sigstore-signiertes in-toto-Statement gegen die Artefakte, die die SBOM beschreibt:

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

Abnehmer verifizieren dann mit gh attestation verify <Artefakt> -R <owner>/<repo> --predicate-type https://cyclonedx.org/bom. Die Releases von kunnus-scanner funktionieren genau so: Jedes Release trägt eine CycloneDX-SBOM des veröffentlichten Quellbaums mit separatem cosign-Bundle, attestiert gegen die Archive und Pakete, die sie beschreibt. Eine ehrliche Einschränkung: Ein separates Bundle signiert das Dokument von außen, statt einen Signaturblock darin zu füllen. So wird üblicherweise signiert, und es liefert genau die Zusicherung, für die es das Element gibt — wer aber auf eine Signatur im Dokument selbst besteht, findet sie heute nicht.