When the SolarWinds breach exposed the depth of software supply chain vulnerability in 2020, it changed the regulatory conversation permanently. The 2021 US Executive Order on Improving the Nation’s Cybersecurity was explicit: organisations must have visibility into the components of the software they deploy — including software supplied by third-party vendors. The Software Bill of Materials (SBOM) requirement was born from that mandate.

Five years on, SBOMs have moved from a government procurement requirement to a mainstream vendor risk management expectation. If you sell software to the US government, provide cloud services, or work in regulated industries, your customers are increasingly asking for SBOMs — and your vendors should be providing them. Here’s what you need to know.

What Is an SBOM?

A Software Bill of Materials is a formal, machine-readable inventory of the components that make up a piece of software. Think of it like a nutrition label for code: it lists the open-source libraries, third-party packages, and internal components used in a software product, along with their versions and dependency relationships.

SBOMs are typically generated in one of two standard formats: CycloneDX (maintained by OWASP) or SPDX (maintained by the Linux Foundation). Both formats are machine-readable and can be ingested by vulnerability management tools to identify known CVEs in listed components automatically.

Why SBOMs Matter for Vendor Risk Management

The software supply chain is the new perimeter. The Log4Shell vulnerability (CVE-2021-44228) demonstrated that a single vulnerable open-source component — embedded in thousands of commercial and enterprise software products — could expose organisations globally within hours of disclosure. Without an SBOM, you have no way of knowing whether your vendors’ software contains a specific vulnerable component.

With an SBOM, the detection timeline compresses dramatically. When a new CVE is published, you can query your vendor SBOM repository and immediately identify which vendors use the affected component — and prioritise remediation accordingly. This is the difference between reactive and proactive software supply chain risk management.

Current SBOM Requirements and Who They Apply To

• US Federal Government: Executive Order 14028 (2021) and subsequent CISA and NIST guidance make SBOMs a de facto requirement for software sold to US federal agencies. OMB Memorandum M-22-18 extended this to cloud service providers.
• EU Cyber Resilience Act (CRA): The EU CRA, which begins applying in 2027, includes SBOM requirements for manufacturers of hardware and software products with digital elements sold in the EU market.
• NTIA Minimum Elements: The National Telecommunications and Information Administration published minimum elements for SBOMs, widely adopted as a baseline across industries.
• Healthcare: FDA guidance for medical device cybersecurity now includes SBOM expectations for device manufacturers.

How to Request and Use SBOMs from Your Vendors

Operationalising SBOM collection as part of your vendor risk program involves four steps:

1. Add SBOM requirements to vendor contracts — specify the format (CycloneDX or SPDX), frequency of updates, and coverage requirements
2. Build an SBOM repository — a centralised store for vendor-provided SBOMs, ideally integrated with your VRM platform
3. Automate vulnerability scanning — integrate SBOM data with your CVE feeds to automatically flag vulnerable components in vendor software
4. Define a response process — when a CVE is found in a vendor component, what’s the escalation and remediation path?

Findings’ vendor risk platform supports SBOM ingestion and analysis as part of its broader software supply chain risk capabilities — allowing security teams to manage SBOMs alongside traditional compliance assessments in a single workflow.

What to Ask Your Software Vendors Right Now

If you haven’t already, start with these requests to your most critical software vendors:

• “Please provide a current SBOM for [product] in CycloneDX or SPDX format.”
• “What is your process for updating the SBOM when dependencies change?”
• “How do you notify customers when a CVE is identified in a component listed in the SBOM?”
• “Do you have a vulnerability disclosure policy?”

Vendors who can answer these questions clearly are ahead of the curve. Vendors who can’t are a software supply chain risk you may need to escalate.

Get the full SBOM vendor requirements guide.

Our guide covers the current regulatory landscape for SBOMs, how to build an SBOM collection process into your vendor contracts and onboarding, and how Findings automates SBOM tracking alongside your full vendor risk program. Download free. →