provenance
Sign in

Software bill of materials

SBOM management that ends at an answer

Publish a CycloneDX SBOM per release and the register does the rest. Components are deduplicated across the estate, joined to what is deployed, scanned against advisory feeds and kept as evidence you can hand to an assessor.

From a build artefact to an answer

Five steps. Earlier tools stopped being useful when they skipped one of them.

  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. An ingest is only reported once the artefact is 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 can land 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, because the author cannot approve their own.

Who ships this component?

Search by name or exact package URL to get every release that contains the component, with the environments each release is deployed to now. You open this screen when an advisory lands.

The attested original

Download the exact document your build published, with its digest, or a regenerated view labelled as such. When a regulator asks you to send what you shipped, you can send the artefact itself.

Estate-wide export

One CycloneDX document covering every component currently deployed across the estate, or only production. It answers "what are you running" with one file.

Licence exposure

Verdicts per SPDX identifier with rationale and attributable waivers, coverage stated as a percentage, and a warning when a forbidden licence reaches a deployed release.

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 versions. SPDX is not accepted today. If your generator emits SPDX, convert it or emit CycloneDX, which most modern tools can do. The document you publish is stored verbatim and returned byte-exact, so what you get back is your own file.

Container images, and where an SBOM comes from

provenance does not generate SBOMs. It ingests them from whatever produced them, such as 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 image is treated as a release, and its components are deduplicated by purl with everything else. Because the register takes the document from your build, it holds what you actually shipped.

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

Software supply chain security covers build integrity, artefact signing, provenance attestations and the inventory of what you depend on. provenance covers the inventory and the exposure questions that follow from it. It does not sign artefacts, verify build provenance in the SLSA sense or gate a pipeline. Other tools are built for those jobs.

Open source licence compliance

Every component carries the licences its SBOM declared, deduplicated across the estate, so you can check whether anything you ship uses AGPL with one search. Each licence has a verdict of allowed, review or forbidden. A forbidden licence in a deployed release is shown separately from the same licence in a release nobody runs. Components that declare no licence are counted and named, and never assumed to be permissive.

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 that way, so the list is ordered by real exposure.

Where the roadmap sits today

Each of these is on the roadmap, and no other page on this site suggests any of them is available today.

  • SPDX ingest. CycloneDX only today.
  • VEX import. Positions are authored in the platform. They cannot be imported from a supplier yet.
  • 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. Exploit probability is not used.

SBOM questions

Which SBOM format do you accept?

CycloneDX JSON, posted as the raw document against a release. SPDX ingest is on the roadmap, but you cannot submit an SPDX document today.

How do you identify a component?

By package URL (purl), which names the ecosystem, the package and the version unambiguously. Components are deduplicated by purl across the whole estate. Thirty products sharing a base image give one row with thirty occurrences. That is why "who ships this" is a single lookup instead of a sweep through every SBOM you hold.

Do you keep the original document or regenerate it?

Both, and each is labelled. The exact bytes you published are retained with their SHA-256 digest and served back as the attested original. A second, regenerated form shows what the register now holds for the release, and its metadata says it was regenerated. If the original was never retained, the export refuses rather than returning the regenerated version.

What happens to a release with no SBOM?

It shows no findings, and the interface marks it as unknown rather than clean. A release with no SBOM cannot produce findings, and that does not make it safe.

Can I import a supplier VEX document?

Not yet. VEX positions are authored in the platform, where the author is recorded and a suppression on a critical finding needs a second person to approve it. Importing CycloneDX VEX or OpenVEX from a supplier is on the roadmap.

How do licences work?

Every licence declared by a component in the estate is listed with its recorded verdict (allowed, review or forbidden), a rationale and an attributable waiver. A licence without a verdict is reported as unreviewed and is never treated as allowed.

Point your CI at it

You need a scoped key and one POST per release. The register does the rest. The API is documented for people and for agents at /llms.txt.