A software bill of materials is a machine-readable list of the components inside a product, including open-source libraries and their versions, like an ingredients list. When a flaw in a common component is announced, an SBOM lets you check quickly whether a vendor's product contains it.

Does an SBOM prove software is secure?

No. It shows what is inside, not whether a component is reachable or exploitable, whether it has been patched, or whether the vendor's build process is secure. Pair the request with questions about patching, vulnerability disclosure and update-channel protection.

What should we ask a software vendor besides an SBOM?

Ask how often the SBOM is updated and in which format (SPDX or CycloneDX), how fast critical vulnerabilities are patched, whether they publish advisories and have a disclosure policy, how builds and updates are signed, which subprocessors touch your data, how long versions are supported, and how they will notify you of an incident.

What do the NTIA minimum elements require?

NTIA's baseline covers data fields such as supplier, component name, version, identifiers, dependency relationships, author and timestamp; automation support through standard formats like SPDX, CycloneDX or SWID; and practices such as update frequency, dependency depth and distribution. CISA keeps further guidance on its SBOM page.

What if a vendor cannot provide an SBOM?

Not every vendor can yet, and small vendors may need time. A clear plan, a security contact and a record of prompt fixes are still meaningful. Rank vendors by what they hold, and write notification windows and patch timelines into contracts and renewals.

Third-Party Software Risk and SBOMs

Key takeaways

An SBOM is a nested inventory of the components in a piece of software, like an ingredients list.
NTIA's minimum elements define the baseline data fields, the automation support and the practices around producing SBOMs. CISA hosts further SBOM resources.
An SBOM does not prove software is secure. It helps you find where a vulnerable component lives, quickly.
Pair the SBOM request with questions on patching, vulnerability disclosure, and how the vendor secures its own build and update process.

Start with the answer: a software bill of materials (SBOM) is a machine-readable list of the components inside a product, including open-source libraries. When a serious flaw in a common library is announced, an SBOM lets you check in minutes whether a vendor's product contains it, instead of waiting for the vendor to investigate. Ask for one, but do not stop there. Ask how the vendor finds, fixes and tells you about vulnerabilities, too.

Why third-party software is a risk

Modern applications are assembled. A typical product pulls in many open-source and commercial components, and those pull in more. A flaw in one deep component can reach thousands of products at once. You also depend on the vendor's own build systems and update channels: if an attacker compromises those, a trusted update becomes the delivery route. You cannot inspect every vendor, but you can ask better questions and keep your own inventory.

What an SBOM contains

The NTIA report on the minimum elements for an SBOM sets a baseline in three groups. Data fields: supplier name, component name, version, other unique identifiers, dependency relationship, the author of the SBOM data and a timestamp. Automation support: the SBOM must be in a standard machine-readable format so tools can read it, and the common formats are SPDX, CycloneDX and SWID tags. Practices and processes: how often SBOMs are produced, how deep the dependencies go, how they are distributed, how access is handled and how errors are managed. CISA maintains an SBOM resource page with guidance, and its work has continued to extend what a good SBOM includes, so check the current material.

What an SBOM does and does not do

It helps you answer, quickly, whether a named component is present. It supports vulnerability management, license review and procurement checks. It does not tell you whether a component is actually reachable or exploitable in that product, whether the vendor has patched it or whether the vendor's own development is secure. Treat it as an inventory, and treat the vulnerability data you match against it as a separate input.

Questions to ask a software vendor

Can you provide an SBOM in SPDX or CycloneDX format, and how often is it updated, for each release?
How do you track vulnerabilities in your components, and how fast do you patch critical ones?
Do you publish security advisories, and how will we be notified?
Do you have a coordinated vulnerability disclosure policy and a contact for reports?
How are builds produced and signed, and how do you protect the update channel?
Which subprocessors and hosted services touch our data, and where?
What happens at end of support, and how long do you maintain a version?
How will you tell us if you have an incident that affects our data?

What to do with the answers

Keep SBOMs in a place you can search. When a new advisory appears, search for the component name across your vendors, then ask the affected ones for their assessment and timeline. Rank vendors by what they hold: a tool with access to customer data or production systems deserves a deeper review than a marketing plugin. Put the commitments into contracts and renewals: notification windows, patch timelines and the right to receive updated SBOMs.

Formats and exchange matter in practice. Ask whether the SBOM covers the whole product or only the top layer, whether it lists transitive dependencies, and whether it is delivered with each release or only on request. An SBOM that is a year old is a history lesson, not an inventory. Some vendors also publish vulnerability exploitability statements alongside the SBOM, which say whether a listed flaw actually affects the product. That is a useful extra, and it saves your team from chasing alerts that do not apply.

Be realistic

Not every vendor can produce an SBOM yet, and small vendors may need time. A clear plan, a security contact and a record of prompt fixes are still meaningful. Your own software matters too: generate SBOMs for what you build, and scan dependencies in your build pipeline.

Where we help

Our cybersecurity team builds vendor questionnaires, reviews SBOMs and software supply chain controls, and sets up dependency scanning in development pipelines. See our Cybersecurity service to start. Standards and tooling in this area are changing quickly, so we confirm the current guidance at each review.

Sources

This article is general information, not legal advice. Standards and vendor documentation change; confirm current requirements with your regulator, counsel and IT provider. Last reviewed November 9, 2026.

Keep reading

Next · SecurityWhat a Code and Endpoint Security Review Finds in the First 24 HoursMost first-day findings are not exotic. They are leaked credentials, outdated libraries, missing authorization checks and files that should never have been public. Here is what to expect, and why an engineer must confirm each one.7 min read

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity

Third-Party Software Risk: SBOMs and What to Ask Vendors