Post

Why Your SBOMs Probably Don't Meet CISA's 2026 Requirements (And How to Fix It)

Ensure your SBOMs meet CISA's 2026 requirements. Learn to identify and fix critical gaps in open-source, AI, and SaaS component coverage.

Why Your SBOMs Probably Don't Meet CISA's 2026 Requirements (And How to Fix It)

If your SBOM generation pipeline hasn’t been updated since 2023, it’s already obsolete. The new CISA guidance for 2026 isn’t a minor patch; it’s a fundamental expansion of what a “minimum viable SBOM” means, and most current tooling running on default settings will fail the audit. You’re likely missing hashes, license data, and the entire new worlds of AI and SaaS dependencies.

TL;DR: CISA’s 2026 SBOM guidance mandates new minimum elements like component hashes and licenses, and dramatically expands the scope to include AI/ML models and SaaS dependencies. Most teams are not prepared for this shift. This post breaks down the new requirements, provides a gap-analysis checklist, and shows you how to bring your tooling into compliance.

What you’ll walk away with:

  • A clear comparison table of the old vs. new CISA minimum elements.
  • An understanding of how to scope SBOMs for AI models and SaaS.
  • A checklist to audit your current SBOM generation process for compliance gaps.
  • Concrete examples of what a compliant SBOM fragment looks like.

What Are CISA’s New “Minimum Elements” for SBOMs?

The new minimum elements are an extension of the original NTIA “Minimum Elements For a Software Bill of Materials,” adding requirements for cryptographic hashes, license information, and expanded dependency relationship data. The goal is to move beyond simple component naming to providing verifiable, actionable data for vulnerability management and license compliance. This isn’t just about federal compliance; it’s the new baseline for commercial supply chain security.

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of software components, dependencies, and their hierarchical relationships. Think of it as a detailed ingredients list for a piece of software, essential for identifying and mitigating security and license risks.

The most significant changes are the mandatory inclusion of component hashes and the explicit requirement to list licenses. Previously, many generators omitted these unless explicitly configured. According to CISA, a component without a hash is ambiguous, and a component without a license is a legal black box.

Element NTIA 2021 (Baseline) CISA 2026 (New Mandate) Why It Matters
Component Hash Optional Required (SHA-256, SHA3, etc.) Unambiguously identifies the exact version of a component, eliminating PURL/CPE naming conflicts and verifying integrity.
License Info Optional Required Essential for automated license compliance checks and identifying components with restrictive or incompatible licenses.
AI/ML Models Out of Scope In Scope AI systems are now part of the software supply chain. SBOMs must cover models, training data, and frameworks.
SaaS Dependencies Ambiguous In Scope If your application’s core functionality depends on a SaaS API, that service is a dependency that must be documented.
Component Relationships Basic DependsOn More granular relationships Enables more sophisticated dependency graph analysis, like distinguishing a test dependency from a runtime dependency.

The mandatory inclusion of component hashes is the single most important technical change. It’s the difference between saying you use log4j and proving you use log4j-core-2.17.1.jar with SHA-256 hash _..._.

How Do AI/ML Models and SaaS Fit into the New SBOM Scope?

CISA’s guidance now requires you to treat AI/ML models and critical SaaS dependencies as first-class components in your SBOM. For AI, this means inventorying not just the Python libraries like TensorFlow but the specific pre-trained model weights and even the datasets used for training. For SaaS, it means if your app breaks when a specific third-party API is down, that API is a dependency.

This shift forces a much broader view of your application’s attack surface. Your dependency tree is no longer just the code you compile; it’s the entire distributed system your application relies on. Visualizing this helps clarify the expanded scope.

flowchart LR
    subgraph Your Product
        App["Application Code"]
        Lib["Internal Library"]
    end

    subgraph Third-Party Dependencies
        OSS["Open Source<br/>(e.g., Log4j)"]
        AI_Model["AI Model<br/>(e.g., Llama 3)"]
        SaaS["SaaS API<br/>(e.g., Stripe)"]
    end

    subgraph AI Model Components
        Framework["ML Framework<br/>(e.g., PyTorch)"]
        Dataset["Training Dataset"]
    end

    App --> Lib
    App --> OSS
    App -- "API Call" --> SaaS
    App -- "Inference" --> AI_Model
    AI_Model --> Framework
    AI_Model --> Dataset

Getting an SBOM for a SaaS provider is the hardest part. It requires their cooperation. Start by demanding SBOMs or equivalent attestations in your vendor contracts. If a critical vendor can’t provide one, that’s a significant supply chain risk you need to formally accept or mitigate. This is where you might use a tool to generate a VEX (Vulnerability Exploitability eXchange) document to track their vulnerability status.

Integrating AI model details is also a new discipline. When considering how to integrate AI into your security pipeline, SBOM generation for the models themselves must be a core requirement, not an afterthought.

Treat SaaS providers like any other software supplier. If they won’t provide an SBOM for a service critical to your operation, you have a blind spot.

Which SBOM Tools Actually Support the New CISA Requirements?

Most modern SBOM generators like Syft, Trivy, or the official CycloneDX/SPDX libraries can produce formats that hold the new data. The problem isn’t the format; it’s the data collection process. You have to configure your tools to explicitly fetch hashes and licenses, and you need new processes to gather data for SaaS and AI components, which often can’t be found by static analysis alone.

Both SPDX and CycloneDX are excellent, machine-readable formats. CycloneDX is often favored for its focus on security use cases, while SPDX has deep roots in license compliance. For the new CISA requirements, both are fully capable. The choice is less important than the quality of the data you put into them.

Here’s the practical difference. Your old SBOM might have looked like this, missing the crucial new fields:

Click to see a diff between an old vs. CISA-compliant SBOM fragment (JSON)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
  {
    "bomFormat": "CycloneDX",
    "specVersion": "1.5",
    "components": [
      {
        "type": "library",
        "name": "log4j-core",
        "version": "2.17.1",
-       "purl": "pkg:maven/org.apache.logging.log4j/[email protected]"
+       "purl": "pkg:maven/org.apache.logging.log4j/[email protected]",
+       "licenses": [
+         {
+           "license": {
+             "id": "Apache-2.0"
+           }
+         }
+       ],
+       "hashes": [
+         {
+           "alg": "SHA-256",
+           "content": "51b2c6328399652610204d8d16f55b9e4a33333333f0d480dd778e8748d86eef"
+         }
+       ]
      }
    ]
  }

Use this checklist to audit your own pipeline. If you can’t check every box, you are not ready for 2026.

  • Our primary SBOM generator tool is configured to capture SHA-256 hashes for every component.
  • Our tool is configured to resolve and include the SPDX-License-Identifier for every component.
  • We have an inventory of all critical SaaS dependencies.
  • We have a process for requesting and ingesting SBOMs from our SaaS vendors.
  • We have an inventory of all AI/ML models used in production.
  • We have a process for generating SBOMs that include model parameters and training data sources.
  • Our CI/CD pipeline fails if an SBOM cannot be generated or if it’s missing critical fields.

You can use configuration management tools to enforce these checks across your fleet. Automating this compliance is a perfect use case for something like Ansible security automation.

Don’t just check if your tool can support the new fields. Check if it is configured to, and fail the build if it isn’t.

Bottom Line

The CISA 2026 SBOM requirements are not a future problem; they are an immediate call to action. Your current SBOMs are likely non-compliant, exposing you to supply chain blind spots. The work to inventory SaaS and AI dependencies must start now, as this is a process and procurement challenge, not just a technical one.

In the next post, we’ll dive into VEX (Vulnerability Exploitability eXchange) and how it’s becoming non-negotiable for communicating risk alongside your SBOMs.

FAQ

What is the deadline for CISA 2026 SBOM compliance?

There isn’t a single “deadline.” The guidance reflects evolving federal procurement requirements and industry best practices. Federal agencies will increasingly require this level of detail in contracts starting well before 2026.

Do I need an SBOM for internal-only software?

Yes. The primary purpose of an SBOM is managing operational risk, which doesn’t disappear just because software is internal. An internal service with a critical vulnerability can be just as damaging if exploited.

What’s the difference between SPDX and CycloneDX?

Both are industry-standard SBOM formats. SPDX (Software Package Data Exchange) originated from the Linux Foundation with a strong focus on license compliance. CycloneDX originated from OWASP with a security-first focus. Both are excellent and can meet the CISA requirements.

How do I get an SBOM from a SaaS provider?

Start by asking. Make it a requirement in your procurement and renewal contracts. If they cannot provide one, ask for alternative security attestations and formally document it as a risk.

Does the CISA guidance apply to non-government software?

While CISA’s direct authority is over federal civilian agencies, its guidance sets the de facto standard for the entire software industry. Commercial clients, insurance providers, and partners will expect you to meet this baseline.

Part of the series: sbom-2026-compliance

  1. Why Your SBOMs Probably Don't Meet CISA's 2026 Requirements (And How to Fix It) (you are here)
  2. Automate Your SBOM Generation: Painful Old Ways vs. CISA 2026's New Mandates
  3. Is Your SBOM-Driven Risk Assessment Actionable? A 5-Minute Audit for CISA 2026 Compliance

Further Reading


🚀 Ready to get hands-on? Spin up an interactive AI or Kubernetes Sandbox at Aicademy Labs for free.

This post is licensed under CC BY 4.0 by the author.