What an SBOM actually is
Modern software is not built from scratch. Almost every application your team builds relies on dozens, sometimes hundreds, of external libraries and open-source components. A web service might use a JSON parsing library, a logging framework, an authentication module, and a database connector, none of which your team wrote, and all of which come from external sources.
An SBOM is the complete list of all of those components. It includes what they are, who made them, which version is in use, what licence they carry, and how they relate to each other.
Think of it like a nutritional label on packaged food. The label tells you exactly what's inside. Not just the main ingredient, every ingredient, its source, and the quantities. You can check for allergens, understand what you're consuming, and make informed decisions about whether it meets your standards.
An SBOM does the same thing for software. It tells you exactly what is inside an application. Not just the code your team wrote, every library, every dependency, every version. When a new vulnerability is discovered in any component anywhere in the world, you can immediately check your SBOM to see whether you're affected.
Why "bill of materials" is the right term
The phrase comes from manufacturing. A car's bill of materials lists every part: the bolts, the panels, the engine components, the wiring. If a manufacturer discovers that a specific batch of bolts has a defect, they use the bill of materials to find every vehicle that used those bolts. An SBOM does the same for software. When a vulnerability is discovered in a component, you use the SBOM to find every product and service that contains it.
Why it became urgent, two events that changed everything
Software teams have managed dependencies informally for years. Most engineers know roughly what libraries they're using. But "roughly" and "exactly" are two different things when a critical vulnerability is discovered and you have hours to respond.
Two events made this concrete in a way that moved SBOMs from a good idea to a requirement.
The events that accelerated SBOM adoption
SolarWinds (2020) and Log4j (2021): what they revealed about software visibility
SolarWinds, December 2020. Attackers gained access to SolarWinds' build infrastructure and inserted malicious code into a routine software update called Orion. The update was cryptographically signed and legitimate-looking. Around 18,000 organisations installed it, including multiple government agencies and major technology companies. The attack worked because the compromised code was inside trusted software. Nobody was checking what was inside the updates they installed.
Log4j, December 2021. A critical vulnerability was discovered in Log4j, a Java logging library so widely used that it was embedded in applications across virtually every industry. The vulnerability affected hundreds of millions of devices globally. The urgency was immediate: organisations needed to find every application they ran that contained Log4j, in any version.
Organisations that had SBOMs for their applications could query them and get an answer in minutes. They knew which services used Log4j, which versions, and which ones needed patching immediately. Organisations without SBOMs spent days or weeks manually auditing code repositories, running scans, and checking with development teams. Some discovered they had been running the vulnerable version in production for months without knowing.
TechRadiant analysis: both events revealed the same problem. Organisations did not have sufficient visibility into the composition of their own software. SBOMs are the systematic solution to that visibility gap. The White House issued Executive Order 14028 in May 2021, mandating SBOMs for all federal software procurement, four months before Log4j made the issue impossible to ignore.
The numbers behind these events explain why adoption accelerated so quickly. IBM and Gartner research consistently shows that over 90% of modern software applications contain open-source dependencies, with around 74% containing at least one high-risk dependency. The software most organisations run is almost entirely built on components they did not write and may not be actively tracking.
What an SBOM actually contains
An SBOM is not a free-text description of what's in your software. It is a structured, machine-readable document that follows a standardised format. That standardisation is what makes it useful: automated tools can read it, query it, and cross-reference it against vulnerability databases.
The core attributes that every SBOM must include, as defined by the US National Telecommunications and Information Administration (NTIA) and expanded by CISA's 2024 guidance, are these:
Component identity
Supplier name and component name
Who made the component and what it is called, using the original supplier's name. This allows components to be uniquely identified across different systems and databases.
Version tracking
Version of the component
The specific version in use. Vulnerabilities are almost always version-specific. Knowing you use Log4j is not enough. Knowing you use Log4j 2.14.1 tells you exactly whether you're affected.
Unique identifiers
CPE, SWID tags, or Package URLs
Standardised identifiers that allow the component to be matched against vulnerability databases (like the National Vulnerability Database) automatically. Without these, matching vulnerabilities to components requires manual work.
Integrity verification
Cryptographic hash
A unique fingerprint for each component. If a component is modified after the SBOM is generated, the hash will not match. This is how you verify that what's running is what was documented.
Relationship mapping
Dependency relationships
How components connect to each other. This includes both direct dependencies (libraries your code explicitly calls) and transitive dependencies (libraries that your libraries depend on). Transitive dependencies are often where vulnerabilities hide.
Legal compliance
Licence information and copyright notices
The legal terms under which each component can be used. Open-source licences vary widely. Some (like GPL) have requirements that affect how your software can be distributed. Knowing what licences are in use prevents legal surprises at product launch.
The transitive dependency problem
When you add a library to your project, that library often depends on other libraries, which depend on others still. These are transitive dependencies. Your project might directly depend on five packages, but transitively depend on two hundred. Most vulnerabilities in supply chain attacks are in transitive dependencies, not direct ones. An SBOM must capture the full dependency tree, not just the top-level packages you explicitly chose.
An SBOM needs to be machine-readable to be useful. Humans cannot manually check 200 dependencies against a live vulnerability database every time a new CVE is announced. The machine does that. For the machine to do it, the SBOM must be in a standardised format.
CISA's 2024 guidance recognises two primary formats. Both are open standards, both are widely supported by tooling, and both can represent the same information. The choice between them usually comes down to what you're optimising for.
In practice, most organisations choose CycloneDX for security-focused DevSecOps pipelines because of its tight integration with vulnerability management tools. SPDX tends to be preferred in environments where licence compliance and open-source governance are the primary drivers. Tools like Syft, Trivy, and cdxgen can generate SBOMs in either format from most build environments.
Who requires it and which industries are affected
SBOM adoption started as a best practice and is becoming a legal requirement in a growing number of contexts. The pace of regulatory change has accelerated significantly since 2021.
US Federal Government, Executive Order 14028 (2021)
Any software vendor selling to US federal government agencies must provide an SBOM. This was the first formal government mandate and has served as a model for industry-specific requirements globally.
Status: Mandatory for federal software procurement. CISA expanded guidance published September 2024.
Healthcare, FDA Medical Device Requirements
The FDA requires SBOMs for medical devices as part of premarket submissions. Medical devices run software and connect to hospital networks, a compromised device can affect patient safety directly.
Status: Mandatory for medical device premarket submissions. IMDRF also recommends SBOM adoption internationally.
Financial Services, PCI DSS v4.0
Payment Card Industry Data Security Standard version 4.0 includes requirements for software inventory management. Organisations handling payment data need to demonstrate they can identify and track the components in their payment systems.
Status: PCI DSS v4.0 enforcement began March 2025.
EU Cyber Resilience Act
The European Union's Cyber Resilience Act, which entered into force in December 2024, includes SBOM requirements as part of mandatory security documentation for products with digital elements sold in the EU market.
Status: Requirements phasing in through 2027. Affects any organisation selling digital products in EU markets.
Enterprise procurement requirements (private sector)
Gartner predicted that by 2025, 60% of organisations building or procuring critical infrastructure software would mandate SBOMs, up from under 20% in 2022. Large enterprises and financial institutions increasingly request SBOMs from their software vendors as part of security due diligence and procurement requirements.
Status: Growing private sector adoption driven by supply chain risk management and customer requirements.
Need help with your security pipeline?
Find DevSecOps agencies verified on supply chain security practices
TechRadiant verifies DevSecOps consultants on documented pipeline outcomes including SBOM generation, dependency scanning, and supply chain security. Find a team who has done this before.
SCA vs SBOM: they work together, not instead of each other
Two terms that often get confused are SCA (Software Composition Analysis) and SBOM. They are closely related but they are not the same thing, and you need both.
SCA, Software Composition Analysis
Active scanning process
- Actively scans code during development to find vulnerabilities
- Focuses primarily on open-source components and third-party libraries
- Provides real-time alerts when a dependency has a known CVE
- Runs as part of the CI/CD pipeline on every build or commit
- Optimised for developer workflows and immediate remediation feedback
SBOM, Software Bill of Materials
Standardised inventory document
- A structured document listing all software components in standardised format
- Covers all components including proprietary code, not just open source
- Shareable with customers, regulators, and procurement teams externally
- Provides the foundation for compliance documentation and audits
- Enables cross-organisation supply chain visibility
The relationship between them is practical: SCA tools are often how you generate the SBOM. The tool scans your code, identifies all components, and outputs a standardised SBOM document in SPDX or CycloneDX format. The SCA tool then continues to monitor those components against live vulnerability databases, alerting you when something new is discovered. The SBOM is the artefact you share and store. The SCA tool is the process that creates and maintains it.
How your team gets started
Most teams implementing SBOMs for the first time find the concept more intimidating than the actual implementation. The tooling is mature, the formats are well-documented, and the hardest part is usually deciding where to start rather than the technical work itself.
Here is a practical three-phase approach that works for most engineering teams.
1
Pick one application and generate your first SBOM
Choose one application, ideally something externally facing or business-critical, and run an SBOM generator against it. Tools like Syft (from Anchore), Trivy, or the CycloneDX CLI can scan most project types and output a complete SBOM in minutes. Read the output. You will almost certainly find components you didn't know were there.
Tools to start with: Syft, Trivy, cdxgen, CycloneDX CLI, all open-source and free
2
Integrate SBOM generation into your CI/CD pipeline
Once you've done it manually, automate it. Add SBOM generation as a step in your build pipeline so that every build produces a fresh SBOM automatically. Store the SBOM alongside the built artefact. GitHub Actions, GitLab CI, and Jenkins all have integrations for the major SBOM tools. This ensures your SBOM is always current with what's actually shipping.
Most CI/CD platforms have ready-made integrations for Syft and Trivy, typically a single YAML step
3
Connect your SBOM to a vulnerability feed
An SBOM that exists but isn't connected to a vulnerability database is only half useful. Connect your SBOMs to a feed like the National Vulnerability Database (NVD) or OSV (Open Source Vulnerabilities). When a new CVE is published that affects a component in any of your SBOMs, you want an alert, not a discovery days later. Tools like Grype, Dependency-Track, or FOSSA can do this continuously.
Dependency-Track (OWASP) is the most popular open-source SBOM management platform for this workflow
4
Expand across your full application portfolio
Once the pipeline integration is working for one application, it takes minimal effort to apply it to others. Work through your portfolio methodically, prioritising by exposure: customer-facing applications first, internal tools after. Establish a governance policy for how SBOMs are stored, who has access, and what happens when a vulnerability is flagged in a production component.
CISA's SBOM guidance includes a maturity model, use it to assess where you are and what "good" looks like for your organisation
On handling unknown and incomplete information
In practice, you will encounter components you cannot fully document. Legacy software, proprietary third-party libraries, or components under contractual non-disclosure agreements may not reveal all their internal dependencies. The right approach, per CISA's 2024 guidance, is to document what you know and explicitly mark what is unknown or incomplete rather than omitting it. An SBOM that says "dependency information for this component is unknown" is more useful than an SBOM that silently skips it. Downstream consumers of your SBOM can make informed decisions about risk when they can see what is and isn't documented.
The goal is visibility, not perfection. An incomplete SBOM that you continuously improve is dramatically more useful than a perfect SBOM you never get around to creating. The Log4j response made this obvious: the teams that could query even a partial SBOM were hours ahead of the teams who had to start from nothing. For the DevSecOps consultants who help teams build SBOM pipelines into their existing CI/CD environments, TechRadiant's verified DevSecOps agency index covers teams evaluated on documented supply chain security practice.
Common questions answered
What does SBOM stand for and what does it do?
SBOM stands for Software Bill of Materials. It is a structured inventory of every component, library, and dependency inside a software application, recorded in a machine-readable format. Its primary function is to give you immediate visibility into what your software is made of, so that when a vulnerability is discovered anywhere in the software supply chain, you can quickly determine whether you're affected and act on it immediately rather than spending time figuring out what you're running.
Is an SBOM legally required?
It depends on your industry and who you sell software to. In the United States, software sold to federal government agencies requires an SBOM under Executive Order 14028 (2021). The FDA requires SBOMs for medical device premarket submissions. PCI DSS v4.0 includes software inventory requirements for payment processing systems. The EU Cyber Resilience Act, which phased in from December 2024, includes SBOM requirements for digital products sold in EU markets. Beyond these mandates, large enterprise customers and financial institutions increasingly request SBOMs from software vendors as part of procurement security requirements. If you sell software to regulated industries or government entities, you almost certainly need one.
What is the difference between SPDX and CycloneDX?
Both are standardised, machine-readable SBOM formats recognised by CISA. SPDX was developed by the Linux Foundation and is widely used in open-source ecosystems, with particular strength in licence compliance documentation. CycloneDX was developed by OWASP specifically for application security and supply chain risk management, with strong native support for vulnerability management workflows and VEX (Vulnerability Exploitability eXchange) integration. In practice, most security-focused DevSecOps teams choose CycloneDX because of its tighter integration with vulnerability scanning tools. SPDX tends to be preferred in environments where licence compliance and open-source governance are the primary concerns. Most SBOM generation tools support both formats and can output either on request.
What tools can generate an SBOM?
Several mature, widely-used open-source tools generate SBOMs. Syft (from Anchore) is one of the most popular, supporting most package ecosystems and container images, outputting in both SPDX and CycloneDX formats. Trivy is widely used in container and cloud-native environments and can generate SBOMs alongside its vulnerability scanning. CycloneDX CLI and cdxgen provide language-specific SBOM generation for popular ecosystems including Python, Node.js, Java, Go, and .NET. For managing SBOMs after generation, Dependency-Track (OWASP) is the most popular open-source platform, providing continuous monitoring against vulnerability databases and dashboards for tracking component risk across your application portfolio. All of these tools are free and open-source.
What is a transitive dependency and why does it matter for SBOMs?
A transitive dependency is a dependency of a dependency. When you add Library A to your project, Library A might depend on Library B, which depends on Library C. Libraries B and C are transitive dependencies of your project. You did not choose them explicitly, but they are part of your software and their vulnerabilities affect you. Most supply chain attacks and many major vulnerabilities specifically target transitive dependencies because they are less visible and less actively monitored than direct dependencies. An SBOM must capture the complete dependency tree, including all transitive dependencies, to be useful. A shallow SBOM that only lists direct dependencies can miss the majority of your actual attack surface.
What is VEX and how does it relate to SBOMs?
VEX stands for Vulnerability Exploitability eXchange. It is a companion standard to SBOMs that addresses a practical problem: just because your SBOM shows that you use a component with a known vulnerability does not necessarily mean you are affected. The vulnerability might only be exploitable through a code path you do not use, or in a configuration you do not run. VEX documents the actual exploitability status of known vulnerabilities for specific software. It tells downstream users and customers: "Yes, we use this component with this CVE, but here is why it does not affect us in our configuration." This distinction reduces false positives in automated vulnerability management and helps security teams focus on real risks rather than theoretical ones.
