SBOM-Identität, Autor & Seriennummern

Eine SBOM muss sagen, wer sie erzeugt hat und welches Dokument sie fortschreibt — sonst kann ein Abnehmer eine neue Revision Ihrer SBOM nicht von der SBOM eines ganz anderen Produkts unterscheiden. Diese Flags setzen genau diese Metadaten; keines von ihnen verändert, was gescannt wird.

kunnus sbom repo \
  --author "ACME GmbH <psirt@acme.example>" \
  --component-id acme/widget \
  --component-version 1.2.3 \
  --output sbom.cdx.json

Wer sie erzeugt hat: --author

Die CISA-Mindestangaben definieren den SBOM-Autor als die Organisation, die das Werkzeug betreibt — nicht als das Werkzeug selbst. --author (Env KUNNUS_AUTHOR) nimmt "Name" oder "Name <E-Mail>", wird vor dem Scan validiert und landet in metadata.authors und metadata.manufacturer. kunnus und osv-scalibr bleiben getrennt davon unter metadata.tools mit ihrer jeweiligen Version verzeichnet. Ohne das Flag trägt das Dokument die Kunnus-Identität als Platzhalter — und die CLI warnt, dass genau das im Prüfordner landen würde.

Lineage: Seriennummern und Dokumentenserien

Jede SBOM trägt eine CycloneDX-serialNumber und eine Dokument-version. Dokumente mit derselben Seriennummer, geordnet nach Version, bilden eine Serie — eine Komponente, mehrfach gescannt. Was Sie bekommen, hängt davon ab, welche Identität Sie mitgeben:

• Ohne Identitäts-Flags: pro Lauf eine frische zufällige UUID, Dokumentversion 1. Ehrlich — jedes Dokument ist eine Serie mit einem Mitglied.
• --component-id (Env KUNNUS_COMPONENT_ID), mit oder ohne --component-version: Die Seriennummer wird deterministisch abgeleitet; Rescans derselben ID und Version ergeben immer dieselbe.
• kunnus sbom container <Registry-Referenz>: automatisch deterministisch — der Repository-Pfad schlüsselt die Serie, der Tag wird die Komponentenversion.
• --serial-number <uuid> (Env KUNNUS_SERIAL_NUMBER): exakt der übergebene Wert, blank oder als urn:uuid:, validiert vor dem Scan. Für PLM-/ALM-Systeme, die Dokument-IDs bereits selbst vergeben.

Wer eine Serie will, muss sagen, wer er ist. kunnus erfindet bewusst keine Identität aus dem, was es sieht — ein Repo-Scan kennt von sich aus nur den Basisnamen des gescannten Verzeichnisses, und eine daraus abgeleitete Seriennummer wäre auf die falsche Weise stabil: Sie kollidierte über unabhängige Projekte hinweg, die in CI alle unter /src gemountet werden, und änderte sich, sobald jemand ein Checkout umbenennt.

export KUNNUS_COMPONENT_ID=acme/widget
export KUNNUS_COMPONENT_VERSION=1.2.3
kunnus sbom repo -o sbom.cdx.json

Die Komponentenversion ist Teil des Serienschlüssels: Laut CISA gilt eine Serie pro Name/Version-Paar, ein Release 1.2.4 startet also bewusst eine neue. Auch der Scan-Modus gehört zum Schlüssel — eine repo-SBOM und eine os-SBOM desselben Produkts sind unterschiedliche Dokumente mit unterschiedlicher Erzeugungssemantik und teilen nie eine Serie. Für Serienmitglieder ist die Dokument-version der Erzeugungszeitstempel in Unix-Epoch-Sekunden — so bleiben Rescans streng geordnet, ohne dass der Scanner sich zwischen Läufen etwas merken muss.

Was das Dokument ohne Flag festhält

Alles Weitere, was die CISA-Mindestangaben auf Dokumentebene verlangen, füllt kunnus automatisch: den Erzeugungskontext (pre-build bei Repo-Scans, post-build bei OS- und Container-Scans), das Datenformat samt Version, den Zeitstempel und jedes beteiligte Werkzeug mit eigener Version. Der Guide zu den CISA-Mindestangaben geht alle siebzehn Felder durch, zeigt, was kunnus in jedes einträgt, und wie das fertige Dokument signiert wird.