When a serious flaw is disclosed in a widely used code library, the first question every organization asks is simple: do we use it? This article explains how a software bill of materials (SBOM) is meant to answer that question, what a joint US-led update published in July 2026 changed, and where the idea still has limits.
What is a software bill of materials?
Modern programs are rarely written from scratch. They are assembled from dozens or thousands of smaller pieces, many of them open-source libraries maintained by people outside the company that sells the product. An SBOM is the inventory of those pieces.
The US Cybersecurity and Infrastructure Security Agency (CISA) describes an SBOM as “a nested inventory, a list of ingredients that make up software components,” and calls it a key building block in software security and software supply chain risk management. The National Institute of Standards and Technology (NIST) quotes the definition in a 2021 US executive order, Executive Order 14028: a “formal record containing the details and supply chain relationships of various components used in building software.” NIST also compares an SBOM to the ingredient label on food packaging.
“Nested” matters. A component often depends on other components, which depend on others. A useful SBOM records those relationships, not just a flat list of names.
Why does a component list matter for security?
Software supply chain risk means that a weakness can enter a product through something its maker did not write. If a flaw is found in a shared library, every product that bundles it is affected, yet customers usually have no way to see inside the product.
According to NIST, SBOMs increase transparency and provenance (where a component came from), and they speed up the identification and remediation of vulnerabilities by federal agencies. They can also show whether a supplier follows secure development practices across the software development life cycle.
The same logic helps any organization. Public flaws are labeled with CVE identifiers, which are short tags that let everyone refer to the same problem. With an SBOM in a searchable form, matching a new CVE to the software you run becomes a lookup rather than a round of emails to vendors. The effect is similar to the prioritization problem described in the explainer on CISA’s exploited-vulnerabilities catalog: attention is limited, so knowing quickly what you actually run is the first step.
What changed in July 2026?
According to CISA, the “2026 Minimum Elements for a Software Bill of Materials” was released on July 29, 2026, as joint guidance from CISA, the National Security Agency, the Federal Bureau of Investigation and international partners. It “updates and replaces” the earlier minimum elements that the US National Telecommunications and Information Administration (NTIA) published in 2021.
CISA’s SBOM page says the new joint guidance includes new data fields, practices and processes that reflect stakeholder feedback. CISA also lists a 2025 draft of the minimum elements that was open for public comment until October 3, 2025, and the agency says the final text reflects that feedback and current tools. The guidance keeps the core principles of the NTIA original.
Some details are not confirmed here. The CISA pages read for this article do not list the individual data fields in text; the field list sits in the full PDF. Secondary reports describe additions such as digital signatures, component hashes and license information, but those descriptions should be checked against the document itself before anyone builds a compliance process on them.
What does the minimum actually cover?
NIST’s page on software supply chain security explains the general shape of the 2021 baseline, which the new version builds on. Machine-readable SBOMs should include data fields about each component, support for automation, and practices for how SBOMs are requested, produced and used. NIST lists three common formats: SPDX, CycloneDX and SWID. “Machine-readable” means software can process the file without a person retyping it.
| Element | Plain-language meaning |
|---|---|
| Data fields | Details recorded for each component, such as its name and supplier |
| Automation support | Formats that tools can read and compare at scale |
| Practices and processes | How often SBOMs are generated, shared and updated |
The table paraphrases the categories NIST describes; the specific fields are defined in the guidance itself.
CISA says the minimum elements describe baseline technologies and practices, and that some kinds of software, such as AI systems and cloud-based software as a service, may need additional elements. It does not specify those extras on the page reviewed.
Does having an SBOM mean software is secure?
No, and the agencies themselves say so. NIST notes that the NTIA considered SBOM capabilities still nascent for federal buyers and described the minimum elements as a first step. SBOMs complement existing supply chain risk management tools, such as vulnerability management and vendor risk assessments, and do not replace them.
Three limits stand out:
- A list is not a verdict. An SBOM says a component is present. It does not say whether the flaw in that component can actually be reached in the way the product uses it.
- Timing matters. NIST warns that an SBOM generated after the fact may not reflect the dependencies used at build time.
- Accuracy is a separate question. A file can be well formed and still incomplete. The minimum elements are a floor for what is recorded, not an audit of whether everything was recorded.
What is VEX, and how does it fit in?
A frequent complaint about SBOMs is noise. A component might contain a flaw that the product never exposes, yet a scanner will flag it anyway. CISA’s answer is a companion document called a Vulnerability Exploitability eXchange, or VEX. CISA defines it as “an attestation, a form of a security advisory” that indicates whether a product or products are affected by known vulnerabilities.
In practice the two documents divide the work. The SBOM says what is inside; the VEX says, for a given flaw, whether the product is affected. A buyer who receives both can skip alerts the supplier has already assessed as not applicable and focus on the ones that are.
Worked example: a flaw in a shared library
Illustrative arithmetic only, with invented numbers. Suppose an organization runs 200 applications, and a flaw is announced in a popular logging library.
- Without SBOMs, the security team must ask each of the 200 vendors or internal teams whether the library is inside. If each inquiry takes one hour of someone’s time, that is 200 hours of work before any fixing starts.
- With searchable SBOMs for all 200, a single query might show that 12 applications include the library. The team then reads supplier statements for those 12; if 9 are marked “not affected” in VEX documents, only 3 need urgent action.
The numbers are hypothetical, but the shape of the saving is the point: the work shrinks from 200 questions to a lookup and a short review.
Who is expected to produce and use them?
The 2021 executive order tied SBOMs to federal purchasing. NIST says agencies should, where applicable, require suppliers to provide machine-readable SBOMs that conform to the order and the NTIA’s 2021 minimum elements. That makes the minimum elements a practical reference for software vendors that sell to government, and, through contracts, to their other customers.
The July 2026 update, as described on CISA’s page, is published as joint guidance. The page reviewed gives no sign of a comment period, an effective date or a mandate attached to the new version. Whether and when procurement language shifts to the 2026 text is not stated in the sources reviewed.
Defenders outside government can still use the idea. NIST’s recommended capabilities range from foundational steps, such as using standard formats and cataloging SBOMs across all classes of software, to more advanced ones, such as integrating vulnerability detection with SBOM repositories. For organizations with no SBOM program, a sensible start is to ask critical suppliers whether they can provide one and in what format, and to keep a current inventory of internally built software.
Is an SBOM relevant to future-proofing, too?
Component inventories also help with slower-moving risks. Older cryptography embedded in a product is one example. Knowing which libraries supply encryption makes it far easier to plan a migration of the kind discussed in the piece on the NIST and NCSC post-quantum timeline. An inventory does not do the migration, but it tells you where to look.
The same goes for open-source dependencies in general. The article on why everything depends on open-source software explains why so many products share the same building blocks, and why one maintainer’s bug can become thousands of organizations’ problem.
What remains unsettled?
Several questions remain open. The exact content of the 2026 field list should be read from the primary document. It is not yet clear from the sources reviewed how widely vendors will adopt the update, how buyers will verify that an SBOM is accurate, or how AI systems and cloud services, which CISA says may need more elements, will be handled. No independent measurement of how much faster organizations respond to new flaws with SBOMs was found among the sources reviewed, so the benefits described by agencies remain expectations rather than demonstrated results.
Reading an ingredient list with realistic expectations
An SBOM is a starting point for asking better questions, not an answer on its own. It makes the contents of software visible, and with VEX statements and a habit of checking new CVEs against inventory, it can turn a scramble into a routine. The July 2026 update refines the baseline, but the value still depends on suppliers producing accurate lists and customers actually using them.
This article offers general information and is not a substitute for professional security advice.
Sources: Cybersecurity and Infrastructure Security Agency; National Institute of Standards and Technology
