Understanding the Proposed CISA 2025 SBOM Minimum Elements
CISA has proposed updates to the SBOM Minimum Elements. What does this mean for business leaders and engineers?
Michael Lieberman
September 23, 2025
Software bills of materials (SBOMs) are an ecosystem-agnostic way to describe the software that’s inside your applications. The information in an SBOM helps you better understand your software dependencies. Unfortunately, the quality and quantity of information can vary widely from one SBOM to another. To address this, the U.S. Cybersecurity & Infrastructure Security Agency (CISA) recently released a draft of its updated SBOM Minimum Elements for public comment.
What the updates mean for you
For engineering and platform teams, the proposed updates mean fewer proprietary formats, less guesswork when integrating tools, and a standardized record that can travel across environments and vendors. The addition of new mandatory fields, like Tool Name and License, brings greater clarity. SBOM tools operate differently, so knowing which tool generated an SBOM helps teams assess the reliability of the data, while explicit license information is critical for navigating usage rights in SaaS, distributable products, or mixed environments. This is important as many organizations place restrictions on which licenses can be used in their software.
For business and enterprise developers, SBOMs help answer basic-but-critical operational questions: What software are we running? What components does it rely on? What changed between versions? These are questions you don’t want to be answering reactively in the middle of a production incident or regulatory audit.
SBOMs also enable teams to check for newly introduced vulnerabilities in each build and enforce policies that prevent critical vulnerabilities from ever reaching production. By treating SBOMs as living operational documents, rather than compliance checkboxes, organizations can make updates more efficiently, spot dependency issues earlier, and reduce costly surprises in the release cycle. The new Component Hash field strengthens this by offering a unique identifier for each dependency. That matters because packages often share names, but differ in source or build; the hash confirms exactly which component was included. Similarly, the Generation Context field records when and how an SBOM was produced—whether pre-build, during build, or through post-build inspection. Build-time SBOMs are generally most accurate, but in many real-world cases teams may only have a container image or source code to work with. Capturing this context helps downstream users understand the limits of the data and make more informed decisions.
SBOMs recommendations
Keep in mind that any SBOM is better than no SBOM. My recommendation is that simplicity is the best starting point. You don’t need a complex new system to begin generating and using SBOMs. Lightweight tools, integrated into existing CI/CD pipelines, can already provide enough visibility to make informed decisions.
Over time, richer SBOM practices, such as cross-project dependency analysis and historical tracking, can become powerful enablers of enterprise-scale operations. The key takeaway is that SBOMs aren’t just about meeting a compliance requirement. They are useful in understanding software composition, managing dependencies, and ultimately delivering software with greater confidence, speed, and control.
Forbes and The New Stack recently covered this topic, and their coverage is worth reading.
With Kusari Platform, you can enrich your SBOMs and get a holistic view across your entire application portfolio. Ready to get started? Schedule a time to see how Kusari can help you understand your software supply chain.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?