SBOM management that ends at an answer, not a document

From a build artefact to an answer

Five steps, each of which exists because skipping it is how the previous tool stopped being useful.

1. Publish. CI posts the CycloneDX document against a release with a scoped key. The bytes are retained and their digest recorded before anything is parsed, so the ingest is not claimed until the artefact is actually held.
2. Deduplicate. Components are keyed by package URL across the whole estate. One row per component, one occurrence per release that ships it.
3. Join to reality. A deployment records which release runs in which environment, and optionally on which machine from the hardware register.
4. Scan, and keep scanning. Releases are scanned on demand and on a nightly schedule, because an advisory published today lands in a component ingested months ago.
5. Decide, attributably. A VEX position records what you concluded and why. Suppressing a critical finding needs a second person; the author cannot approve their own.

Formats, containers and the rest of the supply chain

Which SBOM formats are accepted

CycloneDX, versions 1.2 through 1.6, as JSON. Anything else is refused with a message naming the supported set rather than accepted and quietly mangled. SPDX is not accepted today — if your generator emits SPDX, convert it or emit CycloneDX; most modern tools can do either. The document you publish is stored verbatim and returned byte-exact, so what you get back is your file and not a re-rendering of it.

Container images, and where an SBOM comes from

Nothing here generates an SBOM. It ingests one, whatever produced it — a language-level scan of your source tree, or an image scan of a built container. If your pipeline already emits CycloneDX for a container image, that is a release like any other and its components deduplicate by purl alongside everything else. The advantage of taking the document rather than scanning for you is that the register holds what you actually shipped, not what a scan thought it saw afterwards.

Software supply chain security, and the part of it this is

Software supply chain security spans build integrity, artefact signing, provenance attestations and the inventory of what you depend on. This platform is the inventory half and the exposure question that follows from it. It does not sign artefacts, does not verify build provenance in the SLSA sense, and does not gate a pipeline. Those are real and separate problems, and a register that pretended to solve them would be the wrong tool in two places instead of the right one in one.

Open source licence compliance

Every component carries the licences its SBOM declared, deduplicated across the estate, so "does anything we ship use AGPL" is a lookup. A verdict is recorded per licence — allowed, review, forbidden — and a forbidden licence in a deployed release is separated from the same licence in something nobody runs. Components declaring no licence at all are counted and named rather than assumed permissive, which is the failure mode that matters in open source license compliance: the gap is never the licence you can see.

CVE tracking against what you ship

A CVE matters to you only if you ship the affected component, and it is urgent only if that release is deployed. Findings are recorded per component occurrence and ranked by that, so CVE management here means a list ordered by real exposure rather than by how many hosts a scanner happened to see it on.

Where the roadmap sits today

We would sooner you read this here than find it in your first hour. Each of these is actively on the roadmap, and none of it is implied anywhere else on this site.

• SPDX ingest. CycloneDX only today.
• VEX import. Positions are authored in the platform, not imported from a supplier.
• Dependency graph. Components are recorded flat, so "what pulls in this transitive dependency" is not yet answerable.
• EPSS and CISA KEV ranking. Triage uses severity, CVSS and real deployment, not exploit probability.