SBOM and Software Transparency: The CISO's 2…

Software Bills of Materials have been required for US federal contractors since the 2021 executive order on cybersecurity. What’s changed in 2026 is the scope: SBOMs are now demanded by enterprise procurement teams, required under the EU Cyber Resilience Act for connected products, and referenced in NIS2 compliance frameworks. The CISO who hasn’t built a position on SBOM is increasingly behind the curve — not because regulators have uniformly mandated it, but because customers and partners are starting to ask for it.

What an SBOM Actually Is — and Isn’t

An SBOM (Software Bill of Materials) is a machine-readable inventory of the components that make up a piece of software: open-source libraries, proprietary dependencies, third-party modules, and their transitive dependencies. The two dominant formats are SPDX (SBOM standard from the Linux Foundation, now ISO/IEC 5962) and CycloneDX (OWASP-maintained, increasingly preferred for security use cases).

What an SBOM is not: a vulnerability assessment. An SBOM tells you what components are in a product. It doesn’t tell you which ones are exploitable, which ones have been exploited, or what to do about it. The operational value of an SBOM depends on what you do with it after generation — specifically, running it against vulnerability intelligence feeds (NVD, OSV, GitHub Advisory Database) to identify known vulnerabilities in the components it lists.

The companion standard that tells you what to do with SBOM vulnerability findings is VEX (Vulnerability Exploitability eXchange). A VEX statement says, for a given CVE affecting a component in your product: is the product exploitable, not exploitable, being fixed, or under investigation? Together, SBOM and VEX give customers a structured answer to “what does this vulnerability mean for your product I’m running?”

The Regulatory Landscape in 2026

US federal supply chain: NIST SP 800-218 (SSDF) and the CISA Secure Software Development Attestation Form require federal software suppliers to attest that their development practices meet SSDF requirements. SBOM generation is referenced in SSDF and increasingly expected alongside attestation. The Office of Management and Budget (OMB) M-22-18 and M-23-16 memos formalised the requirements for critical software suppliers.

EU Cyber Resilience Act: The CRA, with manufacturers’ obligations applying from late 2027, requires producers of products with digital elements to document components (explicitly referencing SBOMs) and notify ENISA and national authorities of actively exploited vulnerabilities. For CISOs in UK and EU organisations that purchase or develop connected products, the CRA is the operative regulation — and it applies regardless of whether your software is sold to governments.

NIS2: NIS2’s Article 21 requires entities to address supply chain security including the “security of software and hardware supply chains.” ENISA guidance implementing NIS2 references SBOM and software transparency as mechanisms for supply chain risk management. National competent authorities in Germany and the Netherlands have begun asking about software inventory practices in supervisory assessments.

UK Cyber Security Resilience Bill: Currently in consultation, the Bill includes provisions for software supply chain transparency that are expected to reference SBOM practices. CISOs with operations in the UK should track this legislation through 2026.

The Three SBOM Positions Your Organisation Needs

Most CISOs need to address SBOM from three angles simultaneously:

As a consumer: You receive software from vendors. Do you require SBOMs from your critical software suppliers? Can you ingest and act on the SBOMs you receive? This is becoming a procurement and contract question. Enterprise procurement teams are adding SBOM delivery obligations to software contracts, particularly for security-critical products, cloud infrastructure components, and anything that touches regulated data.

As a producer: If your organisation develops software — internal tools, customer-facing applications, embedded firmware — your customers and enterprise buyers are increasingly asking for SBOMs. If you sell to US federal agencies or large enterprises with mature supplier risk programmes, this may already be a contract requirement.

As an operator: You run software in your own environment. Do you have visibility into what components you’re running, and can you rapidly determine your exposure when a major open-source vulnerability is published (the next Log4Shell scenario)? This is fundamentally an asset management and vulnerability management question, and SBOM is one mechanism — alongside SCA tools — for answering it.

Building the Programme

Start with SCA Tooling, Not SBOM Generation

If your development teams don’t already run software composition analysis (SCA) tools, that’s the first step. SCA tools (Snyk, FOSSA, Black Duck, GitHub Dependabot, Renovate, OSV-Scanner, Trivy, Grype) scan your codebases and build artefacts for open-source dependencies and known vulnerabilities. The SBOM is an output of this process, not a separate activity.

Most modern SCA tools can export in CycloneDX or SPDX format. Integrate this into your CI/CD pipeline so that an SBOM is generated with every build, signed with your code signing key, and stored alongside the release artefact.

Define Minimum SBOM Requirements for Vendors

Procurement-side SBOM requirements should specify:

Format: CycloneDX 1.6 or SPDX 2.3 (both are current versions as of 2026)
Content: package name, version, PURL (Package URL, the machine-readable identifier), license, supplier, and ideally transitive dependencies
Freshness: SBOMs should be current to within 30 days of product release, or regenerated on significant update
VEX: require VEX statements for Critical and High CVEs affecting components listed in the SBOM

Put these requirements in your standard supplier security addendum. Most large software vendors can now produce SBOMs for their products — asking for them is more about having the contractual requirement than about the vendor’s technical capability.

Vulnerability Correlation Workflow

An SBOM is only operationally useful if you can run it against vulnerability intelligence. The workflow:

Ingest SBOM (SPDX or CycloneDX format) into your vulnerability management platform or a dedicated tool (DependencyTrack is widely used and open-source)
Match PURLs against NVD, OSV.dev, and GitHub Advisory Database
Generate a vulnerability report showing: CVE, CVSS score, affected component version, fixed version if available
Triage using VEX statements where provided by the vendor
Feed findings into your vulnerability management workflow with the same prioritisation applied to other vulnerabilities

The “ingest, correlate, triage” workflow is the missing piece in most SBOM programmes. Generating an SBOM without the downstream correlation step produces a document that no one reads.

The Board-Level Message

The SBOM conversation at board level is a supply chain risk and regulatory compliance story. The questions to answer:

Do we know what third-party software components are running in our critical systems?
When the next Log4Shell-scale vulnerability is published, how quickly can we determine our exposure?
Do our major software vendors provide SBOMs? Do our contracts require them to?
Are we meeting our attestation obligations under applicable regulations?

The quantitative frame: in the Log4Shell incident (December 2021), organisations with mature SCA/SBOM practices were able to determine their exposure in hours. Organisations without this visibility spent weeks on manual discovery. Given that CISA tracked active exploitation within days of disclosure, the time window for response directly determines whether the vulnerability is exploited in your environment or not.

Practical First Steps

For CISOs who haven’t yet started: pick one high-risk application or product and run an SCA tool against its current build. The output — a list of components, versions, and known vulnerabilities — is your baseline SBOM. The exercise will also surface findings that almost certainly warrant attention. Use that output to build the business case for a broader programme.

SBOM and Software Transparency: The CISO's 2026 Compliance and Risk Guide