New SBOM Requirements: CISA Mandates Digital Signature and Unlimited Dependency Coverage

On July 31, 2026, CISA, together with 16 government entities from four continents, published the updated guidance on minimum elements for a Software Bill of Materials. The document replaces the 2021 NTIA guidelines and introduces ten new mandatory fields, shifts from the concept of “depth” to “coverage,” and requires a digital signature to attest integrity and authenticity. The following day, the agency also released a separate guide on open source security.

Ten Fields That Reshape the Software Inventory

The new guidance adds ten previously absent elements. The most impactful of these is the digital signature for the SBOM, designed to guarantee its integrity and authenticity throughout the supply chain. Alongside it comes the obligation to indicate the name and version of the tool used to generate the inventory, as well as other data that make the origin of every component traceable.

The initial draft, dating back to 2025, was refined after receiving comments from over 90 organizations, including Google, Microsoft, and AWS. The result is a set of requirements that, while formalizing already common practices—as Jeff Williams of OWASP and Contrast Security notes—tightens the transparency demanded from those providing software to the federal government.

From Depth to Coverage: Goodbye to Limits on Indirect Dependencies

The most significant structural change concerns dependency management. Until now, the “depth” field set a maximum nesting level to be declared. The new guidance eliminates it and introduces the “coverage” field: from now on the SBOM must include all transitive dependencies, that is, dependencies of dependencies, without any depth limit.

This shift forces suppliers to perform a complete recursive analysis of third-party components, reducing blind spots where a vulnerability could hide in a package nested beyond the previous limit. Coverage becomes an absolute requirement, no longer adjustable.

What It Means for Those Providing Software to the U.S. Government

Organizations operating under federal compliance regimes will need to adapt their SBOM generation processes to meet three immediate constraints:

• include the digital signature;
• record the tool and version used to produce the inventory;
• extend the analysis to all dependency levels, without exception.

These are not revolutionary obligations, because tools based on SPDX and CycloneDX already offer most of these capabilities. However, the formal tightening raises the stakes for supply chain risk management and for compliance with frameworks derived from CISA’s directives.

Criticism: Without VEX and Verification, the SBOM Remains a Partial Tool

According to Williams, the guidance fails to address two critical points. First, it lacks VEX (Vulnerability Exploitability eXchange), a format for contextualizing the actual exploitability of vulnerabilities in a specific deployment context. Without it, the SBOM continues to produce lists of CVEs without helping to set patching priorities.

The second sore point is verification of accuracy and coverage. The guidance does not require that the stated inventory corresponds to what is actually distributed or deployed, nor does it mandate automated consistency checks. This limits the practical utility of the document in daily security decisions. Pending further developments, the expert recommends internal checks for completeness and alignment between SBOMs and real artifacts.

The Day After: A Guide on Open Source Security

On August 1, CISA published a second guide, dedicated to best practices for open source software security. It is not a direct addition to the new SBOM, but it sits alongside the overall framework with which the agency is redesigning transparency and rigor requirements across the software chain, extending the guidance to the ecosystem of open components as well.