In August 2025, CISA (the US Cybersecurity Infrastructure & Infrastructure Security Agency) published new guidance around Software Bills of Materials (SBOMs) for the first time in four years, including what it calls the new ‘Minimum Elements’.
Minimum Elements sets the baseline standard for what ‘good’ looks like in an SBOM. It includes items like cryptographic ‘Component Hashes’ to clearly identify dependencies and ‘Generation Context’ to document the timeline of how an SBOM was created.
Despite the US Government relaxing previous suggestions for firms to adopt SBOMs to shore up the security of the software supply chain, CISA’s guidance forms part of a global effort to set a higher baseline for artifact provenance and software security.
For example, the EU Cyber Resilience Act (CRA) legally mandates “security by design” for all products with digital elements, including a requirement for firms to create, maintain, and retain an SBOM for all products sold in the EU.
This means that firms who want to do business in Europe can’t shove aside SBOMs as a “nice to have”, and procurement teams will increasingly expect suppliers to evidence what their SBOM contains and how it is produced.
With the CRA making SBOMs a legal requirement, and CISA expanding the technical definition of a credible SBOM, we’re seeing the emergence of a higher global baseline – and organizations that do not meet it will be left behind.
What Are the New Minimum Elements?
As well as the newer, flashier items like Component Hashes and Generation Contexts, CISA’s guidance included a whole list of updates to items that are already considered part of a standard SBOM.
Many of these data fields were reimagined to help users make better, more risk-informed decisions about software security, such as major updates to ‘SBOM Author’, ‘Component Version’, and ‘Software Identifiers’ metadata.
This often meant stripping out any ambiguity in the name of pre-existing fields to make their meaning crystal clear: like changing “supplier name” to “software producer”, or “other identifiers” to “software identifiers”.
Beyond that, however, the overhaul of these standards and the introduction of new Minimum Elements has effectively raised the standard for what counts as a credible SBOM. It’s a standard that many organizations aren’t currently meeting.
Why Do Minimum Elements Matter?
With CISA’s Minimum Elements likely to take over as the de facto mark of secure, trusted software packages, the ability to automatically generate higher-bar SBOMs will be an incredibly useful tool to accelerate your incident response process. Crucially, it will also help you meet customers’ increasingly tight due diligence requirements.
These requirements are tightening, in part, because of the CRA. Its goal is to ensure that any product with digital elements sold in the EU is secure at the time of purchase and throughout its entire lifecycle. This tilts the burden of responsibility for cybersecurity from the end-user to the manufacturer, making digital security a non-negotiable standard for doing business in the EU.
This isn’t limited to EU firms. Any company doing business in the EU will need to comply with CRA requirements, such as:
- Identifying, documenting, and remediating vulnerabilities without delay.
- Affixing a ‘Conformité Européenne’ (CE) mark to declare that the product meets mandatory EU cybersecurity standards.
- Notifying authorities of actively exploited vulnerabilities or severe security incidents within a very tight window.
While the CRA doesn’t explicitly call for companies to provide provenance data or SBOMs, it does set incredibly strict deadlines for responding to attacks.
Within 24 hours of becoming aware of an attack or vulnerability, companies must notify authorities that a problem exists and where the product is sold. Two days after that, they must be able to provide a detailed assessment, including the nature of the exploit and any initial steps taken to fix it.
You’d be very hard-pressed to meet those deadlines without some form of provenance data. Having that information at your fingertips means you spend less time worrying about fulfilling reporting obligations and more time remediating issues. If you spend hours combing through logs after an attack trying to understand where the problem is, your risk of missing the deadline jumps drastically – as does your exposure to fines.
SBOMs as Living Documents
To paraphrase Heraclitus: no organization ever uses the same software supply chain twice; for this is not the same supply chain, nor is it the same organization.
In much the same way, you can’t treat an SBOM like a one-off certificate. CRA policy applies to the entire lifecycle of your product. Dependencies change; versions change; and, most of all, so do attackers. Regulators and customers need to know that organizations are shipping secure, verified software on a regular basis and that, when new vulnerabilities emerge, developers know exactly what they need to fix.
An SBOM that can’t be regenerated from source is just a snapshot. So, instead, you need mechanisms to generate provenance data on a continuous basis. That is another reason why building processes around, and having the ability to automate provenance data from the outset puts you in a stronger position to handle CRA requirements long-term.
In practice, that means generating an SBOM for every build, attaching it to the exact artifact hash, and storing it immutably alongside the release. When a new CVE is disclosed, you should be able to query your artifact store and know within minutes which releases are exposed.
That way, you can contain the blast radius of a potential attack without having to sleep with one eye open every night.
The Future of Artifact Provenance
The US’s suggestions on SBOM generation may be gone, but they’re not forgotten. CISA’s Minimum Elements and related standards work will continue to influence what “good” looks like in practice, because they provide a concrete framework for the level of detail buyers and regulators will expect.
Going forwards, suppliers with mature, automatic SBOM processes will find it much easier to prove their software is trustworthy and secure. Those without will find themselves at the bottom of a buyer’s shortlist – and experience a lot of sleepless nights.
This article was submitted by Cloudsmith.