Key Takeaways
- The 2025 SBOM minimum elements represent significant progress since the 2021 baseline.
- New fields, such as license, hashes, and generation context, push SBOMs beyond check-the-box compliance.
- Licensing data closes a critical blind spot in software supply chain risk management.
- Generation context highlights build-time SBOMs as the industry gold standard.
- Embedded software remains at risk of being overlooked unless file-level SBOMs are explicitly recognized.
In August 2025, the Cybersecurity and Infrastructure Security Agency (CISA) and the Department of Homeland Security (DHS) released a new draft of the Minimum Elements for a Software Bill of Materials (SBOM). It’s the first major revision since 2021, when the National Telecommunications and Information Administration (NTIA) outlined a simple baseline of just seven fields.
The new draft is a genuine turning point. It raises the bar for SBOMs, pushing them beyond check-the-box compliance and closer to being a real tool for managing risk. But while these changes are a big step forward, they still leave embedded systems—built largely in C and C++—struggling to fit into a framework designed with modern package-managed software in mind.
As Kelli Schwalm, SBOM Director at RunSafe Security, puts it: “The recommended 2025 SBOM minimum elements show how far the industry has come since 2021. We’ve moved from a theoretical checklist to practical requirements that reflect how SBOMs are actually used in the real world.”
However, Kelli warns, the implicit assumption in the draft recommendations is that a software component equals a package. For embedded systems, that’s not the case. Without explicit recognition of file-based SBOMs, we risk leaving critical systems out of the picture.
Listen to the Audio Overview
What Are SBOM Minimum Elements?
An SBOM is an ingredients list for software. To be useful, every SBOM must include certain key data fields, or the minimum elements.
In 2021, the NTIA’s list was a good starting point, but as software development has evolved, it is now far too basic: name, version, identifier, timestamp.
To reflect the reality of software development today, the 2025 draft adds fields like:
- License: Critical for compliance and security obligations
- Component hash: Cryptographic accuracy, pushing toward automation
- Generation context: Identifying whether an SBOM was created at source, build, or binary stage
- Dependency relationships: Clarifying how components connect
The updates reflect how organizations are actually using SBOMs today to manage software supply chain risk.
Why the New SBOM Minimum Elements Guidance Matters
From “Check-the-Box” to Automation
The 2021 requirements made it possible to deliver a barebones SBOM with nothing more than an Excel spreadsheet. Those quickly went stale and carried little value. The new requirements—particularly hashes, license data, and generation context—make that shortcut nearly impossible, forcing a move toward automated SBOM generation.
As Kelli explained: “By requiring more fields—hashes, authorship, generation context—CISA is making it almost impossible to get by with an outdated Excel spreadsheet. These new elements push the industry toward automated, accurate SBOM generation, which is the only way to keep pace with today’s threat environment.”
Licensing Finally Gets Its Due
License information is now a minimum requirement. Licensing is a compliance issue, but license restrictions can directly impact how software can be used or redistributed. By including it, CISA and DHS are addressing a real-world gap that often goes unnoticed until it becomes a legal or operational problem.
“Licensing impacts how organizations use and share software,” Kelli said. “Ignoring it in SBOMs left a blind spot in the software supply chain, and closing that gap is long overdue.”
Generation Context Raises the Quality Bar
Including generation context—stating where in the lifecycle the SBOM was created—is a small addition with outsized impact. For example, “Build-time SBOMs give the clearest and most accurate view of software,” Kelli said. “This requirement could pressure suppliers to deliver them, raising the quality bar across the ecosystem.”
By making generation context mandatory, the draft puts pressure on suppliers to produce higher-quality SBOMs and discourages binary-only or “black box” approaches.
Compare SBOM generation approaches.
RunSafe’s Perspective
RunSafe sees the 2025 SBOM minimum elements as a much-needed course correction. They reflect four years of learning, discourage paper-thin compliance practices, and push the industry toward automated, accurate, and timely SBOMs.
But gaps remain, especially for embedded systems. Most federal guidance still implicitly equates “software component” with “package.” For modern applications built with package managers, that’s fine. For embedded devices, it’s a problem.
“Most federal guidance still assumes software components come neatly packaged, but embedded software in C and C++ rarely works that way,” Kelli said. “File-level SBOMs are harder to generate, but they’re also where you get the most precise vulnerability data.”
That precision matters most in embedded systems—the software inside medical devices, critical infrastructure, and defense technology—where false positives waste time and false negatives risk lives.
“If we don’t account for embedded use cases, we risk leaving out some of the most critical systems,” Kelii said.
RunSafe believes the draft’s generalized fields are a step in the right direction, but federal guidance should go further. It should explicitly recognize that SBOMs can be generated at the file level, not just at the package level, and that embedded contexts demand this granularity.
Raising the Bar for Software Supply Chain Security
The 2025 SBOM minimum elements draft is a milestone. It raises expectations, improves accuracy, and pressures suppliers to move beyond token compliance. That’s progress.
But for SBOMs to fulfill their promise across the entire software ecosystem, we must ensure embedded systems are not left behind. File-level SBOMs are essential for securing the most critical software our society relies on.
At RunSafe, we applaud the direction of the new guidance and will continue to advocate for embedded-first thinking in SBOM guidance. The security of the software supply chain depends on it.
Learn more about RunSafe’s approach to SBOM generation and software supply chain security. Download our white paper or view our SBOM tool comparison.
