Software Bills of Materials (SBOMs) have gained significant traction for traditional software. Executive Order 14028, CISA guidance, and industry standards like SPDX and CycloneDX have established SBOMs as a foundational element of software supply chain security. But as AI and machine learning models become embedded in critical systems, a question is emerging: do we need SBOMs for AI models, and what would they look like?
The answer to the first question is unambiguously yes. The answer to the second is still being worked out, but the contours of an AI/ML SBOM are becoming clearer.
Why AI Models Need SBOMs
Traditional SBOMs document the components that make up a piece of software: libraries, frameworks, dependencies, and their versions. This transparency enables vulnerability tracking, license compliance, and supply chain risk assessment. AI models have analogous transparency needs, but the "components" are different.
An AI model is the product of:
Training data. The datasets used to train the model fundamentally determine its capabilities, biases, and failure modes. Knowing what data was used, how it was collected, and what licenses govern its use is essential for risk assessment.
Model architecture. The specific neural network architecture, including layer types, sizes, and configurations, determines the model's computational requirements and potential vulnerabilities.
Training code and frameworks. The software used to train the model (PyTorch, TensorFlow, JAX) and the specific training scripts, hyperparameters, and optimization techniques are all components that can contain vulnerabilities or introduce biases.
Fine-tuning and alignment data. For large language models, the reinforcement learning from human feedback (RLHF) data and instruction-tuning datasets are critical components that shape the model's behavior.
Pre-trained model dependencies. Many models are fine-tuned from pre-trained base models. The provenance of the base model is a supply chain dependency that should be tracked.
Inference infrastructure. The serving stack, including model formats (ONNX, TensorRT, etc.), quantization settings, and inference frameworks, affects both performance and security.
Emerging Standards and Frameworks
Several initiatives are working to define what AI/ML SBOMs should contain:
CycloneDX ML-BOM
The CycloneDX standard, maintained by OWASP, added Machine Learning Bill of Materials (ML-BOM) support in version 1.5. The ML-BOM specification includes fields for:
- Model type and architecture
- Training datasets with source and licensing information
- Quantitative analysis (performance metrics)
- Input/output specifications
- Environmental considerations (compute used for training)
CycloneDX's approach integrates ML-BOM with the existing SBOM framework, allowing organizations to document both the software components and the ML model components in a single, unified format. This is particularly useful for applications where traditional software and ML models are combined.
SPDX AI Profile
SPDX 3.0, the latest version of the Linux Foundation's SPDX standard, includes an AI and Dataset profile that extends the base SPDX model with AI-specific fields. The AI profile supports documentation of:
- Training data packages with provenance
- Model packages with architecture and performance information
- Relationships between models, data, and software components
Model Cards
Introduced by Google researchers in 2018, Model Cards are a documentation framework for machine learning models. While not technically an SBOM format, Model Cards cover some overlapping ground, including model details, intended use cases, performance metrics, ethical considerations, and limitations. Many organizations use Model Cards as a complement to more formal SBOM formats.
Hugging Face Model Documentation
The Hugging Face platform has implemented its own model documentation standards that include model architecture, training data, performance metrics, and usage guidelines. As the largest repository of open-source ML models, Hugging Face's standards significantly influence how the community documents and shares AI components.
The Unique Challenges
Creating SBOMs for AI models presents challenges that do not exist for traditional software:
Training data is messy. Traditional software dependencies are discrete packages with version numbers. Training data may be scraped from the internet, licensed from data providers, generated synthetically, or some combination. Documenting all data sources with sufficient granularity for meaningful risk assessment is difficult.
Model provenance is complex. A fine-tuned model depends on a base model, which was trained on specific data, which may itself be derived from other datasets. Tracking this chain of provenance requires documentation standards that can represent multi-level dependencies.
Reproducibility is hard. In traditional software, you can rebuild a binary from source and verify it matches the original (at least in theory with reproducible builds). Retraining an ML model from the same data and code may not produce identical weights due to non-deterministic GPU operations, different hardware, or minor framework version differences.
Dynamic behavior. Traditional software behaves deterministically given the same inputs. ML models produce probabilistic outputs that may vary based on quantization, serving configuration, and even hardware. This makes it harder to define what "the same model" means across different deployments.
Intellectual property concerns. Some organizations treat their training data, model weights, and training methodologies as trade secrets. Full transparency conflicts with these business considerations, requiring standards that can balance disclosure with confidentiality.
Practical Steps for Organizations
Even before AI/ML SBOM standards are fully mature, organizations can take practical steps:
Inventory your AI components. Know what models you are running, where they came from, and what they are connected to. Many organizations have deployed AI models in production without formal tracking.
Document training data provenance. For models you develop, maintain records of what training data was used, where it came from, and what licenses apply. This is both a security and a legal compliance requirement.
Track ML framework dependencies. The software stack used for model training and inference (PyTorch, TensorFlow, CUDA, etc.) has the same vulnerability management requirements as any other software dependency. Include ML frameworks in your standard SBOM processes.
Monitor model repositories. If you are pulling pre-trained models from Hugging Face or other repositories, treat them as dependencies that need vulnerability tracking and provenance verification.
How Safeguard.sh Helps
Safeguard.sh is extending its SBOM capabilities to address the emerging needs of AI/ML supply chain security. Our platform already tracks the software dependencies that underpin AI systems, including ML frameworks, CUDA libraries, and serving infrastructure. As AI/ML SBOM standards mature, Safeguard.sh will incorporate model-level tracking, enabling organizations to maintain a comprehensive inventory of both their software and AI components. For organizations deploying AI models in production today, Safeguard.sh provides the foundational supply chain visibility needed to manage the security risks that come with ML dependencies.