# Standardizing AI Risk: The Push for AI Bills of Materials in 2026
As artificial intelligence systems increasingly power critical business decisions—from fraud detection to medical diagnostics—organizations face a mounting problem: they don't actually know what they're deploying. Unlike traditional software, AI models arrive with opaque supply chains, hidden dependencies, and unclear training data provenance. This blind spot is driving a global push to implement AI Bills of Materials (AI BOMs), a standardized approach to documenting what's inside machine learning systems before they reach production.
The movement is accelerating rapidly. Standards organizations, open-source projects, and commercial vendors are converging on what could become the industry's first unified framework for AI transparency. By 2026, AI BOMs are no longer theoretical—they're becoming practical, toolable, and increasingly demanded by regulators. The question is no longer *whether* organizations will adopt them, but *when*.
## The Threat: Unknown Dependencies in AI Systems
Organizations deploying AI models face unprecedented supply chain risks. A single model might depend on dozens of pre-trained datasets, libraries, and third-party components—most of which are invisible to the deploying team. This opacity creates several critical vulnerabilities:
Data poisoning at scale: Training datasets pulled from unvetted sources can inject adversarial examples or biased data that degrade model performance or enable attacks downstream.
Hidden model vulnerabilities: Pre-trained models used as foundation layers may contain exploitable flaws that propagate through downstream applications.
License and compliance risks: Commercial AI systems often mix open-source components with incompatible licensing, exposing organizations to legal liability.
Provenance gaps: When a model fails or behaves unexpectedly in production, teams struggle to trace the failure back to its source—whether it's a data issue, a training procedure, or a dependency problem.
Supply chain attacks: Adversaries can poison models at the source (training data, base model, dependencies) with effects that ripple across thousands of downstream deployments.
Traditional software addressed these risks through Software Bill of Materials (SBOMs)—standardized lists of components, versions, and known vulnerabilities. AI BOMs aim to bring that same rigor to machine learning systems.
## Background and Context: From Software to AI
SBOMs emerged as a practical tool to combat software supply chain attacks. After high-profile incidents like the SolarWinds compromise and the Log4Shell vulnerability, organizations realized they couldn't defend what they couldn't enumerate. An SBOM answers a basic question: *What's in this software, and what are the risks?*
AI systems demand the same transparency, but with added complexity. A machine learning model isn't just code—it's a combination of:
Without documentation, teams deploying AI models operate blind. They can't assess risk, validate compliance, or respond effectively when vulnerabilities emerge.
## Technical Details: Standards Taking Shape
Two major standards organizations have stepped forward to define AI BOM frameworks:
OWASP CycloneDX with AI Extensions
The Open Web Application Security Project's CycloneDX standard—already widely adopted for software SBOMs—released AI-specific extensions. OWASP's AI SBOM Initiative meets weekly in open sessions and has developed the OWASP AI BOM Generator, an open-source tool that automatically generates AI BOMs from Hugging Face models in CycloneDX-compliant format.
This approach leverages existing SBOM infrastructure while adding AI-specific fields:
SPDX Standard (Version 3.0) with AI Profiles
The Linux Foundation's SPDX standard, released in version 3.0, added dedicated AI and Dataset profiles that provide structured field mappings for model training details and data provenance. SPDX offers a complementary approach to CycloneDX, with emphasis on dataset lineage and training transparency.
Model Signing and Cryptographic Verification
The OpenSSF AI/ML Working Group formalized a model-signing specification in 2025, with contributions from Google, HiddenLayer, and NVIDIA. This enables cryptographic verification of model integrity—ensuring a model hasn't been tampered with between creation and deployment.
CISA's Foundational Guidance
The U.S. Cybersecurity and Infrastructure Security Agency published AI SBOM Tiger Team guidance in 2025, offering government-backed best practices. However, recent personnel cuts have cast uncertainty over CISA's capacity to maintain and evolve this initiative, potentially leaving a guidance gap.
## Commercial Momentum: Vendors Adopt AI BOM Tooling
Standards alone don't drive adoption. Vendors are embedding AI BOM capabilities into security platforms:
| Vendor | Tool | Launch Date | Approach |
|--------|------|------------|----------|
| Manifest Cyber | AI Supply Chain Security Product | Summer 2025 | Built with defense and automotive partners; 18+ months of AIBOM generation |
| Cycode | AI & ML Inventory + BOM Generation | October 2025 | Integrated into application security posture management (ASPM) platform |
| JFrog | Universal MCP Registry | March 2026 | Extends artifact management to treat AI models with same rigor as software |
| Apiiro | AI Model Tracking | 2026 | Similar integration into security posture management |
This vendor alignment is critical: it translates standards from white papers into usable tools that development and security teams can integrate into existing workflows.
Academic Progress: The January 2026 paper introducing AIBoMGen presented a proof-of-concept platform for generating cryptographically signed AI BOMs during model training, demonstrating feasibility at scale.
## Implications: Who Must Care Now
AI Development Teams: If you're building or fine-tuning models, you'll soon need to document provenance, training procedures, and dependencies in a standardized format. This is shifting from "nice to have" to compliance requirement.
Security and Risk Teams: AI BOM adoption enables your organization to:
Regulators and Compliance Officers: The EU AI Act's requirements for high-risk AI systems implicitly demand BOM-like documentation. Organizations in regulated sectors (finance, healthcare, autonomous systems) will face explicit BOM requirements within 12-24 months.
Third-Party AI Consumers: Organizations using commercial AI APIs or models from vendors must demand BOMs from their suppliers. Without them, you can't properly assess risk or maintain your own compliance posture.
## Recommendations: Getting Started in 2026
1. Audit Your AI Inventory
Catalog every AI/ML system in your organization, noting:
2. Adopt a Standard Now
Choose between OWASP CycloneDX or SPDX 3.0 and begin generating BOMs for new AI systems immediately. CycloneDX is simpler for teams already using SBOM tools; SPDX offers richer dataset provenance tracking.
3. Demand BOMs from Vendors
Require AI BOM documentation from any third-party AI model or service you consume. Start with your highest-risk systems (production ML pipelines, customer-facing AI).
4. Integrate into Your ASPM Workflow
Use tools like Cycode, JFrog, or Manifest Cyber to automate BOM generation and integrate it into your existing security posture management pipeline.
5. Plan for Model Signing
As cryptographic model verification becomes standard, plan to adopt OpenSSF's model-signing specification for any models you develop or distribute internally.
---
## HackWire Analysis
AI BOMs represent a critical inflection point in AI governance. For years, the industry treated machine learning systems as black boxes—useful but opaque. The current push toward standardized BOMs suggests we're finally treating AI as infrastructure worth understanding, not just deploying.
The timing matters. The EU AI Act doesn't explicitly mandate BOMs, but it demands transparency and risk assessment that are impossible without them. Regulatory pressure is the accelerant here. Organizations that wait for explicit legal requirements will find themselves rushing to retrofit documentation onto systems already in production—expensive and error-prone.
What's striking is the vendor-standards alignment. Typically, standards lag commercial adoption. Here, standards bodies (OWASP, Linux Foundation, OpenSSF) and vendors (JFrog, Cycode, Manifest) are moving in lockstep. This suggests AI BOMs will reach practical adoption faster than previous security standards. By Q4 2026, expecting a BOM for any new AI system should be normal, not exceptional.
The hidden risk: governance gaps. CISA's personnel cuts undermine the U.S. government's ability to maintain guidance and evolve standards. That leadership vacuum may shift to the EU (which has regulatory authority) or to vendor consortia. Organizations should monitor this carefully—regulatory definitions of "adequate" AI BOM documentation could harden around SPDX or CycloneDX, making early adoption decisions significant.
For defenders, this is a win. For the first time, there's a practical path to inventory, assess, and monitor AI risk at the supply chain level. Organizations moving now build institutional knowledge and tooling before BOMs become mandatory compliance work.
— *HackWire Editorial*
---
## Related Coverage