|

CISA Wants to Update the Biden‑Era SBOM Minimum Requirements: What’s Changing and How to Weigh In

ByInnoVirtuoso

If you sell software to the U.S. government—or rely on it in your enterprise—your SBOM strategy is about to matter a lot more. The Cybersecurity and Infrastructure Security Agency (CISA) has asked the public to comment on an updated version of the government’s “minimum elements” for a Software Bill of Materials (SBOM). That’s a big deal. It signals the next phase of SBOM adoption, moving from early policy to everyday practice.

Here’s why this moment matters: organizations have been generating SBOMs since 2021, but the focus is shifting from simply “creating a list” to consistently sharing, analyzing, and managing SBOMs at scale. The update CISA is proposing aims to reflect that maturity. It could reshape what you need to collect, how you publish it, and how government buyers verify it.

In this deep dive, we’ll unpack what’s on the table, what could change, and what you should do now—whether you’re a federal supplier, an agency buyer, or a security leader trying to keep your software supply chain resilient.

Let’s start with the basics and build from there.

SBOM 101: Why It Exists and What the Current Rules Say

An SBOM is a machine‑readable inventory of the components in your software, including third‑party and open source packages, plus their dependencies. Think of it like a nutrition label for software. It helps you (and your customers) answer simple but vital questions:

  • What’s inside the software I’m running?
  • Which components are vulnerable?
  • How fast can I respond when a new flaw hits the headlines?

After high‑profile supply chain incidents, SBOMs moved from “nice‑to‑have” to national priority. Here’s the short policy timeline:

  • May 2021: President Biden issued Executive Order 14028, calling for better software supply chain security and setting the stage for SBOMs in federal procurement.
  • 2021: The National Telecommunications and Information Administration (NTIA) published the first government guideline—the “SBOM Minimum Elements”—to help agencies and vendors standardize SBOM content and format. See NTIA’s overview here.
  • September 2022: The Office of Management and Budget (OMB) released M‑22‑18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.” Among other things, it signaled that CISA would produce successor guidance to the 2021 NTIA SBOM Minimum Elements.

Since then, agencies and suppliers have been working toward practical SBOM adoption. Some stakeholders asked for more time; others pushed to move faster. Now, CISA is stepping in to modernize the baseline.

The 2025 Pivot: CISA Seeks Comments to Update SBOM Minimum Elements

CISA has announced plans to update the 2021 NTIA SBOM Minimum Elements to reflect how the ecosystem has evolved. The agency noted that SBOM tooling now extends beyond generation to include sharing, analyzing, and managing SBOMs—capabilities that didn’t exist or weren’t widely used in 2021.

A few additional signals frame this moment:

  • The SBOM community is larger and more coordinated than it was in 2021, with strong open source participation and converging standards.
  • Media and community chatter suggest leadership and working‑group shifts, with independent foundations signaling they’ll help steward the work. For broader community context, see the Open Source Security Foundation (OpenSSF) here.
  • CISA is explicitly inviting comments from experts across industry, academia, open source, and the public—an opportunity to influence requirements that will likely cascade through federal procurement.

If you’re directly affected—software vendors, integrators, and agency buyers—this is your chance to turn pain points into policy improvements.

For CISA’s SBOM resources and updates, start with CISA’s SBOM hub here.

What Might CISA Change? Key Areas to Watch

While the final text isn’t published yet, CISA has previewed the direction: updating the “minimum elements” to match current practice. Based on where the ecosystem is today, expect refinements in at least these areas.

1) SBOM Scope and Granularity

  • Component identification: Stronger expectations for unique identifiers (e.g., Package URL, CPE, SWID where relevant).
  • Dependency depth: Clearer guidance on how deep to enumerate transitive dependencies and when to include optional or dev‑only components.
  • Metadata hygiene: More consistent supplier names, versions, and license fields to reduce ambiguity.

Why it matters: Ambiguous component names or missing version data make SBOMs hard to automate against vulnerability feeds and asset inventories. Precision enables speed when incidents happen.

2) Accepted Formats and Interoperability

  • Continued emphasis on widely adopted formats like SPDX and CycloneDX.
  • Potentially clearer mapping between formats, fields, and minimum required data elements to minimize “translation loss.”

Why it matters: Interoperability lets agencies and primes ingest SBOMs without brittle, one‑off conversions.

3) Update Cadence and Versioning

  • Expectations for how often SBOMs should be refreshed (e.g., at each build, major release, or when material changes occur).
  • Versioning guidelines so SBOMs can be tied to specific builds, commits, and releases.

Why it matters: A stale SBOM creates false confidence. Tying SBOMs to builds and commits also supports traceability.

4) Distribution, Access Control, and Sharing

  • Guidance on how suppliers should share SBOMs: public download, portal access, NDA‑gated, or “SBOM‑on‑request.”
  • Data minimization and sensitivity: how to protect proprietary or exploitable details while keeping SBOMs useful.

Why it matters: Some components reveal architectural details. You want to balance transparency with risk.

5) Validation, Quality, and Conformance

  • Minimum quality checks: completeness thresholds, schema validation, deduplication rules.
  • Evidence and attestations: tying SBOMs to build pipelines or signatures; potentially linking to provenance frameworks like SLSA and development practices in NIST’s SSDF (SP 800‑218).

Why it matters: Trustworthy SBOMs are verifiable and linked to how the software was built, not just what’s listed.

6) Vulnerability Context with VEX

  • Stronger integration with Vulnerability Exploitability eXchange (VEX), so consumers can tell whether a known CVE in a component is actually exploitable in your product.
  • Alignment with CycloneDX and SPDX VEX capabilities.

Why it matters: VEX prevents alert fatigue. It says, “Yes, this component has a CVE, but our product doesn’t call the vulnerable function,” or “We’ve mitigated it.”

For an overview of VEX in practice, see CycloneDX’s VEX resources here.

7) Automation and APIs

  • Recommendations for API‑based SBOM access, ingestion, and correlation with ticketing, CMDB, and vulnerability tools.
  • Encouragement for machine‑readable signatures and policy checks.

Why it matters: Manual SBOM handling doesn’t scale. Automation is the only way to operationalize SBOMs across portfolios.

8) Aligning SBOMs with Secure Development Practices

  • Mapping SBOM requirements to the NIST SSDF (SP 800‑218) that agencies already reference.
  • Emphasis on how SBOMs complement—not replace—threat modeling, code review, and dependency hygiene.

Why it matters: SBOMs work best as part of a secure development and release process, not as an afterthought.

The State of SBOM Tooling in 2025: From Generation to Management

Back in 2021, most of the conversation was about how to generate SBOMs. Today, the tooling landscape is broader and more robust. You’ll find:

  • Generators: Embedded in CI/CD, language‑specific tools, and commercial scanners.
  • Repositories: Artifact registries and SBOM catalogs that support search, versioning, and access control.
  • Analyzers: Correlate SBOM data with vulnerability feeds (like NVD, advisories) and internal asset inventories.
  • Managers: Platforms to govern SBOM workflows—requesting, validating, deduplicating, mapping to products, and feeding VEX.
  • Integrations: Connect SBOMs to ticketing, SIEM, CMDB, and risk dashboards.

CISA’s update is likely to codify best practices that these tools already support. If your process still involves emailing a JSON file around, it’s time to modernize.

What This Means for You: Stakeholder‑Specific Implications

For Software Vendors and SaaS Providers

  • Expect clearer expectations for SBOM quality, frequency, and format. If you produce multiple SBOM formats, consider standardizing on one that aligns with your customers’ needs.
  • Be ready to provide VEX statements with SBOMs to minimize disruption during high‑profile vulns.
  • Invest in automation: generate SBOMs during build, sign them, store them with artifacts, and expose them via an access‑controlled portal or API.
  • Prepare for procurement questions. Agencies may request SBOMs as part of RFPs or continuous monitoring.

Here’s why that matters: SBOMs are increasingly table stakes in federal sales. Treat them like a feature of your product, not a compliance checkbox.

For Federal Agencies and Systems Integrators

  • Standardize SBOM intake: Decide on preferred formats, schemas, and API endpoints. Publish this guidance to vendors.
  • Establish validation workflows. Automate schema checks, component ID normalization, and cross‑linking SBOMs to systems in your inventory.
  • Prepare to handle VEX at scale: decide how VEX statements will influence vulnerability scoring and patch SLAs.
  • Train acquisition staff to ask for SBOMs appropriately and evaluate them consistently.

Let me explain: the biggest barrier to SBOM value isn’t generating them—it’s consuming them. Make that part easier for your suppliers, and you’ll get better data, faster.

For Open Source Maintainers

  • You may be asked to ship SBOMs for your projects or accept PRs that add SBOM generation to your build.
  • Align on a default format (SPDX or CycloneDX) and keep it in your release artifacts.
  • Consider publishing VEX or security advisories clarifying exploitability when high‑visibility CVEs hit.

This doesn’t mean you need enterprise tooling. Many language ecosystems have lightweight generators you can run in CI for free.

For Security and Risk Leaders

  • Update your risk model to incorporate SBOM‑driven insights: bill of materials coverage, time‑to‑ingest, and mean time to remediate when VEX says “exploitable.”
  • Tie SBOM metrics to business outcomes: faster incident response, fewer emergency patches, clearer vendor accountability.
  • Use SBOMs to validate third‑party risk attestations and align with SSDF practices.

The bottom line: SBOMs are becoming your visibility layer for supply chain risk. Treat them like first‑class data.

A Practical SBOM Readiness Checklist (Next 90 Days)

If you need a clear starting point, use this phased plan.

  • Weeks 1–2: Baseline
  • Inventory your products and services that require SBOMs.
  • Choose a primary format (SPDX or CycloneDX) and schema version.
  • Map SBOM generation to your CI/CD for each build.
  • Weeks 3–4: Quality and Provenance
  • Ensure component IDs, versions, and licenses are consistently captured.
  • Link SBOMs to build artifacts, commits, and signatures.
  • Stand up an SBOM repository with role‑based access.
  • Weeks 5–6: Vulnerability Context
  • Decide when and how you’ll publish VEX statements.
  • Integrate SBOMs with vulnerability management to correlate CVEs automatically.
  • Weeks 7–8: Sharing and Requests
  • Document your SBOM sharing policy: public, request‑only, or gated portal.
  • Provide an SBOM landing page or API endpoint for customers and agencies.
  • Weeks 9–10: Governance and Training
  • Define ownership: who approves SBOMs, who responds to SBOM requests.
  • Train engineering and support teams on SBOM updates during releases.
  • Weeks 11–12: Dry Run
  • Simulate a high‑profile CVE. Deliver SBOM + VEX to stakeholders.
  • Measure time to identify exposure and communicate status.

How to Write Comments that Move the Needle with CISA

CISA has asked for broad participation—including technical specialists, industry, academics, and public interest groups. If you want your comments to matter:

  • Be specific: Point to fields, formats, or workflows that cause friction (e.g., “transitive dependencies are inconsistent in language X; require Y solution”).
  • Provide data: Share anonymized metrics or case studies (e.g., SBOM ingestion time dropped 60% when suppliers used SPDX field Z).
  • Propose text: Offer draft language for minimum elements, validation checks, or cadence.
  • Represent your constituency: Are you a small vendor? Open source maintainer? Prime contractor? Explain your constraints and trade‑offs.
  • Consider interoperability: Suggest mappings between SPDX and CycloneDX for required fields.
  • Address security vs. sensitivity: Recommend a model for public vs. private SBOMs and minimum redactions that preserve utility.

If you’re unsure where to start, review the current NTIA guidance here and OMB’s policy baseline in M‑22‑18, then highlight what’s missing or outdated.

Common SBOM Pitfalls to Avoid

  • Shipping “empty calories”: SBOMs with missing versions, vague component names, or no license info.
  • One‑and‑done generation: Failing to update SBOMs when you patch dependencies.
  • Format roulette: Sending different formats per product or per customer without clear rationale.
  • Ignoring VEX: Leaving customers to chase non‑exploitable CVEs.
  • Manual handling: Emailing SBOMs as attachments without signatures, traceability, or API access.

Each of these erodes trust and increases support burden. The cure is consistent automation and clear policy.

Key Questions to Watch as Policy Evolves

  • How prescriptive will CISA be on fields, formats, and validation?
  • Will the update standardize SBOM refresh cadence tied to releases or builds?
  • How will agencies balance transparency with sensitive component details?
  • What role will VEX play in mandatory reporting?
  • How will SBOM guidance align with NIST SSDF and provenance frameworks like SLSA?
  • Will there be different expectations for on‑prem software vs. SaaS?
  • How will small vendors and open source maintainers be supported?

You don’t need definitive answers today. Use these questions to guide your internal planning and your public comments.

Frequently Asked Questions

Q: What is an SBOM in simple terms?
A: It’s an ingredient list for software. It tells you what components and dependencies are inside an application, so you can find and fix risk faster.

Q: Is an SBOM required to sell software to the U.S. government?
A: Federal policy set the expectation for SBOMs through EO 14028 and OMB’s M‑22‑18. Agencies can require SBOMs as part of procurement and continuous monitoring, and expectations are tightening as CISA updates the minimum elements.

Q: What SBOM formats are accepted?
A: The government recognizes common open formats like SPDX and CycloneDX. Pick one, ensure it’s valid, and be consistent.

Q: How often should I update an SBOM?
A: At least with each release or when you materially change dependencies. Many organizations generate an SBOM at every build to keep the data fresh and traceable.

Q: Do SBOMs expose sensitive information?
A: They can. That’s why many suppliers use access‑controlled portals or share SBOMs under NDA. Expect CISA to clarify how to balance transparency with security.

Q: What is VEX and why should I care?
A: VEX stands for Vulnerability Exploitability eXchange. It adds context to known vulnerabilities, indicating whether a CVE in a component is exploitable in your product. See CycloneDX’s VEX overview here.

Q: How do SBOMs help with zero‑day events?
A: When a new vulnerability (like Log4j) drops, SBOMs let you rapidly search for impacted components across your environment and inform stakeholders with VEX.

Q: How do SBOMs relate to NIST’s Secure Software Development Framework (SSDF)?
A: SBOMs provide visibility that supports several SSDF practices and can tie to secure build and release processes. Learn more about SSDF in NIST SP 800‑218 here.

Q: We’re a small vendor. Is this going to be too heavy?
A: It doesn’t have to be. Start with your main product, pick one format, automate generation in CI, and publish via a simple portal or on‑request process. You can mature over time.

Q: Where can I track official updates?
A: Follow CISA’s SBOM page here and the NTIA SBOM resources here. For standards, watch SPDX and CycloneDX.

The Takeaway

SBOMs are moving from policy aspiration to operational requirement. CISA’s update to the 2021 NTIA Minimum Elements will likely harden expectations around quality, sharing, cadence, and context—with VEX and automation playing bigger roles. If you prepare now, you’ll reduce firefighting later and build trust with buyers.

Your next steps: – Automate SBOM generation and tie it to builds and releases. – Standardize on a format, validate it, and set a sharing policy. – Add VEX to reduce noise and accelerate response. – Submit thoughtful comments to CISA so the new guidance solves real‑world problems.

If you found this analysis helpful, consider subscribing for future updates on SBOM policy, tooling, and best practices. We’ll track the CISA process and translate changes into clear, actionable steps you can use.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring! 

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

Read more related Articles at InnoVirtuoso

InnoVirtuoso

Hello there! I'm passionate content writer navigating the digital landscape. With a deep love for words and an insatiable curiosity about technology.

With 10 years of experience in IT field, I write mostly about emerging tech, sharing news, informational articles and covering other topics I find interesting.

Let's craft the future of content together – one word at a time!

Browse InnoVirtuoso for more!