Using SBOMs to Find Vulnerable Components Faster

When a serious vulnerability is announced in a popular library, the first question every security team asks is "where do we use this?" Without a component inventory, answering it means searching code repositories, asking developers and emailing vendors, which can take days. A software bill of materials (SBOM) turns that question into a lookup. If you generate SBOMs for the software you build, collect them for the software you buy, store them in one place and keep matching them against new vulnerability data, you can find affected systems in minutes. Here is how that works in practice, and where the federal requirements fit in.

What is an SBOM?

An SBOM is a machine-readable inventory of the components that make up a piece of software. Think of it as an ingredients list. Each entry names a component, its version and its supplier, plus identifiers that tools can match on, such as a package URL (purl) or a CPE name.

A good SBOM also records dependency relationships. Most modern applications pull in far more transitive dependencies (the dependencies of your dependencies) than direct ones, and those are exactly the components teams lose track of.

On its own, an SBOM says nothing about security. It is an inventory. The value for vulnerability management comes from matching that inventory against vulnerability data, continuously and at scale.

Why did SBOMs become a federal priority?

Three documents shaped the current push for SBOMs in the US. Even if you never sell to a federal agency, they set the expectations that software vendors are now building toward.

Executive Order 14028 (May 2021)

Executive Order 14028, "Improving the Nation's Cybersecurity," was signed on May 12, 2021. Section 4 focused on software supply chain security. Among other things, it called for guidance under which software producers provide purchasers with an SBOM, either directly or by publishing it on a public website.

The order also directed the Department of Commerce, working with the National Telecommunications and Information Administration (NTIA), to publish the minimum elements of an SBOM within 60 days.

The NTIA minimum elements (July 2021)

NTIA published The Minimum Elements for a Software Bill of Materials on July 12, 2021. It groups the minimum elements into three areas:

Two of the practices matter a lot for vulnerability work. "Frequency" says a new SBOM must be created whenever software is updated with a new build or release. "Known unknowns" asks authors to state where the dependency data is incomplete, so consumers don't mistake a gap for a clean result.

OMB M-22-18 and secure software self-attestation (September 2022)

The Office of Management and Budget issued memo M-22-18 on September 14, 2022. Its core requirement is that federal agencies obtain a self-attestation from software producers confirming they follow the NIST Secure Software Development Framework (SP 800-218) and NIST's software supply chain security guidance.

On SBOMs, the memo is more measured than many people assume. It does not require an SBOM for every purchase. Agencies may require one in solicitations based on how critical the software is. Any SBOM must use one of the formats named in the NTIA minimum elements report, and agencies should consider reciprocity for SBOMs a producer has already provided to other agencies.

The memo originally set deadlines of 270 days for critical software and 365 days for all software. In June 2023, OMB memo M-23-16 reset those clocks to three and six months after OMB approves a common attestation form. CISA released a draft of that form for public comment in April 2023, and as of this writing the final form has not been approved.

SPDX vs. CycloneDX: which SBOM format should you use?

The NTIA report lists three formats, but two dominate SBOM tooling. SWID tags are mainly used to identify installed software, while SPDX and CycloneDX cover most SBOM generation and exchange.

Both formats handle the NTIA data fields, and most open-source SBOM generators can produce either. Standardize on one format for the SBOMs you produce, and make sure your tooling accepts both for the SBOMs you receive. Conversion works, but some detail can be lost.

What is VEX, and how does it cut the noise?

The first time you match a full set of SBOMs against vulnerability data, the result is usually a very long list. Many entries are real components with real CVEs that pose no risk in context, because the vulnerable function is never called or the affected feature isn't compiled in.

Vulnerability Exploitability eXchange (VEX) addresses this. A VEX document is a statement from a supplier about whether a specific product is affected by a specific vulnerability. CISA's April 2023 paper, Minimum Requirements for Vulnerability Exploitability eXchange (VEX), defines four status values:

• Not affected: no remediation is required.
• Affected: action is recommended to remediate or address the vulnerability.
• Fixed: the listed product versions contain a fix.
• Under investigation: the supplier doesn't know yet.

A "not affected" statement must come with a justification, such as the vulnerable code not being present or not being in the execution path. VEX data can be expressed in CSAF, CycloneDX or OpenVEX.

For consumers, the payoff is triage speed. When a supplier's VEX says a finding doesn't apply, you can close it with evidence instead of chasing it. If you build software for customers, publishing VEX alongside your SBOMs saves everyone a lot of back-and-forth.

How do you use SBOMs to find vulnerable components?

The workflow has three core stages (generate, store and continuously match) followed by triage.

1. Generate SBOMs as part of every build

Generate the SBOM in your CI pipeline, from the same build that produces the artifact you ship. CISA's April 2023 paper on SBOM types distinguishes between SBOMs created from design documents, source code, build output, analysis of finished artifacts, deployed environments and running systems. For software you build yourself, a build-time SBOM is usually the most accurate record of what actually shipped.

A few habits make the output far more useful:

• Include transitive dependencies, not just what's listed in your manifest.
• For container images, capture operating system packages as well as application libraries.
• Populate package URLs and CPEs wherever possible, because matching depends on identifiers.
• Record the SBOM author and a timestamp, as the NTIA minimum elements expect.
• Regenerate on every release, so each version has its own SBOM.

For commercial software, ask suppliers for SBOMs during procurement and renewals. Where a vendor can't provide one, create an analyzed SBOM by scanning the installed product or image. It will be less complete, but it's a start.

2. Store SBOMs where you can query them

An SBOM sitting in a build artifacts folder won't help much during an urgent response. Store SBOMs in a central repository and tie each one to a product, a version and, ideally, the places that version is deployed. Without that link to your asset inventory, you'll know a vulnerable component exists somewhere but not where it's running.

Keep older SBOMs rather than overwriting them, since environments rarely run a single version of anything. Apply access control too, because an SBOM is a detailed map of your software's internals. Open-source platforms such as OWASP Dependency-Track can act as this repository and handle matching.

3. Match continuously against vulnerability data

This is where the speed comes from. A scan at build time only tells you about vulnerabilities known on the day you built. New vulnerabilities in components you've already shipped are disclosed all the time, so stored SBOMs need to be re-evaluated whenever vulnerability data changes.

Useful sources include:

• The National Vulnerability Database (NVD), which uses CPE names for product matching.
• OSV, an open-source database that maps vulnerabilities to package ecosystems and versions and works well with package URLs.
• Vendor and project security advisories, including VEX documents.
• CISA's Known Exploited Vulnerabilities (KEV) catalog, which is less a matching source than a prioritization signal.

Expect some matching errors. Component names and identifiers don't always line up between an SBOM and a vulnerability database, which produces both false positives and missed matches. Good identifiers at generation time reduce both.

4. Triage with context

Not every match deserves the same response. Filter first by VEX status, then prioritize using signals such as whether the vulnerability is being exploited (KEV), whether the affected system is exposed to the internet and whether the vulnerable code is actually reachable. Route each confirmed finding to the team that owns the product.

Once a fix ships, the rebuild produces a new SBOM, and re-matching confirms the vulnerable version is gone. That SBOM becomes the baseline for the next round.

What slows SBOM programs down?

SBOMs are useful, but the gaps are worth planning for:

• Uneven quality. Missing versions, vague supplier names and absent identifiers all weaken matching.
• Few supplier SBOMs. Many vendors don't provide SBOMs yet, and those that do vary in format and depth.
• Drift. The SBOM for a build doesn't always match what's running, especially where systems are patched in place.
• Volume. Without VEX and prioritization, matching output can swamp the team that has to act on it.

None of these is a reason to wait. A partial inventory you can query today beats a complete one that doesn't exist.

Frequently asked questions

Do we need SBOMs if we don't sell to the federal government?

Most private organizations aren't legally required to produce SBOMs. But the operational benefit, answering "where are we affected?" quickly, applies to anyone who builds or runs software. Federal purchasing requirements also mean more vendors will be able to supply SBOMs when you ask.

How often should an SBOM be regenerated?

Every time the software changes. The NTIA minimum elements say a new SBOM should be created for each new build or release, including builds that only update a dependency. Matching against vulnerability data, by contrast, should run continuously against the SBOMs you already hold.

Is it risky to share SBOMs?

An SBOM reveals what's inside your software, which is why access control is one of the NTIA practices. Attackers can often fingerprint components by other means anyway, so the defensive value usually outweighs the exposure. Share SBOMs under agreed terms rather than publishing everything by default.

Can a vulnerability scanner replace an SBOM?

The two overlap, and many scanners build an inventory internally. The difference is persistence. A scan is a point-in-time result, while a stored SBOM lets you re-check every past and current release against new vulnerability data without rescanning anything.

Next steps

1. Pick one SBOM format for what you build and add SBOM generation to your CI pipelines.
2. Set up a central store and link each SBOM to the systems where that version is deployed.
3. Schedule continuous matching against NVD and OSV data, and use KEV as a priority signal.
4. Add SBOM and VEX requests to your procurement and vendor renewal questions.
5. Test the process. Pick a widely used library and time how long it takes to find every place you run it.