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.

Whether You Can Answer Immediately When a Vulnerability Is Disclosed

What is needed immediately after a vulnerability is disclosed is, in most cases, the answer to a single question: does the software currently running contain the affected version of that component? If an up-to-date inventory of components is already in place, answering it is a matter of cross-checking records. If it is not, it becomes an investigation that walks through repositories and running environments one by one, and the time required grows in proportion to the number of things to check. It is not only the time that changes, but also the confidence in the result. In a manual investigation, "not found" is not proof that the component is absent, so a judgment of "not affected" cannot be made on solid grounds. Without being able to separate the scope that needs action from the scope that does not, organizations tend to apply precautionary measures across a wide area. Moreover, the timing of a disclosure is not something you choose. Starting to build the inventory after disclosure means that building it costs as much as the manual investigation itself, so it does not serve as material for meeting the deadline. Having a state in which records can simply be cross-checked, prepared in ordinary times, is directly connected to how long you remain exposed after a disclosure.

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.