Attestations

An attestation is a document that makes a claim about a piece of software. SBOM Observer works with three kinds. An SBOM says what a release contains. A VEX statement says whether a known vulnerability affects it. SLSA provenance says where and how it was built.

Each one answers a question you could otherwise answer by reading the source code and the build. For most of the software an organization runs, nobody there can.

Software you can't inspect

Your own repositories hold the answers for software your teams build: the lock files list the dependencies, and the build scripts show how a release was made. Most of what runs in production comes from somewhere else, though. A vendor's application, a base image pulled from a registry, an appliance on the network. You receive the binary, not the build.

When an advisory is published for a widely used library, the first question is whether you run it, and where. Without a component list per product, that question goes to every supplier as an email, and you wait for the answers. With your suppliers' SBOMs in SBOM Observer it becomes a search: impact analysis lists every application and container that includes the component, directly or through other components.

Your own releases need the same record. The source code keeps changing after a release ships, so the repository today doesn't tell you what version 2.3 contained. An SBOM generated when that release was built does, and it stays as evidence after the code has moved on. Retention strategy covers how many versions to keep active.

Three questions, three attestations

Formats and standards lists the versions and encodings SBOM Observer accepts.

SBOM

An SBOM lists the components of a release with their versions, package URLs, licenses, and suppliers, and how they depend on each other. It is a claim by whoever generated it, so its accuracy depends on the tool and on what it scanned. An SBOM generated from source can list dependencies the build never includes. One generated from the built binary or image lists what ships. See Generate SBOMs at build time and for containers.

VEX

Vulnerability matching compares component versions with advisories. A match means the vulnerable version is present. It doesn't mean the vulnerability can be exploited in this product: the vulnerable function may never be called, or the affected feature may be left out of the build. Until someone records that analysis, every team that runs the product triages the same finding again, and an auditor sees an open critical vulnerability.

A VEX statement records the conclusion once, with a state such as not_affected and a justification. Suppliers can publish VEX next to their SBOMs, and you can record your own in SBOM Observer.

A statement covers every dependency path that runs through the component it is about. If a supplier marks its application not_affected by a vulnerability in a library it bundles, that settles the vulnerability for the application. A statement on a framework inside the application settles only the paths through that framework. If the application also reaches the library some other way, the vulnerability stays open.

Policies receive the VEX state with each vulnerability, so a policy can skip what has been analyzed and marked not_affected or resolved.

SLSA provenance

An SBOM names the package version in a release. It can't tell you whether that package was built from the source repository it claims to come from. Provenance can: the build system signs a statement naming the source repository, the commit, and the build workflow, and records it in the public Sigstore transparency log.

SBOM Observer collects provenance for npm packages. After an SBOM is imported, it looks up each npm component on deps.dev and imports the provenance npm publishes for that version, when there is one. This needs internet access, so air-gapped installations skip it. You can also upload an npm provenance bundle yourself.

The provenance shows in the Provenance Attestation section of the component's OSS Insights tab, with links to the commit, the workflow run, and the transparency log entry. See Evaluate open source components.

How they combine

All three land in one index per namespace, linked to the components they describe, so an SBOM and the VEX for it can arrive months apart and from different senders. One component-scoped policy sees the component from the SBOM, its vulnerabilities each with its VEX state, and its provenance. Data model fundamentals describes the index.

Which attestations to collect

Two questions pick the row: who builds the software, and who needs the answers. Your security team needs them for everything you run. Your customers need them for what you ship to them.

Regulations such as the Cyber Resilience Act ask for this record. Compliance mapping maps their requirements to SBOM Observer.

Related

• Concept: Data model fundamentals, Compliance mapping
• Reference: Formats and standards
• How-to: Generate and upload SBOMs