Review – CISA Publishes 2025 Minimum SBOM Requirements Guidance

On Friday, CISA published a request for information (RFI) in the Federal Register (90 FR 41094-41095) on their draft update of the “2025 Minimum Elements for a Software Bill of Materials (SBOM)”. The original draft was published in July 2021, by DOC’s The National Telecommunications and Information Administration (NTIA) in response to requirements of President Biden’s EO 14028. CISA requests input on the clarifications and enhancements in the proposed voluntary guidance.

The 2025 version of the Minimum Elements expands on the three minimum elements as required by EO 14028, that were set out in the 2021 document:

Data Fields: Documenting baseline information about each component that should be tracked,

Automation Support: Allowing for scaling across the software ecosystem through automatic generation and machine-readability, and

Practices and Processes: Defining the operations of SBOM requests, generation and use.

Appendix A provides an expanded list of SBOM data elements with Appendix B adding an explanation of the changes made to the data elements list.

Public Comments

CISA is soliciting public comments on this draft SBOM guidance documents. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov: Docket # CISA-2025-0007) Comments should be submitted by October 3^rd, 2025.

A reminder, this is a proposed guidance document, not a regulatory document. This means that there is a lack of specificity in what CISA is expecting to see in the SBOM data elements.

 

For more information about what is included in the draft document, including a commentary on the use of SBOMs, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/cisa-publishes-2025-minimum-sbom - subscription required.

Review - CISA Announces SBOM Listening Sessions

Today, CISA published a meeting notice in the Federal Register (87 FR 33192-33193) for a series of four public listening sessions on “Advancing SBOM Technology, Processes, and Practices, to be held over five days in July. According to today’s notice, these listening sessions “are intended to advance the software and security communities' understanding of SBOM creation, use, and implementation across the broader technology ecosystem.”

CISA is looking for information about SBOM topics in these listening sessions. They intend to facilitate discussions between interested parties. They specifically state that it is not currently their “intent to use information shared during listening sessions to directly address or inform any Federal policy decision.” While CISA intends to facilitate “effective and constructive collaboration”, it is not clear from the notice how these sessions relate to the ongoing work being done by NTIA on the SBOM issue.

All sessions will be held virtually. Sign-up and access information will be available at the CISA SBOM website (not up as of this morning).

 

For more details about these sessions, including brief look at topics and schedule, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/cisa-announces-sbom-listening-sessions - subscription required.

Reader Comment – Log4Shell Do Something Now

Yesterday I received a DM from a long-time reader and ICS influencer as part of an ongoing discussion about software updates for ICS products for the Log4Shell problem. It said:

“Patrick we need to shake up the ICS vendors they are not doing justice to the seriousness of this vulnerability .... (sic) they and their customers are all likely to be impacted .... (sic)”

My first inclination was to agree; this is certainly a problem, and something needs to be done about it now. But I recognized that response as being an emotional response and I have learned over the years that I need to let such responses simmer, so that I don’t say something that I later regret. And, this morning, I am glad that I did.

The Siemens Example

Siemens was one of the first ICS companies to respond to Log4Shell. This is to be expected. They have lots of experience dealing with newly discovered vulnerabilities. They published their advisory on December 13^th, and their first update on December 15^th. Part of the reason for the quick update was the discovery of a second Log4J vulnerability and the ineffectiveness of the first workaround. Then there was a second update on the same day. More affected products were listed, and one was removed. Now that there is a third Log4J vulnerability, I suspect that a third update is probably in the works.

Fixing Means Stopping Production

If an owner/operator started working on the first suggestions from the initial advisory, they may have had to start anew with the later information. The problem, however, is that to ‘fix’ and ICS system, you have to take that system out-of-service for some amount of time to apply the fix. That means that production must stop. If an owner/operator tried to do that for each of the Siemens’ updates, that would quickly begin to impact the bottom line.

Oh, and if you had taken the system down to ‘fix’ a device that was not really affected by Log4Shell after all, the cost would have come without any benefit.

Risk Notification

Okay, so maybe we really do want to have vendors to get a good fix made before the owner/operator tries to fix their systems. And remember, the fixes really need to be tested and evaluated in a mirror of the deployed system to make sure the fix does not cause even more problems. But we should be able to expect quick notification about the vulnerabilities from the vendors, right?

To be fair, the response that I reported upon earlier this week is the most comprehensive (far from perfect, but the best yet) set of vendor responses that I have seen since I started reporting on vendor advisories. It is far from complete, and many of the reports were of the ‘we are looking at the problem’ sort, but that is still much more than what we typically see for library vulnerabilities.

SBOM

The big problem here is that the Lib4J library is much more pervasive that first thought. This has grown beyond just a vendor or 3^rd party provider problem; we are starting to see that this is a 4^th or 5^th party provider problem. It certainly points out the need for software bill of materials, but it also points out how complex the SBOM issue is becoming in modern software development.

But SBOM is not a be all and end all. It must be accompanied by a vulnerability notification system that pushes those notifications down the line. This is the only way that vendors and end users will know to look at the vulnerabilities in the first place.

Review - HR 4611 Introduced - Software Supply Chain Risk Management Act

Last week, Rep Torres (D,NY) introduced HR 4611, the DHS Software Supply Chain Risk Management Act of 2021. The bill would require DHS to develop contract guidance to require that proposed contract bids would include a planned bill of materials for covered information and communications technology or service and a certification that such materials are free of known security vulnerabilities. The guidance would go into effect 180 days after the enactment of this bill.

NOTE: This review is based upon a Committee Print of the bill provided by the House Homeland Security Committee. The official GPO version has not yet been printed.

As I mentioned yesterday, this bill will be marked-up by the House Homeland Security Committee tomorrow. I expect that the bill will pass with significant bipartisan support. That would allow the bill to be considered by the full House under the suspension of the rules process.

For more details about the provisions of the bill and my look at its relation to software-bill-of-materials as defined by NIST, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/hr-4611-introduced - subscription required.

Review - NTIA Releases Minimum Elements for SBOM

Yesterday the DOC’s National Telecommunications and Information Administration (NTIA) published their report on the minimum elements for a software bill of materials (SBOM) as required by President Biden’s EO 14028. The report outlines three broadly defined minimum elements, explains how they can currently be implemented and used and points the way forward for expanding the usefulness of SBOM. NTIA had solicited public input on the development of these minimum elements last month, but has been working on the topic with an open work group since 2018.

The announcement lists the three minimum elements as required by EO 14028:

• Data Fields: Documenting baseline information about each component that should be tracked,

• Automation Support: Allowing for scaling across the software ecosystem through automatic generation and machine-readability, and

• Practices and Processes: Defining the operations of SBOM requests, generation and use.

The report goes into more detail about each of the elements.

NTIA acknowledges that these three minimum requirements are just that, MINIMUM. They outline much of the near term works that needs to be done.

For a more detailed look at the report, see my report at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/ntia-releases-minimum-elements-for - subscription required.

Review - HR 2928 Introduced – Cyber Sense Program

Back in March Rep Latta (R,OH) introduced HR 2928, the Cyber Sense Act of 2021. The bill would require DOE to establish “a voluntary Cyber Sense program to identify and promote cyber-secure products intended for use in the bulk-power system” {§2(a)}. Similar bills have passed in the House in the last three sessions of congress, most recently HR 360 in the 116th.

Moving Forward

On Thursday of this week the House Energy and Commerce Committee held a markup hearing where this bill was considered. The Committee considered HR 2928 without amendments and ordered it favorably reported to the House by a voice vote. The bill will be considered by the full House, likely before the Summer Recess. The bill will be considered under the suspension of the rules process. This means limited debate, no floor amendments and a super majority will be required for passage. The bill will almost certainly pass (yet again) with strong bipartisan support.

Commentary

I would like to propose a value-added feature that should be made part of the Cyber Sense Program, a software bill of materials {SBOM, as defined in §10(j) of EO 14028} requirement for all product. This would help DOE notify other vendors of potential vulnerabilities in their systems due to new vulnerabilities being reported to DOE in other affected products. This will be especially critical while there is a CEII restriction on publication of the vulnerability. To make this happen, we could revise §2(b)(2):

(2) for products and technologies tested under the Cyber Sense program, the Secretary would establish:

(i) a requirement to submit a software bill of materials (SBOM), as that term is defined in §10(j) of EO 14028 for each product or technology submitted for evaluation;

(ii) and maintain cybersecurity vulnerability reporting processes and a related database; and

(iii) provide notification to affected vendors when a vulnerability reported to the Cyber Sense program potentially affects their product, based upon their SBOM listing on file with the program.

For a more detailed analysis of this legislation see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/hr-2928-introduced (subscription required).

Review - EO 14028 – NTIA Publishes SBOM Request for Comments

Today, the DOC’s National Telecommunications and Information Administration (NTIA) published a notice in the Federal Register (86 FR 29568-29571) requesting public comments on “Software Bill of Materials Elements and Considerations”. This action is being taken in support of the requirements of EO 14028 for NTIA to “publish minimum elements for an SBOM” {§4(f)}.

Public comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket #210527-0117). Due to the short response requirements of EO 14028, NTIA is requesting that comments be submitted by June 17^th, 2021.

Commentary

One point that is not discussed here (and admittedly it was not part of the presidential mandate) that needs to be discussed before any SBOM process becomes operational is the information sharing aspect of the SBOM. Let’s face it, and SBOM is going to provide an adversary with a software blueprint that will help guide the development of an attack process. Any discussion of an effective SBOM process is going to have to address how widely the detailed information in an SBOM is shared.

For a more detailed look at the information that NTIA is looking for, see my post at - https://patrickcoyle.substack.com/p/eo-14028-ntia-publishes-sbom-request. Subscription Required

NTIA Publishes SBOM Meeting Notice – 4-29-21

Today the DOC’s National Telecommunications and Information Administration (NTIA) published a meeting notice in the Federal Register (86 FR 17139-17140) for a virtual meeting of a multistakeholder process on promoting software component transparency on April 29, 2021. The agenda and slide deck will be posted on the NTIA Software Transparency web site. Background material can be found on the NTIA Software Bill of Materials (SBOM) web site.

Reader Comments – More on SBOM – 2-28-21

My blog post on software bill of materials (SBOM) sparked a small Twitversation this week. It is always nice to be part of an exchange of ideas. That is, of course, the whole point of writing a blog. So, lets look at what new information surfaced.

Software Component Transparency

SBOM did not rise, phoenix like, from the ashes of my mind. There have been conversations on the topic for sometime now. One extended conversation has been taking place under the auspices of the Department of Commerce’s (DOC) National Telecommunications and Information Administration (NTIA). They, in fact, have a web page dedicated to “NTIA Software Component Transparency” and hold periodic public discussions about aspects of the issue.

Their web page provides a wealth of information on the topic. More importantly, they are actively soliciting participation in various working groups. Those working groups include:

• Framing Working Group,

• Awareness and Adoption,

• Formats and Tooling, and

• Healthcare Proof of Concept

It’s Not There

Ron Brash emphasized a point that I tried to make in my post. Just because a vulnerable software component is present in a product does not mean that the product is thus vulnerable. Ron makes the point about Linux kernels; being an open-source product, a developer can take what they want and leave the rest. This is why some sort of vulnerability testing is still necessary.

But, even where vulnerable code does actually exist in the end product, it may not be exploitable in the end product. A lot depends on how the developers access the component and use it in their software/firmware.

Wish List

What would be really nice is if someone could come up with a relatively simple to use Third-Party Vulnerability Tool (TPVT) that could pull data from a database of known vulnerabilities to test and see if vulnerabilities in the known components (from a SBOM) of a product are present in the tested product.

Okay. That means two things on the wish list. First is the TPVT. That will be an interesting development effort. Probably take a 1,000 software engineers. Actually, the database would have to come first, and that, in and of itself, is going to be a monster of a job. I know what a job it is just to keep up with the summaries I do of vulnerability reporting in the ICS field. But a database of all of the versions of all of the potential components (kernels and libraries, oh my) with the associated vulnerabilities, PoC and exploits, that is going to be monumental.

Come to think about it, we may never see this tool. But the NSA might really want one….