SBOM - Software Bill of Materials

About 2 min read

A SBOM (Software Bill of Materials) is a "parts list" that enumerates all the components that make up a piece of software (libraries, frameworks, dependent packages, and so on). It applies the manufacturing concept of a BOM (bill of materials) to software, recording in a machine-readable format which version of which library is used. Triggered by the surge in supply chain attacks and the Log4Shell incident in 2021, it has been gaining worldwide attention as a means of ensuring software transparency.

Historical Background and Legislation

The concept of an SBOM itself had been discussed since the early 2010s, but the turning point came with Executive Order 14028, signed by U.S. President Biden in May 2021. This executive order mandated the provision of an SBOM for software delivered to the federal government, demanding transparency in the software supply chain at the national level. Log4Shell (CVE-2021-44228), which came to light in December of the same year, dramatically proved this policy correct. Organizations around the world scrambled to investigate whether their systems contained Log4j; those that had prepared an SBOM could identify the scope of impact within hours, while those that had not spent weeks.

The Two Major Formats

Which to choose depends on the purpose. If license compliance is the main goal, SPDX is appropriate; if security management is the main goal, CycloneDX fits better. In practice, a growing number of organizations generate both and use them according to the purpose.

The SBOM Generation Flow

Automatic Generation Tools

Creating an SBOM manually is impractical. Modern software has hundreds to thousands of dependencies, so the use of automatic generation tools is a prerequisite. Among the leading tools, Anchore's Syft can generate an SBOM from both container images and file systems and is easy to integrate into a CI/CD pipeline. Aqua Security's Trivy can perform vulnerability scanning and SBOM generation with a single tool, carrying the process all the way through to cross-checking against the CVE database. GitHub's Dependency Graph and GitLab's Dependency Scanning also have built-in SBOM generation features, enabling management at the repository level.

Common Misconceptions

There is a misconception that "making an SBOM makes you secure," but an SBOM is merely a tool for visualization and does not by itself improve security. What matters is the operational process of continuously updating the SBOM, cross-checking it against newly disclosed vulnerabilities, and connecting that to patch management. In addition, an SBOM must include not only direct dependencies but also transitive dependencies (libraries that a dependency in turn depends on). Even in the Log4Shell case, many organizations were affected even though they did not use Log4j directly, because the frameworks they used depended on Log4j internally.

Real-World Use Cases

"The morning after Log4Shell was disclosed, our team, which had maintained an SBOM, identified the 12 affected services in two hours and completed patching all of them by noon. Meanwhile, the department without an SBOM spent two weeks on a manual investigation, remaining exposed to risk the entire time."

The big picture of supply chain security is explained in detail in the article on supply chain attacks, and safe ways to use open source are covered in the article on open-source security audits. For building an organization's security foundation, the startup security checklist is also a useful reference.software supply chain security books on Amazon are also helpful in practice.