SBOM Identity, Author & Serial Numbers

An SBOM has to say who produced it and which document it revises — otherwise a consumer cannot tell a new revision of your SBOM from an SBOM of something else entirely. These flags set that metadata; none of them change what is scanned.

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

Who generated it: --author

CISA's minimum elements define the SBOM Author as the entity that operates the tool, not the tool itself. --author (env KUNNUS_AUTHOR) takes "Name" or "Name <email>", is validated before the scan runs, and lands in metadata.authors and metadata.manufacturer. kunnus and osv-scalibr stay recorded separately under metadata.tools, each with its version. Leave the flag out and the document ships with the Kunnus identity as a placeholder — the CLI warns you that this is what you are about to hand an auditor.

Lineage: serial numbers and document series

Every SBOM carries a CycloneDX serialNumber and a document version. Documents sharing one serial number, ordered by version, form a series — one component, rescanned. What you get depends on what identity you supply:

• No identity flags: a fresh random UUID per run, document version 1. Honest — every document is a series of one.
• --component-id (env KUNNUS_COMPONENT_ID), with or without --component-version: the serial is derived deterministically, so rescans of the same id and version always produce the same one.
• kunnus sbom container <registry-ref>: deterministic automatically — the repository path keys the series, the tag becomes the component version.
• --serial-number <uuid> (env KUNNUS_SERIAL_NUMBER): exactly the value you pass, bare or in urn:uuid: form, validated before the scan runs. For PLM/ALM systems that already mint document identifiers.

If you want a series, say who you are. kunnus deliberately does not invent an identity from what it can see — a repo scan only knows the scanned directory's basename, and a serial derived from that would be stable in the wrong way: colliding across unrelated projects that all mount at /src in CI, while changing when someone renames a checkout.

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

The component version is part of the series key: per CISA a series is per name/version pair, so releasing 1.2.4 deliberately starts a new one. The scan mode is part of the key too — a repo SBOM and an os SBOM of the same product are different documents with different generation semantics and never share a series. For series members the document version is the generation timestamp in Unix epoch seconds, which keeps rescans strictly ordered without the scanner having to remember anything between runs.

What the document records without a flag

Everything else the CISA minimum elements ask for at document level is filled in automatically: the generation context (pre-build for repo scans, post-build for os and container scans), the data format and its version, the timestamp, and every tool involved with its own version. The CISA minimum elements guide walks through all seventeen fields, what kunnus puts in each, and how to sign the finished document.