In December 2021, a security researcher published a proof-of-concept exploit for a vulnerability in Apache Log4j, a Java logging library so ubiquitous that most developers had never consciously chosen to use it. It was just there, pulled in as a transitive dependency by something else they were using. Within 72 hours, over 625,000 applications were under active attack.
The organisations that contained the damage fastest had one thing in common: they knew what was in their software. They had a list. They could search it, sort it by component, and immediately identify every system that needed patching. Everyone else was doing archaeology, manually digging through codebases, dependency trees, and container images trying to answer a question they should have been able to answer in seconds.
That list has a name. It is called a Software Bill of Materials. And after Log4Shell, the question shifted from โshould we have one?โ to โwhy don't we already?โ
โAn SBOM is the difference between knowing your exposure in 30 seconds and spending three weeks in a war room. Log4Shell did not create the SBOM conversation, it ended the debate about whether it was necessary.โ
โ Soham Sawant, Cybersecurity Expert & Technical Writer, SecComplyWhat Is an SBOM?
An SBOM is a formal, machine-readable inventory of every component, library, dependency, and module in a software product, including open source packages, third-party libraries, commercial components, and their known vulnerability status.
Think of it as the ingredient label for software. Just as a food label tells you exactly what is inside the product, not just the headline ingredients but the additives, preservatives, and allergens, an SBOM tells you exactly what is inside your application, including the things you did not consciously choose to include.
The analogy to a food ingredient label is more precise than it first appears. When a food safety recall happens, manufacturers with accurate ingredient labels can immediately determine whether they are affected. Those without them have to audit every product line from scratch. Software supply chain incidents work exactly the same way.
An SBOM typically captures for each component: its name and version, the supplier, the relationship to your software (direct dependency or transitive), the licence, known vulnerabilities (CVEs), and cryptographic hash for integrity verification. The minimum elements required by the US National Telecommunications and Information Administration (NTIA) for a โbaselineโ SBOM are supplier name, component name, version, unique identifier, dependency relationships, author of SBOM data, and timestamp.
Why SBOMs Are No Longer Optional
SBOMs have existed as a concept for years. What changed is the regulatory and commercial pressure that has made them a hard requirement rather than a best practice.
SPDX vs CycloneDX, The Two Dominant Formats
Two formats have emerged as the industry standard for SBOMs. They serve overlapping but distinct purposes, and understanding the difference matters for choosing the right toolchain.
| Attribute | SPDX | CycloneDX |
|---|---|---|
| Governing body | Linux Foundation / ISO (ISO 5962) | OWASP |
| Primary focus | Licence compliance & provenance | Security & vulnerability tracking |
| Formats supported | SPDX tag-value, JSON, YAML, XML, RDF | JSON, XML, Protobuf |
| VEX support | Limited | Native (Vulnerability Exploitability eXchange) |
| Best for | Open source licence management, legal teams | Security teams, vulnerability management, DevSecOps |
| Tooling | FOSSology, SPDX tools, Syft | Syft, cdxgen, Snyk, Dependency-Track |
| Recommended for | Software selling into legal-compliance-heavy markets | Most security-focused teams |
For most security and compliance teams, CycloneDX is the right starting point. It has better tooling support for vulnerability tracking, native VEX (Vulnerability Exploitability eXchange) for communicating exploitability status, and is the format most commonly requested by enterprise security questionnaires. You can always generate both from the same tooling.
What a Good SBOM Actually Contains
The NTIA defines the minimum elements, but a production-grade SBOM goes further. Here is what each layer adds:
| Level | What It Includes | Sufficient For |
|---|---|---|
| Minimum (NTIA) | Supplier, name, version, unique ID, dependency relationships, SBOM author, timestamp | Basic regulatory compliance |
| Standard | Above + licence info, cryptographic hash, download URL, known CVEs at time of generation | Licence compliance, vendor questionnaires |
| Comprehensive | Above + VEX statements, build environment, signing info, transitive dependencies, SBOM of SBOMs | ISO 27001, SOC 2, enterprise procurement, regulated industries |
Log4j was a transitive dependency for most affected organisations, a dependency of a dependency, not something teams had directly chosen. A baseline SBOM that only lists direct dependencies would not have caught it. Your SBOM must include the full dependency tree, not just the first level.
How to Generate Your First SBOM
The tooling has matured significantly. Generating an SBOM no longer requires specialist knowledge, for most stacks it is a single command.
๐ ๏ธ SBOM Generation, Step by Step
syft <image-name> -o cyclonedx-json > sbom.json. It scans the image layers and produces a CycloneDX SBOM covering all OS packages and application dependencies inside the container.@cyclonedx/cyclonedx-npm for Node.js, cyclonedx-bom for Python, cyclonedx-maven-plugin for Java, cyclonedx-gomod for Go. Each reads your existing package manifest and outputs a standards-compliant SBOM.How SBOMs Map to Your Compliance Frameworks
ISO 27001:2022 Annex A.8.8, Management of Technical Vulnerabilities: An SBOM is the inventory that makes this control implementable at scale. Without knowing what components you are running, you cannot manage their vulnerabilities.
ISO 27001:2022 Annex A.15.1/15.2, Supplier Relationships: Requiring SBOMs from software vendors is a directly implementable control under supplier security agreements.
SOC 2 CC9.2, Vendor and Supply Chain Risk Management: An SBOM program demonstrates that you have a systematic approach to identifying and monitoring software supply chain risk.
SOC 2 CC7.1, Vulnerability Detection: Continuous SBOM monitoring via Dependency-Track directly produces the evidence auditors need for this control.
NIST CSF 2.0, ID.SC (Supply Chain Risk Management): SBOMs are explicitly referenced in NIST guidance as a mechanism for implementing supply chain risk management controls.
Common SBOM Mistakes to Avoid
- Generating once and forgetting: An SBOM from six months ago is not a security tool, it is false confidence. SBOMs must be regenerated on every build and monitored continuously.
- Covering only direct dependencies: Log4j was a transitive dependency. If your SBOM does not include the full dependency tree, it will not catch the next Log4Shell.
- No VEX statements: Not every CVE in your SBOM represents a real risk. A CVE in a component you ship but do not execute is not exploitable. VEX (Vulnerability Exploitability eXchange) statements let you document which CVEs are not exploitable in your context, critical for reducing noise.
- Not sharing with customers: An SBOM you keep internal provides you with visibility. An SBOM you share with customers provides them with transparency, and is increasingly what enterprise buyers are asking for before they sign.
- Treating it as a compliance checkbox: The value of an SBOM is operational, not administrative. The organisations that benefit most are those that use it as a live tool in their vulnerability management process, not a document they attach to audit submissions.
Need Help Building Your SBOM Program?
SecComply helps organisations implement SBOM generation, continuous monitoring, and compliance mapping across ISO 27001, SOC 2, and the EU Cyber Resilience Act, as part of a complete supply chain security program.
Book a Free Consultation โ