SBOM (Software Bill of Materials)
1. Overview
A. Definition
A specification that inventories, in machine-readable form, all components, libraries, and dependencies of a piece of software along with their version, license, and supplier information. Borrowing the concept from the manufacturing Bill of Materials (BOM), it is the core deliverable of Software Supply Chain security (SSC).
The fundamental purpose of the SBOM lies in the proposition "you can't secure what you can't see." In a modern application, 70–90% of the code is filled not by what the developer wrote directly but by external open-source and third-party components, yet most organizations lack even a list of what and how much is inside. The SBOM makes this "ingredient label of software" (often likened to a food nutrition label) explicit, elevating vulnerability and license risks—previously in a management blind spot—into manageable objects.
The crux is that an SBOM is not merely a document but an automatable data structure. If it stopped at a human-readable list, it would be impossible to cross-check hundreds of components against a daily-updated vulnerability database. Therefore, an SBOM attains effectiveness only when written in a standard format that tools can parse, cross-reference, and verify.
B. Background and Necessity
As open-source dependencies exploded, a single app came to depend directly and indirectly on hundreds to thousands of components, and major incidents followed in which a single flaw hidden deep within spread across the entire supply chain. Representative are the SolarWinds (2020) incident, which contaminated the build system itself to distribute malware on legitimately signed updates, and Log4Shell (Log4j, 2021, CVE-2021-44228), a remote-code-execution vulnerability in a widely used Java logging library.
During Log4Shell in particular, countless organizations delayed their initial response by days because they "could not even determine whether their systems used Log4j, and if so which version and where." Had an SBOM been in place, they could have instantly identified the scope of impact with a single query and patched by priority. This incident etched the value of the SBOM into the entire industry. Against this backdrop, the U.S. mandated SBOM submission for software delivered to the federal government through Executive Order EO 14028 (2021), after which it rapidly spread into national regulations and industry standards.
2. SBOM Components, Standard Formats, and Generation Tiers
A. Components and Standard Formats
For an SBOM to be effective, it must be interpretable automatically by tools rather than humans, so writing it in a machine-readable standard format is important. Only when the format is standardized can SBOMs be exchanged between different organizations and tools, cross-checked automatically against vulnerability databases, and verified back up the supply chain.
| Category | Content |
|---|---|
| Components | Component name·version, supplier, dependency relationships, license, hash (integrity verification) |
| Standard formats | SPDX (Linux Foundation, ISO standard), CycloneDX (OWASP, security-focused), SWID |
The U.S. Department of Commerce's NTIA defined the minimum elements an SBOM must contain: supplier name, component name, version, unique identifier, dependency relationships, SBOM author, and timestamp. These minimum elements form the common basis for cross-checking and merging different SBOMs. As a component's unique identifier, PURL (Package URL) or CPE (Common Platform Enumeration) is used, because only when notation is standardized can one judge without false positives "is this component the same as the target of that CVE?".
The formats also differ in character. SPDX has strengths in license and compliance management and was adopted as an international standard (ISO/IEC 5962:2021), while CycloneDX, led by OWASP, focuses on vulnerability and supply-chain security use, with rich expression of VEX, services, and dependency graphs. The reason for including a hash (checksum) is to verify whether the specified component is bit-for-bit identical to the actual distributed artifact (whether it has been tampered with or contaminated). Without a hash, a supply-chain attack where "the list is right but the actual artifact has been swapped" cannot be filtered out.
B. Tiers by Generation Point
An SBOM's accuracy and completeness differ depending on when it is generated. Understanding this makes clear why build-time automatic generation is recommended.
| SBOM type | Generation point | Characteristics |
|---|---|---|
| Source SBOM | At source/dependency declaration | Based on declared dependencies, may differ from actual inclusions |
| Build SBOM | At build/compile time | Based on the actual artifact, accurate·current (recommended) |
| Deployed/Runtime SBOM | At deployment·operation | Reflects even the runtime environment·configuration |
The dependencies declared at the source stage and the components actually included in the build artifact often diverge (due to transitive-dependency resolution, conditional inclusion, bundling, etc.). Hence the received wisdom is that a trustworthy SBOM must be a Build SBOM extracted from the artifact that the build pipeline actually produced.
3. Objects of Management: Open-Source Risks
The risks that an SBOM seeks to make visible are broadly fourfold, of which transitive dependencies are the trickiest. Because it is a multi-tier structure in which a library I imported directly calls another, which in turn calls a third, the component that actually becomes the problem lurks deep in a place invisible to the eye. In fact, while an app's explicitly declared direct dependencies may number in the dozens, the transitive dependencies dragged in from them commonly reach hundreds to thousands.
| Vulnerability | Content |
|---|---|
| Known vulnerabilities (CVE) | Public flaws like Log4j lurk in transitive dependencies |
| Dependency risk | Hard to grasp what is used due to multi-tier transitive dependencies |
| License violation | Legal risk when copyleft licenses like GPL are not complied with |
| Maintenance halt·malice | EOL (end-of-life) packages, malicious injection (Typosquatting) |
The reason license violation is as important as security is that including a strong copyleft license like GPL without awareness leads directly to legal and business risks—such as an obligation to disclose one's own source code or restrictions on distribution. There are not a few real cases where an open-source license violation halted product shipment or escalated into litigation.
The last type, maintenance halt·malicious injection, is also a surging threat lately. Typosquatting, which registers a fake package differing by a single letter from a popular package name to prey on typos; dependency hijacking, which seizes the maintenance rights of a legitimate package to distribute a malicious version; and unpatched vulnerabilities of long-abandoned EOL packages—all are hard to even become aware of without an SBOM.
These four risks intertwine and amplify one another. For example, if a new CVE is disclosed for a transitive dependency whose maintenance has ceased due to EOL, no patch will appear, so one must replace it with an alternative component or work around it; yet because it is a transitive dependency, without an SBOM it is hard to even trace which direct dependency to touch. Thus risks must be judged not individually but in the context of the entire dependency graph, and the SBOM serves as the very map that provides that graph.
4. SBOM-Based Management Approaches
An SBOM must be not a static document made once and done, but a continuous process that cycles through generation → sharing → mapping → response → regeneration. Because new CVEs are disclosed by the dozens to hundreds every day, a component safe until yesterday can become vulnerable today.
flowchart LR
G["Generate SBOM(SPDX·CycloneDX)"] --> S["Share·publish"]
S --> M["Vulnerability mapping(CVE·NVD cross-check)"]
M --> R["Response·patch·monitoring"]
R -. Continuous management .-> G
Each stage of the above cycle is concretized across the CI/CD pipeline and the operations stage as follows. The diagram below shows how the SBOM is automatically integrated along the development-build-operation axis.
flowchart TB
DEV["Development(declare dependencies)"] --> BUILD["Build(auto-generate SBOM)"]
BUILD --> SCA["SCA scan(composition·vulnerability·license)"]
SCA --> VEX["Judge exploitability via VEX"]
VEX --> GATE{"Pass release gate?"}
GATE -->|No| DEV
GATE -->|Yes| OPS["Deploy·operation monitoring"]
OPS -. Watch new CVEs .-> SCA
| Stage | Approach |
|---|---|
| Generation | Auto-generate the SBOM at CI/CD build time (secures accuracy·currency) |
| Analysis (SCA) | Scan components·vulnerabilities·licenses with an SCA tool |
| Mapping | Cross-check against the CVE/NVD database to identify vulnerable components |
| Response·monitoring | Patch·upgrade, continuously watch for new CVE disclosures |
The crux is to integrate SBOM generation into the build pipeline automatically, not by human hands. A specification written by hand quickly diverges from the actual code and becomes untrustworthy, so an SBOM must be mechanically extracted from the actual artifact each time the build runs. Representative tools include the SBOM generator Syft, the vulnerability scanners Grype·Trivy, and commercial SCA platforms (e.g., Snyk, Sonatype), which are connected to CI to automate generation-scanning-blocking.
Another important practical point is securing the trustworthiness of the SBOM itself. If an SBOM is forged or altered, it can instead give a false sense of safety, so a procedure must also be in place to attach a digital signature to the generated SBOM (e.g., Sigstore/Cosign) and verify its integrity, only then completing the supply-chain chain of trust.
5. Deep Dive: VEX Coupling and Domestic/International Regulatory Trends
That a vulnerability list alone easily overestimates actual risk is the greatest pitfall of SBOM operation. Even if a CVE exists in some component, if the vulnerable code path is not actually invoked·executed in our product, the exploitation risk may be nonexistent or very low. What bridges this gap is VEX (Vulnerability Exploitability eXchange). VEX is a document in which the supplier explicitly declares, for each vulnerability, an exploitability status such as "not_affected · under investigation · affected · fixed," decisive for setting response priorities and reducing needless patch fire drills. If the SBOM is "what is inside," VEX is "which of those is actually dangerous," and the two must be paired for effectiveness to be complete.
Regulatory trends are also strengthening rapidly. The U.S., following EO 14028, is expanding SBOM requirements to medical devices (FDA) and federal procurement at large, and the European Union is moving, through the CRA (Cyber Resilience Act), toward imposing SBOM provisioning and vulnerability-handling obligations on digital products placed on the market. In Hàn Quốc too, centered on the Ministry of Science and ICT and KISA, SW supply-chain security guidelines are being prepared and the flow of SBOM adoption is being discussed and spreading, starting with the public and financial sectors. However, since the detailed scope and timing of mandates may vary by policy, it is advantageous for organizations to establish an SBOM management system proactively rather than chasing regulations.
The expected exam direction from a professional-engineer perspective can be organized into (1) a comparison of the SBOM's definition·minimum elements·standard formats (SPDX vs CycloneDX), (2) the necessity of managing transitive dependency·license risks, (3) the continuous process of SBOM generation-SCA-CVE mapping-VEX-monitoring, and (4) approaches to DevSecOps integration and signature-based integrity assurance.
6. Considerations and Implications
First, securing automation and currency. The SBOM must be integrated into the build pipeline and auto-generated on every build; a hand-crafted specification quickly ages and loses trust. Beyond generation, continuous re-mapping aligned with new CVE disclosures must run together for the SBOM to become a living asset.
Second, prioritization through VEX coupling. Response order must be set by exploitability rather than by the sheer number of vulnerabilities, so that limited manpower can concentrate on actual risk. Listing only CVEs without VEX creates the paradox that "patch fatigue" delays the response to genuinely dangerous vulnerabilities.
Third, securing SBOM integrity·chain of trust. Supply-chain trust holds only when there is a procedure to sign·verify the SBOM itself, detect artifact tampering via component hashes, and confirm the authenticity of an SBOM received from a supplier. An untrustworthy SBOM gives a false sense of safety worse than having none.
Fourth, ongoing management of licenses·compliance. Not only security vulnerabilities but also copyleft·conflicting licenses must be continuously inspected to proactively control legal and business risks, which requires accurately managing SPDX-based license metadata.
Fifth, organization-wide DevSecOps internalization and regulatory response. SBOM·SCA·VEX must be continuously integrated into the pipeline, and regulatory changes such as the EU CRA and Hàn Quốc's SW supply-chain security policies must be proactively reflected to raise the supply-chain security maturity across the organization. A perspective is needed in which the SBOM is not an end in itself but the foundational infrastructure underpinning the visibility·trust·responsiveness of the entire supply chain.
References
- CISA, "Software Bill of Materials (SBOM)": https://www.cisa.gov/sbom
- NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)", 2021
- OWASP CycloneDX: https://cyclonedx.org/ · SPDX: https://spdx.dev/
In one line: The SBOM inventories software components in the SPDX·CycloneDX standards to make open-source vulnerability·license risks visible, and manages supply-chain security through the continuous process of auto-generation at build time → SCA scan → CVE mapping → VEX prioritization → signing·monitoring—a foundational infrastructure.