What’s New in the 2025 Draft SBOM Minimum Elements

During Cybersecurity Awareness Month, we invited security teams to look beyond perimeter defenses and focus on the software supply chain and, more specifically, the Software Bill of Materials (SBOM). 

In August, the Cybersecurity and Infrastructure Security Agency (CISA) released a draft update to the SBOM Minimum Elements. Even in draft form, the guidance signals a shifting focus toward improved data quality, greater automation support, and stronger provenance of software components.

This post closes NetRise’s Cybersecurity Awareness Month series by outlining the most important updates to the SBOM Minimum Elements, what they mean for agencies and vendors, and how NetRise responded.

SBOM Adoption Is Maturing

While the concept of SBOMs has existed for over a decade, the NTIA’s 2021 Minimum Elements for an SBOM established the first US federal baseline for software transparency. Adoption has accelerated, but standardization in reporting on what software actually contains is still catching up. Many SBOMs remain source-based and incomplete, reflecting what developers intended to ship and not what the firmware or software actually contains. 

CISA’s 2025 draft represents a move from simply producing SBOMs to satisfy minimal requirements toward creating SBOMs that are actionable, standardized, and capable of supporting automated risk analysis.

What’s New

The draft introduces several key updates that define what you’ll need to deliver and what your customers will expect to receive.

New Required Fields

• Component Hash: Deterministic fingerprint that validates components and detects tampering
• License: Legal framework for use, distribution, and compliance
• Tool Name: Tool used to generate the SBOM, enabling trust and reproducibility
• Generation Context: When and how the SBOM was created, clarifying coverage and limitations

These additions address long-standing gaps in SBOM reliability. By tying each component to a verifiable hash, declaring its license, and documenting how and when the SBOM was generated, producers can create artifacts that are more transparent and trustworthy. This added context helps consumers validate authenticity, assess risk, and trace vulnerabilities with greater confidence.

Updated or Clarified Fields

• SBOM Author & Software Producer: Distinguishes who created the SBOM and who produced the software
• Component Version: Adds precision and fallback guidance when version data isn’t available
• Software Identifiers: Reinforces standardized identifiers (purl, CPE, SWID) for automation and comparison
• Dependency Relationship, Coverage, Known Unknowns: Expands definitions to reveal transitive dependencies and blind spots
• Distribution & Delivery: Adds access control considerations and streamlines sharing

These clarifications also align with feedback from NetRise CEO Thomas Pace, who, in NetRise’s public comment, emphasized that SBOM accuracy depends on validating SBOMs against the compiled binaries that actually execute, not just the source code they’re derived from.

By demanding richer, more reliable metadata, the draft minimum elements aim to create SBOMs agencies can act on. For vendors, that means moving beyond one-off SBOM exports toward the automated, repeatable generation of accurate data across all products, data that’s verifiable against real binaries.

What Agencies and Vendors Should Expect

• Higher data-quality standards: SBOMs must be accurate, complete, and structured for automation. 
• Automation as a necessity: While the draft doesn’t require automation outright, its data-quality and timeliness goals make manual generation impractical. 
• Procurement alignment: Expect organizations, especially government agencies, to incorporate these requirements into future contracts.
• Edge-case transparency: Legacy and firmware-based systems often lack accessible source code or modern tooling, making complete SBOMs difficult. Document those gaps rather than ignoring them.

The Case for Binary-Validated SBOM

SBOMs must reflect the software that actually executes. Vulnerabilities can be statically linked or embedded in ways source analysis can’t see. Hard-coded credentials, private keys, and configuration risks exist only in binaries. 

As Pace wrote, “An SBOM that does not reflect the compiled binaries that actually execute on a device cannot be considered accurate or complete.”

Guiding Principles for Improvement

NetRise also urged CISA to recognize that SBOM accuracy depends on validation against the compiled software that runs on the device. To that end, NetRise proposed two principles for all future Minimum Elements guidance:

1. Method Disclosure: Producers should disclose how the SBOM was generated - source, manifest, build-attested, or binary - so consumers can assess coverage and blind spots.
2. Binary Validation: SBOMs should be validated against compiled artifacts, since only binaries represent the software that truly executes.

Recommended Additions to Minimum Elements

To strengthen automation, traceability, and risk assessment, NetRise recommends:

• Artifact Digest: A top-level hash (e.g., SHA-256) linking the SBOM to the artifact it represents
• Generation Method & Evidence: Disclosure of generation method, inputs, and tool version
• Coverage Summary & Confidence: Structured indicators of component depth, static linking, and Known Unknowns
• Provenance & Maintenance Metadata: Repository, commit hash, maintainer, and contributor data to verify authenticity and detect malicious insertions
• Expanded License Metadata: Standardized SPDX identifiers with handling for unknown or proprietary licenses
• End-of-Life / End-of-Service Flag: Marker for unsupported components to identify persistent risk
• Provenance/Attestation Pointer: Links to build attestations such as SLSA or in-toto for supply chain integrity

Understanding Provenance

SBOMs should reveal not just what components are present, but where they came from and how they’re maintained. Open-source libraries underpin most device software, yet their provenance and upkeep are often poorly documented. Without that visibility, organizations can’t fully assess the trustworthiness of their software or the risks they’ve inherited.

The 2025 draft addresses this need by calling for Provenance & Maintenance Metadata, including repository, commit hash, maintainer, and contributor attribution. This structured data helps detect malicious insertions, assess maintenance health, and identify unsupported components before they become liabilities.

Structured Precision

NetRise’s submission stresses that narrative fields such as Coverage, Known Unknowns, and License should be expressed as structured data rather than prose. Free-text can’t be parsed consistently, breaking automation. Structured fields make cross-vendor comparison and triage scalable and reliable.

Pace also recommends expanding Tool Name to Tool Metadata (including version and input type) and redefining Generation Context to specify whether the SBOM was produced pre-build, during build, or post-build. These refinements make SBOMs reproducible and comparable at scale.

Binary Validation and Risk Visibility

If CISA’s goal is to make SBOMs more reliably represent software composition, NetRise data quantifies how binary validation is critical in meeting that objective. Across thousands of firmware images analyzed by NetRise, vulnerability risks were found to be over 200 times higher than traditional network scanners reported. Also, networking devices averaged 1,120 known vulnerabilities per image, with more than one-third older than five years.

Feasibility Across Sectors

CISA asked whether these elements are feasible across IT, OT, and device environments. The answer: Feasibility isn’t the issue. Accuracy is.

In operational technology, healthcare, and firmware and device environments, source code is rarely accessible. Binary validation remains the most practical—and in many sectors, the only—path to trustworthy SBOMs. The NetRise platform already supports 88 percent of the NSA’s recommended SBOM-management capabilities, demonstrating that these enhancements are technically achievable and deployable today.

Why This Update Matters and What’s Next

CISA’s draft update signals a move toward verifiable visibility grounded in binary analysis. As the agency reviews public feedback and moves toward a final version, agencies can start embedding accuracy and reproducibility into procurement. Vendors can modernize SBOM generation pipelines to deliver standardized, validated data by default.

NetRise already enables that binary-first approach, SBOMs tied to exact artifacts, enriched with vulnerability, license, and end-of-life intelligence to give you insight into real software risk.

As Pace stated in NetRise’s submission to CISA:

“If SBOMs are to fulfill their role as actionable tools for risk management, they must reflect the software as it exists and executes in the real world. Without validation against compiled binaries, agencies will remain unable to answer the most basic question in a crisis: Where am I exposed?”

The future of SBOMs is defined by proof and binary validation is the proof that matters.