CISA’s new SBOM standards go beyond checkbox security

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) is updating its recommendations for the minimum elements in a software bill of materials, a change that could transform SBOMs from being a compliance checkbox to a strategic tool for reducing supply chain risk.

The recommendations, currently in draft form, are open for public comment.  They represent the first significant update since the National Telecommunications and Information Administration (NTIA) issued its original “Minimum Elements for a Software Bill of Materials” guidance in July 2021. More importantly, they signal how federal expectations around software transparency are evolving.

For enterprises, the changes could mean adjusting internal practices to align with emerging federal guidance, strengthening supply chain visibility, and preparing for the possibility of more formal requirements in the future.

Here’s what you need to know.

Get the White Paper: Go Beyond the SBOM

What’s in the first major SBOM update?

Ensar Seker, CISO at SOCRadar, said that since the original NTIA guidance in 2021, real-world incidents — from Log4Shell to SolarWinds to this month’s big npm compromise — have “[driven] home the fact that most organizations still lack visibility into what’s actually in the software they run.”

CISA’s update reflects not just evolution in technology, but in threat actor sophistication and geopolitical tension surrounding software supply chains.

Ensar Seker

The proposed changes are recognition that the 2021 baseline, while a good start, has proved insufficient in practice, Seker said.

At a high level, the key updates in CISA's 2025 minimum elements for an SBOM include new mandatory fields such as “component hash” — or unique cryptographic fingerprint, license information, tool name, and generation context such as how, when, and by whom the SBOM was created. 

Other minimal requirements include information on the SBOM author, the component version, software identifiers, dependencies, and known unknowns. CISA has also proposed changing the “supplier name” field to “software producer,” and it provides a fallback to “unknown provenance” when that information is not reliably available.

More than an ingredients list 

Together, the updates represent an effort to move SBOMs from being an inventory-focused mindset to something organizations can use to actually tackle software verifiability and trust, Seker said. Adding fields such as “component hash,” “license,” and “generation context” shifts SBOMs toward forensic readiness and machine learning-actionable integrity.

The hash, in particular, is critical because it gives defenders something they can verify independently. Knowing a component’s version isn’t enough if you can’t trust where it came from or how it was built.

Ensar Seker

Seker added that the shift from “supplier name” to “software producer” and the provision for “unknown provenance” were subtle but revealing changes. “CISA is acknowledging that in today’s world, software often passes through multiple hands, and provenance is either missing or intentionally obfuscated,” he said.  

The renaming of “depth” as “coverage” and the formalizing of “known unknowns” also reflects a more mature understanding about what information can and cannot be included in an SBOM. “That kind of epistemic humility is foundational to software risk management,” Seker said.

CISA’s update reflects not just evolution in technology, but in threat actor sophistication and geopolitical tension surrounding software supply chains.

Ensar Seker

What’s in a hash? 

Jason Soroko, senior fellow at Sectigo, said hashing is one of the most critical advancements in CISA’s proposed new SBOM guidance. He said it enables artifact integrity verification, deduplication, and consistent matching across repositories and scanners. 

Similarly, CISA’s plans to make licenses a required field embeds compliance risk management into daily operations, Soroko said. Other updates such as the “tool names” and “generation context” fields enhance reproducibility and trust, while clarified identifiers, versions, dependencies, coverage metrics, and documented unknowns reduce ambiguity and prevent gaming, Soroko said. 

SBOM adoption has shifted from pilot programs to production deployment, driven by supply chain disruptions and procurement requirements. This transition emphasizes concrete needs — provenance tracking, integrity verification, and automation — over abstract concepts.

Jason Soroko

CISA described its new SBOM guidance as reflecting the expanded capabilities of SBOM tools since the original 2021 NTIA recommendations. It also cited the growing maturity of SBOM use and a higher awareness that more granular SBOM data is of value. The goal in updating the guidance is to promote the use of SBOMs as a meaningful tool for reducing software supply chain risk, CISA said. The agency has set a deadline of October 3, 2025, for stakeholders to comment on the draft guidelines.

How will the new SBOM standard impact enterprises?

For enterprise security teams and other stakeholders, the updated SBOM guidance creates an opportunity to integrate SBOMs more tightly into vulnerability management and compliance workflows. It could help reduce response times to emerging threats and strengthen resilience across the supply chain. Many organizations will need to take another look at how they produce, store, and distribute SBOMs, especially across CI/CD pipelines.

Internal teams will need to establish coverage targets, automate validation and signing processes, and implement reason codes for tracking known unknowns, Sectigo’s Soroko said. Organizations should also anticipate stricter conformance requirements in RFPs and audits, along with accelerated adoption of the new minimal requirements by vulnerability management tools. 

The draft standard prioritizes establishing required hash sets with collision policies, strengthening container image and build metadata requirements, and clarifying guidance for dynamic and runtime dependencies, Soroko said. Organizations that follow the guidelines, he said, will need to “ap all elements precisely to SPDX and CycloneDX field names, define distribution trust models with signing and attestation profiles, establish minimum coverage thresholds, and create distinct profiles for lightweight versus comprehensive SBOMs.” 

Organizational stakeholders should also provide clear guidance for modular builds, reproducible builds, and partial disclosure with auditable justifications, Soroko said.

New standards raise the bar for software vendors

CISA’s new guidance, if adopted as proposed, would raise the bar for software vendors, which would need to ensure that the SBOMs they generate are more detailed, accurate, and machine-readable. To do that, vendors will need to adopt tools that capture detailed metadata and track the chain of custody. They will also need to clearly declare software licenses and the provenance of any third-party components in their products, said Alex Kreilein, vice president of product security and public-sector solutions at Qualys.

SBOMs are now attestations of origin and integrity. This raises expectations for accuracy and transparency, with increased market and regulatory scrutiny likely to follow

Alex Kreilein

To stay competitive, many vendors will need to update their pipelines and tooling to produce richer metadata, because consumers increasingly are going to demand more reliable inputs for security operations, compliance, and procurement decisions, Kreilein said.

Progress is welcome but leaves some gaps

Several security experts said CISA’s proposed SBOM requirements are a step in the right direction but would leave some gaps. SOCRadar’s Seker said he would like to see more clarity around the disclosure requirements for transitive dependencies and how comprehensively SBOMs will need to unpack complex packaging systems such as container layers or bundled JavaScript. Similarly, signing requirements need to be more explicit. If organizations expect SBOMs to reflect the reality of software, they need to be signed, traceable, and tamper-evident, Seker said.

CISA should also include guidance on how to operationalize SBOM ingestion, particularly for smaller organizations that don’t have dedicated supply chain risk teams. “Minimum fields are great, but minimum tooling recommendations would make adoption easier,” Seker said.

To be really useful, said Qualys’ Kreilein, SBOMs must also be integrated with data from the Vulnerability Exploitability eXchange (VEX) and the Common Security Advisory Framework (CSAF). While SBOMs provide the inventory, VEX provides exploitability context, and CSAF standardizes how vendors communicate security information. Together, data from the three sources would help organizations focus on the issues that matter.

Without integration with VEX and CSAF, SBOMs are likely only going to create more noise and unnecessary escalations for defenders, Kreilein said. “Expanding these connections would ensure SBOMs drive outcome-oriented improvements rather than becoming compliance and support overhead that taxes already resource-constrained teams.”

What about added complexity?

Jeff Williams, CTO and co-founder of Contrast Security, is concerned that the proposed new minimum SBOM elements could add a level of complexity that could slow adoption. By adding hashes, licenses, and tool context, CISA is acknowledging that SBOMs must be actionable for security and not just for inventory. But in shifting SBOMs from ingredients lists to forensic labels, new problems could arise when the hashes, provider names, relationships, and provenance are not clear. 

Even the idea of a hash is complex when applied in real world software environments. These problems create friction to using SBOMs right when it will be most damaging to adoption.

Jeff Williams

Williams said he wants CISA to acknowledge the role that runtime SBOMs can play in shoring up software security. Runtime SBOMs are a particularly effective way of capturing which components are actually active, he said. “In our studies, 62% of open-source libraries are inactive — never loaded, never invoked.” 

Anyone who can run the software can, and should, create a runtime SBOM, Williams said. The vendor should know what components are actually present in runtime and the consumer should generate their own, too. 

The consumer can check, compare, and manage their SBOMs even for software where the vendor doesn’t provide one. Runtime equals reality.

Jeff Williams

Learn about the rise of the CycloneDX's XBOM, which includes the ML-BOM, SaaSBOM, and CBOM for extending software transparency in the modern era.