SBOM — Standard & ML-Specific Components

The AI system’s supply chain extends well beyond traditional software dependencies. The SBOM must capture five component categories. Software dependencies include ML frameworks (TensorFlow, PyTorch, scikit-learn), data processing libraries (Pandas, NumPy, Apache Spark), serving frameworks (Triton, TorchServe), and their transitive dependencies. Model components include pre-trained foundation models, embedding models, tokenisers, and any third-party model weights.

Infrastructure components include container base images, operating system packages, and cloud service configurations. Data processing components include annotation tools, data labelling services, and data enrichment APIs. External service dependencies include third-party model APIs, vector database services, and managed ML platform services (SageMaker, Vertex AI, Azure ML).

CycloneDX’s ML extension supports all five categories, allowing the SBOM to reference model artefacts with their provenance metadata alongside traditional software components. For CRA-scoped products, the SBOM format and content may need to align with implementing guidance from the Commission. The AI System Assessor monitors guidance updates and adjusts the SBOM generation accordingly. addresses the generation process; this article addresses the content scope.

Key outputs

• Five-category SBOM scope (software, model, infrastructure, data, services)
• CycloneDX ML extension for model component documentation
• CRA alignment where applicable
• Module 9 AISDP evidence

SBOM — CI/CD Integration & Format

The SBOM is generated automatically by the CI pipeline for every build, ensuring that each release has a current, accurate dependency inventory. Syft scans the container image and code repository, producing the SBOM in CycloneDX or SPDX format. CycloneDX is the preferred format for ML systems because its ML extension supports model components, datasets, and services alongside traditional software libraries. SPDX (an ISO/IEC standard) may be required for CRA compliance depending on implementing guidance.

The generated SBOM is stored as a pipeline artefact alongside the container image it describes. Cosign attestation links the SBOM to the specific container image version, creating a verifiable chain between the image and its dependency inventory. The pipeline fails if SBOM generation fails, ensuring that no release proceeds without an up-to-date dependency record.

For CRA-scoped products, three alignment points require verification. Implementing guidance from the Commission may impose specific SBOM format requirements. The CRA requires ongoing SBOM updates throughout the product lifecycle; automated generation on every build satisfies this. The CRA may require SBOM delivery to deployers; Module 8’s transparency documentation should reference the delivery mechanism. The AI System Assessor monitors CRA guidance updates and adjusts the SBOM generation accordingly.

Key outputs

• Automated SBOM generation per build in the CI pipeline
• CycloneDX or SPDX format with cosign attestation
• Pipeline failure on SBOM generation failure
• Module 9 AISDP evidence