From SBOM to AI-BOM: The Evolution of AI Supply Chain Governance

How software composition analysis is expanding from dependency scanning and SBOMs into AI-BOMs, code provenance and AI supply chain security. 

Artificial Intelligence is no longer a future trend. It is already embedded in modern software development workflows: AI coding assistants, generative AI platforms, machine learning models and AI-powered agents are part of everyday practices as we thrive towards 100% AI adoption. Considering this path, the traditional Software Bills of Materials (SBOMs) and software composition analysis processes are no longer sufficient on their own. They must be extended and transformed to provide the level of transparency, traceability and risk management required by modern AI systems. 

The next stage of software governance means expanding our visibility and compliance controls to include AI-generated code, AI models, datasets, agents and their associated provenance information. This is where the concept of AI Bill of Materials (AI BOM) becomes increasingly important. AI components must become part of the software supply chain inventory, just as open-source dependencies are today. 

Evolution of software supply chain governance  

For years, SBOMs have helped organizations understand which software components sit inside their products, enabling vulnerability management,  license compliance, and supply chain transparency. But AI systems introduce layers that traditional SBOMs were never designed to capture. 

Modern AI solutions depend not only on software libraries and packages, but also on foundation models, training and fine-tuning datasets, prompts, agents, evaluation artefacts, provenance information and a complex set of licensing and copyright obligations. An AI-BOM does not replace the SBOM, it extends it, documenting the AI-specific elements that a conventional SBOM misses: 

• Foundation models and Large Language Models (LLMs) 
• Training and fine-tuning datasets, with data provenance 
• AI frameworks and libraries 
• Agents, prompts and embeddings 
• Evaluation and testing artefacts 
• Model provenance and lineage 
• Licensing, copyright and governance information 

AI-generated code provenance and snippet-level compliance 

A developer may accept many suggestions from an AI coding assistant, which means generated code snippets can enter repositories without ever appearing in a dependency manifest. The code may be functionally correct, but its provenance is often unclear. This creates a new category of risk: code provenance and snippet-level compliance. 

Modern AI coding assistants provide some level of safety, but merely enough. For example, some solutions can identify similarities between generated code and publicly available repositories, however, these controls have limitations and do not provide complete visibility across all potential sources. 

As a result, the industry must evolve towards a multi-layered approach: 

• Built-in AI assistant controls and code reference capabilities. 
• Snippet and similarity detection for identifying potentially licensed code fragments. 
• Policy enforcement, audit reporting and compliance workflows. 

The key governance principle is simple: AI-generated code should be treated as third-party content until its provenance and obligations have been assessed. 

Developers remain accountable for all committed code, regardless of how it was generated. AI-produced code must be subject to the same quality and security reviews as human-written code and significant AI-assisted contributions should be disclosed during development and review processes. 

As a result, SBOM evolving to AI BOM in software governance programs is a natural step. Scanning and compliance platforms should not only detect vulnerable software dependencies, but also identify AI-generated code, perform provenance and similarity analysis, capture model and dataset metadata, generate AI BOM artifacts alongside traditional SBOMs and support the audit, customer and regulatory evidence requirements that are becoming increasingly important in the age of AI. 

AI BOMs should not be viewed as separate compliance documents, but as a natural evolution of existing SBOM-driven governance practices.  

EU AI Act makes transparency a business requirement 

The growing focus on AI BOMs is not driven solely by engineering best practice. Regulatory developments are making transparency an operational requirement, and the time companies have been ready is short, especially now that the EU AI Act has entered its implementation phase. General-purpose AI model obligations are already in force, while further transparency obligations are applicable from August 2026. These requirements place significant emphasis on documentation, copyright compliance, transparency and the ability to demonstrate how AI systems are built and operated. 

This shift has important implications for organizations that have broad AI adoption: 

• Organizations must understand whether they act as AI providers, deployers, or both. 
• AI systems require documented governance and risk assessment processes. 
• Transparency obligations must rely on evidence and traceability. 
• Documentation surrounding datasets, models, dependencies and generated content are essential. 

Recognising that AI systems require visibility beyond the scope of traditional software inventories, the U.S. Cybersecurity and Infrastructure Security Agency (CISA), in collaboration with G7 international partners, including the European Union, published the Software Bill of Materials for AI – Minimum Elements guidance. This initiative acknowledges the need for greater transparency into AI models, datasets, dependencies, and other AI-specific artefacts that are not adequately captured by conventional Software Bills of Materials (SBOMs).