Is Your SBOM-Driven Risk Assessment Actionable? A 5-Minute Audit for CISA 2026 Compliance

Your SBOMs exist. But do they actually tell you anything useful about your risk, or are they just compliance artifacts gathering dust? The hard truth is that most software bills of materials fail the basic test of actionability.

TL;DR: Your SBOMs might tick a compliance box but fail CISA’s 2026 actionability test. Most are missing the critical data needed for automated risk assessment. This post gives you a 5-minute audit using jq to verify if your SBOMs contain the cryptographic hashes, AI component data, and SaaS dependency info needed to be genuinely useful.

Run this audit in 5 minutes. Grab a recent SBOM from one of your projects, save it as sbom.json, and run these checks. We’ll assume a standard CycloneDX JSON format for this walkthrough.

Click here for a sample sbom.json to use for the audit

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/[email protected]",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "50c357abc234a9a2a7a37452b3f55a1538356230ce7c83226c406b2b524623df"
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    },
    {
      "type": "library",
      "name": "commons-io",
      "version": "2.11.0",
      "purl": "pkg:maven/commons-io/[email protected]",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    },
    {
      "type": "saas",
      "name": "Stripe Payments API",
      "version": "v3",
      "description": "Payment processing service"
    },
    {
      "type": "machine-learning-model",
      "name": "distilbert-base-uncased",
      "version": "0.1.0",
      "purl": "pkg:huggingface/[email protected]",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "8f86f788b5e02b79471f5413e1645f5a8a4e101c40f803f2a8932c0293c83664"
        }
      ]
    }
  ]
}

Here’s your audit checklist. Go through each step; a finding is any command that produces output.

• Audit Step 1: Cryptographic Hashes
• Audit Step 2: License Data
• Audit Step 3: AI and SaaS Components

Does Your SBOM Contain Cryptographic Hashes?

An SBOM without component hashes is useless for verifying integrity. A cryptographic hash is a unique digital fingerprint (like SHA-256) for a file or component. CISA’s 2026 guidance mandates them because they are the only reliable way to confirm the software you built with is the exact, untampered software you think you built with.

This command finds any component missing a hashes array or where the array is empty. Any output is a finding.

jq '.components[] | select(.hashes == null or .hashes | length == 0) | .name' sbom.json

"commons-io"
"Stripe Payments API"

In this example, two components lack hashes. This means you can’t verify their integrity, making your supply chain vulnerable to tampering. This is a critical failure and a direct violation of CISA’s minimum requirements detailed in Why Your SBOMs Probably Don’t Meet CISA’s 2026 Requirements.

Mandate that your SBOM generator includes at least a SHA-256 hash for every single component. No exceptions.

Can You Automatically Detect License Risk?

Actionable SBOMs must include machine-readable license information. Without it, every new dependency requires a manual legal review, which simply doesn’t scale. Including a standard identifier (like an SPDX ID) allows security tooling to automatically flag components with restrictive or incompatible licenses.

This command finds components that are missing license information.

jq '.components[] | select(.licenses == null or .licenses | length == 0) | .name' sbom.json

"Stripe Payments API"
"distilbert-base-uncased"

Here, the SaaS API and the ML model are missing license data. This introduces unknown legal risk. Are you allowed to use that ML model in a commercial product? You can’t tell from this SBOM. This is where automation platforms can help by integrating checks directly into your workflow, as discussed in Ansible Security Automation: Automating Compliance & Remediation.

Use an SBOM tool that automatically resolves and embeds SPDX license identifiers during generation. Manually adding them later is a recipe for failure.

Is Your AI and SaaS Supply Chain a Black Hole?

Modern applications are not just code; they are assemblies of first-party code, open-source libraries, AI models, and SaaS APIs. Your SBOM must reflect this reality. If your SBOM only lists traditional packages, you have a massive blind spot regarding the risks inherited from your AI and SaaS providers.

The CycloneDX specification includes types like machine-learning-model and saas. This command checks for components correctly identified as such. An empty output here is a major red flag if you know you use these services.

jq '.components[] | select(.type == "machine-learning-model" or .type == "saas") | {name, type}' sbom.json

{
  "name": "Stripe Payments API",
  "type": "saas"
}
{
  "name": "distilbert-base-uncased",
  "type": "machine-learning-model"
}

The output shows our SBOM correctly identifies these component types. This is a crucial step for building a complete dependency graph, enabling a more holistic DevSecOps 2.0 security pipeline. If your SBOM tool can’t do this, it’s not fit for purpose in 2024.

graph TD
    A["Code + Dependencies"] --> B{SBOM Generator};
    B --> C["SBOM Document (JSON/XML)"];
    C --> D{Risk Analysis Engine};
    D -- "Vulnerabilities<br/>License Issues<br/>Integrity Failures" --> E["Actionable Security Ticket"];

If your SBOM generator doesn’t support AI and SaaS component types, replace it. The risk from these dependencies is real and growing.

Scoring Your Audit

Count the total number of findings (i.e., components that showed up in the output of the audit commands).

Findings	Grade	What It Means
0	Healthy	Your SBOMs are actionable and likely meet CISA’s 2026 baseline.
1-3	Needs	You have critical gaps. Your SBOMs are not providing a full risk picture.
4+	Deficient	Your SBOMs are compliance theater and offer little to no security value.

Now that you’ve audited your SBOM’s contents, the next post in this series will cover how to automate these checks and block non-compliant artifacts in your CI/CD pipeline.

Bottom Line

Stop treating SBOMs as a compliance checkbox to be filed away. If your SBOM can’t answer “what is this component’s hash?” and “what is its license?” in a machine-readable format, it’s failing its primary purpose. Run this 5-minute audit on your projects today and aggressively fix the gaps in your generation process.

FAQ

What is the main difference between CycloneDX and SPDX?

Both are standard SBOM formats. CycloneDX is designed for security use cases and operational dependency graphing, while SPDX (Software Package Data Exchange) originated from a focus on license compliance. Both are now widely used for security, but CycloneDX is often preferred for its richer component-type support.

Why does CISA require cryptographic hashes in SBOMs?

Hashes provide integrity. They allow you to verify that the component in your possession is the exact same one the developer published, free from tampering or corruption. Without a hash, you can’t be sure you’re analyzing the correct component.

How do I generate an SBOM for an AI model?

Use tools that specifically support AI/ML lifecycles. For models from platforms like Hugging Face, you can often use their APIs to get metadata. For custom models, tools can inspect model files (like .pkl or .safetensors) and their training dependencies to construct an SBOM entry.

Does an SBOM replace vulnerability scanning?

No, they are complementary. An SBOM lists your ingredients (the components). A vulnerability scanner takes that list and checks it against databases of known vulnerabilities (CVEs). You need the SBOM first to know what to scan.

What’s the easiest way to start generating SBOMs?

Integrate a tool into your build process. For Maven or Gradle, use the official CycloneDX plugins. For container images, use tools like Syft or Trivy. The key is to make generation an automatic, non-negotiable step of every build.

Part of the series: sbom-2026-compliance

1. Why Your SBOMs Probably Don't Meet CISA's 2026 Requirements (And How to Fix It)
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 (you are here)

Further Reading

• https://devops.com/cisas-2026-sbom-guidance-adds-hash-requirements-and-ai-coverage/
• https://www.cisa.gov/resources-tools/resources/software-bill-materials-sbom

---

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