An AI Software Bill of Materials (AI SBOM) is a machine-readable, versioned inventory that documents every component in an AI system: the base model weights, training datasets, fine-tuning pipelines, inference libraries, container images, and their transitive dependencies. For European sovereign on-premises deployers operating under the Cyber Resilience Act (CRA), NIS-2, GDPR, or DORA, the AI SBOM is no longer an optional engineering artefact. It is a legal instrument, a procurement filter, and a primary defence against supply-chain compromise.
The G7 Minimum Elements for an AI SBOM: What They Add to Existing Frameworks
The G7 Hiroshima AI Process, advanced under German and Italian co-chairmanship in 2024, produced a set of minimum elements for an AI SBOM that go substantially beyond what a conventional software SBOM captures. A standard SBOM, as defined by NTIA guidance and now codified in CRA Annex I, records package names, versions, suppliers, and dependency relationships for compiled or interpreted software. The G7 AI SBOM minimum elements add four categories that are unique to AI systems.
First, model weight provenance: the specific checkpoint version, the repository and release tag from which weights were obtained, and a cryptographic hash (SHA-256 or SHA-3) binding the recorded identity to the actual file. Second, training data lineage: the datasets used in pre-training and instruction tuning, their origin licences, any known data contamination disclosures, and the dates of data cuts. Third, fine-tuning pipeline dependencies: every preprocessing script, tokeniser version, PEFT or LoRA adapter configuration, and quantisation step, each treated as a versioned component. Fourth, evaluation and alignment metadata: the benchmarks and safety evaluations applied before deployment, including which model version was tested.
These elements directly address risks that a pure code SBOM cannot surface. A poisoned training dataset leaves no trace in a dependency graph of Python packages. A silently substituted weight file may pass checksum validation on the container layer but not on the model file itself. The G7 framework treats the model as a first-class supply-chain component, not merely a binary blob consumed by a software stack.
Generating and Maintaining an AI SBOM for Mistral and Llama Deployments
Sovereign on-premises deployments of open-weight models such as Mistral 7B, Mistral Mixtral 8x7B, or Meta Llama 3 require a structured generation process that does not call external cloud endpoints at any stage.
The full dependency graph
The AI SBOM for an on-premises Mistral or Llama inference stack must cover at least six layers: (1) the model weight files with SHA-256 digests and the originating Hugging Face repository commit hash; (2) the inference runtime, typically vLLM, llama.cpp, or Hugging Face Transformers, with pinned version tags; (3) CUDA or ROCm driver and toolkit versions, which are frequently the source of CVEs that affect GPU-accelerated inference; (4) the Python environment, captured via a pip freeze or conda lock file and serialised into SPDX or CycloneDX format; (5) the container image, identified by its registry digest rather than a mutable tag; and (6) any fine-tuning adapters, LoRA weights, or GGUF quantisation artifacts, each with their own provenance record.
Tooling that runs without external dependencies
Syft, maintained by Anchore, generates CycloneDX and SPDX SBOMs from container images and filesystems entirely on-premises. Trivy adds vulnerability correlation against local offline databases. For the AI-specific layers, the process must currently be partially scripted: a CI/CD pipeline step that computes SHA-256 hashes of weight shards, records the Hugging Face commit reference, and serialises that output into the same CycloneDX document as the software dependencies. The resulting unified artefact should be signed with a private key held under the organisation’s own key management infrastructure, not a cloud-hosted signing service.
Sonatype recorded a 245% year-on-year increase in malicious packages published to open-source registries between 2022 and 2023 (Sonatype State of the Software Supply Chain, 2023). This figure, which predates the mass adoption of AI inference libraries, makes automated, continuous SBOM regeneration on every model or dependency update a security necessity rather than a compliance checkbox.
Mapping G7 AI SBOM Elements to CRA Article 13 and Annex I
The CRA, published in the Official Journal of the European Union in 2024, places SBOM obligations in Article 13(3) and Annex I, Part II. Manufacturers of products with digital elements must produce and maintain an SBOM “in a commonly used and machine-readable format” covering all third-party components. A sovereign deployer who fine-tunes Mistral or Llama and deploys the result as a product or internal tool that meets the CRA’s “product with digital elements” threshold is a manufacturer for these purposes.
| Requirement area | G7 AI SBOM minimum element | CRA Annex I / Article 13 obligation | Single artefact approach |
|---|---|---|---|
| Software dependencies | Inference libraries, CUDA toolkit, container image | All third-party components, versions, and known vulnerabilities | CycloneDX components section covers both |
| Model identity | Weight file hash, repository commit, checkpoint version | Not explicitly listed; covered under “third-party component” if model is third-party | Add as a CycloneDX “mlModel” component type |
| Training data provenance | Dataset names, licences, data cut dates, contamination disclosures | Not addressed in current Annex I text | Extend CycloneDX document with a custom “aiDatasets” property block |
| Fine-tuning pipeline | LoRA adapters, PEFT configs, quantisation steps | Custom components produced by manufacturer under Article 13(1) | Record as first-party components with internal version tags |
| Vulnerability tracking | Known CVEs in listed components | Mandatory; must be kept current for product lifetime | Automate via Trivy with offline NVD/EUVD feed |
NIST states in the AI Risk Management Framework (AI 100-1): “Trustworthy AI requires that the components used to build AI systems are traceable, verifiable, and that their provenance can be established throughout the supply chain.” This framing aligns directly with what both the G7 elements and the CRA demand, making the NIST AI RMF a useful internal governance reference alongside the two mandatory frameworks.
AI SBOM as a Tool for Model Poisoning and Supply-Chain Injection Detection
61% of organisations reported being directly affected by a software supply-chain attack in 2023 (Sonatype State of the Software Supply Chain, 2023). For sovereign AI deployers, the threat surface extends beyond code: a poisoned dataset, a substituted weight checkpoint, or a backdoored LoRA adapter can alter model behaviour in ways that no conventional vulnerability scanner will detect.
An AI SBOM enables three specific defensive practices. First, hash-based integrity verification: by recording the SHA-256 digest of every weight shard at the time of initial deployment, the organisation can run automated checks on each restart or update cycle and detect silent substitution. Second, dataset provenance auditing: if a training dataset is later found to contain adversarially crafted examples (a documented technique in model poisoning research), the SBOM’s data lineage record identifies which model versions were trained on the affected data and which were not. Third, dependency diff alerting: automated comparison of SBOM versions across releases surfaces new transitive dependencies introduced by library updates, which is the primary injection vector for conventional supply-chain attacks replicated into AI inference stacks.
Vulnerability Disclosure Obligations Under the CRA for AI-Specific Components
When a sovereign deployer identifies a critical vulnerability in a third-party AI component documented in its AI SBOM, for example a remote code execution flaw in vLLM or a known backdoor in a publicly distributed LoRA adapter, the CRA’s disclosure timeline applies. Article 13 requires an early warning to the CRA single reporting platform within 24 hours of becoming aware of an actively exploited vulnerability, followed by a detailed notification within 72 hours.
The CRA single reporting platform feeds into the ENISA European Vulnerability Database (EUVD), which serves as the EU’s authoritative registry for product vulnerabilities and is positioned to supersede reliance on the US-operated NVD for EU regulatory purposes. For AI-specific vulnerabilities that do not yet have a CVE identifier (model poisoning issues, for instance, often do not), deployers should file with ENISA directly and document the disclosure in their AI SBOM’s vulnerability record section.
The European Parliament and Council state in the CRA: “Manufacturers placing products with digital elements on the market shall ensure that vulnerabilities in those products are handled effectively and for the expected product lifetime.” For an AI product, the “expected product lifetime” extends through every fine-tuning cycle and weight update, making continuous SBOM maintenance, not one-time generation, the operative obligation.
The global average cost of a data breach reached USD 4.88 million in 2024 (IBM Cost of a Data Breach Report, 2024). Supply-chain-originated breaches, which involve compromised components documented or undocumented in SBOMs, consistently rank among the highest-cost breach categories, reinforcing the financial case for proactive AI SBOM maintenance.
Using the AI SBOM as a Procurement Due Diligence Instrument
Regulated organisations evaluating open-weight foundation models or fine-tuning service providers should treat the AI SBOM as a mandatory procurement deliverable, not a post-contract artefact. The procurement due diligence process should require the following before any contract is signed.
A machine-readable AI SBOM in CycloneDX 1.6 or SPDX 2.3 format, covering the base model version with cryptographic hash, all training datasets with licence types and data cut dates, the complete Python and CUDA dependency graph, and container image digests. A signed attestation, under the organisation’s own PKI or a notarised equivalent, confirming that no component originates from a jurisdiction whose laws permit compelled secret disclosure of customer data without prior notification. This directly addresses the CLOUD Act, FISA 702, and similar foreign-jurisdiction exposure vectors. A disclosure of any data that transited non-EU infrastructure during training or fine-tuning, including inference API calls made to external services during data preprocessing.
For fine-tuning service providers specifically, the organisation should require evidence that the fine-tuning pipeline itself has been SBOM-documented and that the resulting adapter weights are delivered with their own provenance record. A provider who cannot produce this artefact should be treated as presenting unquantifiable supply-chain risk under the NIST AI RMF’s GOVERN and MAP functions, regardless of their commercial reputation.
FAQ
Does an AI SBOM replace a conventional software SBOM under the CRA?
No. CRA Annex I requires a standard SBOM covering all software dependencies. An AI SBOM extends that baseline with AI-specific fields such as model weights, training data provenance, and fine-tuning pipeline metadata. A sovereign deployer should produce a combined artefact or a clearly linked pair of documents to satisfy both layers.
Are open-weight model deployers considered “manufacturers” under the CRA?
Yes, if they significantly modify the model or integrate it into a product with digital elements placed on the EU market. Downstream fine-tuning, quantisation, or embedding Mistral or Llama into a product typically triggers manufacturer obligations under CRA Article 13, including SBOM production and vulnerability reporting.
How quickly must a sovereign deployer report an actively exploited AI component vulnerability under the CRA?
The CRA requires an early warning to the CRA single reporting platform within 24 hours of becoming aware of an actively exploited vulnerability, followed by a detailed notification within 72 hours. ENISA coordinates the EUVD as the central registry where these reports are ultimately published.
Can AI SBOM generation tooling run fully on-premises without sending data to external services?
Yes. Tools such as Syft and Trivy can be deployed entirely on-premises with offline vulnerability database feeds. Model hash verification using SHA-256 or SHA-3 can be automated via CI/CD pipelines without any external cloud call, preserving data sovereignty throughout the process.
What should a regulated organisation demand from a fine-tuning service provider in terms of AI SBOM artefacts?
The organisation should contractually require delivery of a machine-readable AI SBOM in CycloneDX or SPDX format covering the base model version and cryptographic hash, all training and fine-tuning datasets with provenance records, the full Python and CUDA dependency graph, container image digests, and a signed attestation that no component originates from a jurisdiction whose laws permit compelled secret disclosure.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.