An ingredients list for software
Almost no software is written from scratch. A typical application pulls in dozens or hundreds of open-source libraries, and those libraries depend on others in turn. An SBOM is a machine-readable inventory of all of these components: the ones a project uses directly, and the transitive dependencies that come along with them.
What it records
For every component, an SBOM typically lists:
- its name and version
- a unique identifier, usually a Package URL such as
pkg:maven/org.apache.maven/maven-core@3.9.9 - the license it is published under
- which other components it depends on
Why it matters
When a new vulnerability is published, the first question is: are we affected? Without an SBOM, answering it means digging through the build files of every project. With one, it is a lookup. The Log4Shell vulnerability in Log4j in 2021 made this painfully clear, and regulations such as the EU Cyber Resilience Act now require manufacturers to document the components of their products in an SBOM.
Two common formats
SBOMs are usually written in one of two open standards: CycloneDX, maintained by OWASP, and SPDX, maintained by the Linux Foundation and published as ISO/IEC 5962. Both are plain JSON or XML files that tools can read, compare and check automatically.
How Release Prism uses them
Open Elements generates SBOMs for the open-source projects it tracks and analyzes them with OWASP Dependency-Track, which checks every component against public vulnerability databases. Release Prism shows the results as point-in-time snapshots: pick an artifact and a version to see its dependencies, licenses and known vulnerabilities, or download the SBOM file itself.
Browse tracked projects