SBOM Management
Collect CycloneDX and SPDX files from your pipelines and suppliers, check their quality on every build, and keep an SBOM per release that you can look up and compare.
SBOMs are easy to generate and hard to keep track of
Every team uses a different generator, suppliers send different formats, and every release adds a file. After a few months nobody knows which SBOM describes what shipped.
- SBOMs scattered across systems
- Build artifacts, shared folders and email. There is no single index to look up what shipped in a given release.
- Formats that never line up
- CycloneDX from one pipeline, SPDX from another, a different version from each supplier.
- No release history
- When someone asks what was in version 3.4.1, the answer is rebuilt from build logs.
- Low-quality SBOMs go unnoticed
- A file without supplier names or versions passes until someone needs it.
How it works with SBOM Observer
1Generate or bring the SBOM
Use Syft, Trivy, cdxgen or the Observer CLI. Anything that writes CycloneDX 1.3+ or SPDX 2.2+ works.
2Check and upload in CI
observer analyze runs your policies and fails the build on a violation. observer upload stores the SBOM with the release.
3Compare releases
See which components, versions, licenses and vulnerabilities changed between two releases.
Quality checks fail the build
Policies such as the NTIA minimum elements run on every build. An incomplete SBOM fails in the pipeline, before anyone relies on it.
# Generate an SBOM for this buildobserver fs -o sbom.cdx.json .# Evaluate your policies. Exits non-zero on a violationobserver analyze sbom.cdx.json# Upload for monitoring when the build passesobserver upload sbom.cdx.json
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
Provenance next to each component
Components carry their source repository, project links and SLSA provenance where it exists. A library used by ten applications is one record.
Who works with it
- Security and AppSec teams
- See which components entered each release and which CVEs affect them, without a new scan.
- Platform engineers
- Add the Observer CLI to CI/CD once. Every build uploads its SBOM and gets a policy result.
- Compliance and audit
- Get the SBOM for a release, stored against the build that shipped.
Questions
Can we keep our own SBOM generator?
Yes. SBOM Observer accepts CycloneDX 1.3 and later and SPDX 2.2 and later from any generator, including Syft, Trivy and cdxgen. The Observer CLI can also generate one.
What happens when a supplier sends a low-quality SBOM?
It goes through the same policies as your own SBOMs. Missing fields, such as a supplier name or component version, show up as policy violations you can take back to the supplier.
Which CI systems does the CLI run in?
GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI and any CI with a shell step.
More SBOM Observer use cases
All use cases- Vulnerability ImpactSee which applications and releases a CVE affects, and record VEX decisions next to it.
- Regulatory ComplianceKeep SBOM, VEX and policy results per release for CRA, NIS2 and DORA.
- Software InventoryOne inventory of components and releases across internal and supplier software.
- M&A and Due DiligenceReview an acquisition target or new vendor from its SBOMs.
Upload an SBOM from your own build
Click through the live demo with example data, or book a demo and bring your own SBOMs.