Software Bill of Materials

Open up your favorite IDE, jump into your most recent project, and open its respective lockfile (package-lock.json, go.mod, Pipfile.lock, and so on). You’ll likely find hundreds or thousands of open-source packages and libraries, illustrating exactly how widely your application's unseen and unknown parts spread.

A Software Bill of Materials (SBOM) is a similar inventory of all software components, libraries, and dependencies your application relies on, but goes deeper than package names and pinned versions. By aggregating data on open-source licenses and more, an SBOM gives you complete visibility, which you can use to prevent supply chain attacks or identify new vulnerabilities in a dependency two, three, or more layers deep.

An SBOM comes in many different output formats and data structures, but is ultimately a database of artifacts, including their package names, versions, sources, licenses, URLs, and more. SBOMs also identify the relationship between two artifacts for transparency into the web of dependencies your application relies on.

While SBOMs aren’t particularly useful to scroll through, they are enormously helpful in the broader vulnerability management of your application. You can feed your apps’ SBOMs into other tools offering dependency scanning, malware detection, or end-of-life (EOL) data to ensure you’re surfacing every possible vulnerability in your application—not just the ones at the surface level.

Generating SBOMs is accessible to most developers in their local working environment—one option is an open-source tool, like Syft, to investigate any container image or local filesystem: