Dependency Firewall offer: 50% off your base fee for 3 months + €100 usage credit.Start trialSee what’s new

Regulatory Compliance

Keep the SBOM, VEX decisions and policy results for each release you ship. When an auditor or customer asks about a release, the evidence was stored when it was built.

Open the live demoBook a demo

payments-api 3.4.1

Built Aug 12, 2026 in GitHub Actions

Documents

  • payments-api-3.4.1.cdx.jsonSBOM, CycloneDX 1.6, 412 components
  • payments-api-3.4.1.vex.jsonVEX, 9 statements
  • payments-api-3.4.1.intoto.jsonlSLSA provenance
  • 3 supplier SBOMsNordlys Embedded AS, Helix Networks Ltd, Meridian Systems GmbH

Policy results from the build

  • NTIA minimum elementsPassed
  • Copyleft licensesPassed
  • Critical vulnerabilities with EPSS above 10%Passed
What SBOM Observer keeps for one release: its documents, supplier SBOMs and the policy results from the build.

Evidence is collected after someone asks

Naming the regulation is the easy part. The work is producing the SBOM, vulnerability status and policy results for the release that shipped, and keeping them for years.

Regulations name requirements and leave the process to you
The CRA asks for an SBOM. It does not say which tool, which format or where it is stored.
Evidence sits in several systems
The SBOM in one, policy results in another, supplier documents in email. Every audit starts by collecting them.
Proving what ran at release time is hard
You can show today's policy. Showing that it ran when version 2.3.0 shipped is harder.

How it works with SBOM Observer

  1. 1Run policies in CI/CD

    Vulnerability, license and SBOM quality policies run on every build with the Observer CLI.

  2. 2Results are stored with the release

    SBOM, VEX, SLSA provenance and the policy results are kept against the release version.

  3. 3Answer the request

    Export SBOM and VEX for the release, or publish them to customers through Trust Repository.

Every document per release

SBOMs, VEX and SLSA provenance, in open formats. Invalid files are kept apart, and archived ones stay available.

Imported attestations: 44 documents, none invalid, one archived.
Imported attestations: 44 documents, none invalid, one archived.

Policy results from the pipeline

The result of each policy check is stored with the build that produced it. You can show which checks a release passed, and when.

build job in CI
# Generate an SBOM for this build
observer fs -o sbom.cdx.json .
 
# Evaluate your policies. Exits non-zero on a violation
observer analyze sbom.cdx.json
 
# Upload for monitoring when the build passes
observer upload sbom.cdx.json
Failed

Library Vulnerabilities EPSS/VEX

spring-beans 5.3.17: CVE-2022-22965 with CVSS 9.8 and EPSS 0.98 is not tolerated for a library

A policy check in the build job. Pass or fail, the result is kept with the release.
More about SBOM ObserverPricing

Who works with it

Compliance officers
Find the SBOM, VEX and policy results for a release without asking engineering to rebuild them.
CISOs and security leads
Show that vulnerability and license policy ran at release time, from pipeline records.
Legal and risk teams
See supplier components next to internal ones, traced to the releases that ship them.

Questions

Can we show what was in a release two years ago?

Yes. Every SBOM, VEX document and policy result is stored per release and version.

Which regulations does this support?

The EU Cyber Resilience Act, NIS2 and DORA, and the US EO 14028 requirements for vendor SBOMs.

How do we share this evidence with customers?

Export SBOM and VEX from SBOM Observer and publish them per release in Trust Repository, where customers download them from your Trust Portal.

More SBOM Observer use cases

All use cases

Upload an SBOM from your own build

Click through the live demo with example data, or book a demo and bring your own SBOMs.

Open the live demoBook a demo
SBOM Observer attestations: imported CycloneDX SBOMs with their status, type and component count