Software Bill of Materials (SBOM)

An SBOM must be generated in a structured, standardized data format to enable automated processing by vulnerability scanners and policy engines. Human-readable PDFs or spreadsheets are insufficient.

• SPDX (Software Package Data Exchange): The ISO/IEC 5962 standard, ideal for license compliance tracking.
• CycloneDX: An OWASP standard optimized for security and vulnerability chaining, natively supporting hardware and services.
• SWID (Software Identification Tags): An ISO standard using XML to tag software with a unique identity, often used in endpoint management.

A robust SBOM captures the full recursive dependency tree, not just top-level libraries. This includes transitive dependencies—components included indirectly by direct dependencies—which are a primary vector for supply chain attacks.

• Direct Dependencies: Libraries explicitly linked by the developer.
• Transitive Dependencies: Sub-dependencies pulled in automatically by package managers.
• Graph Representation: The relationship between all components must be mapped to identify the blast radius of a single compromised library.

To prevent tampering, every component listed in an SBOM should be verifiable via a unique cryptographic hash. This allows a consumer to confirm that the artifact they received is bit-for-bit identical to the one the producer documented.

• SHA-256/SHA-512: The standard hashing algorithms used to generate a unique digital fingerprint of a file.
• Verification Process: A CI/CD pipeline compares the hash of a downloaded package against the hash recorded in the SBOM before deployment.
• Tamper Detection: Any mismatch indicates a potential compromise or corruption in the software delivery pipeline.

A VEX document is a companion artifact to an SBOM that provides a machine-readable statement on the exploitability of a known vulnerability in a specific product context. It prevents alert fatigue by filtering out irrelevant Common Vulnerabilities and Exposures (CVEs).

• Status Labels: Not Affected, Affected, Fixed, Under Investigation.
• Justification: Explains why a component is not exploitable (e.g., vulnerable code is not loaded or is blocked by a compiler flag).
• Continuous Authorization: VEX enables automated security gate approvals by proving a vulnerability has been triaged and deemed non-critical.

An SBOM should establish the provenance of each component, answering who built it, when, and from what source. This links the binary artifact back to its origin, ensuring it was produced by a trusted builder on a trusted platform.

• SLSA (Supply-chain Levels for Software Artifacts): A framework for verifying the integrity of the build process itself.
• In-toto Attestations: Signed metadata that provides a verifiable record of every step in the software supply chain.
• Build Signing: The SBOM itself must be digitally signed by the producer to guarantee its authenticity.

In the context of AI, an SBOM must extend beyond traditional software libraries to include model-specific artifacts that introduce unique risks, such as model weights and serialized data objects.

• Model Weights: The numerical parameters of a trained neural network, often stored in formats like .safetensors or .h5, which can harbor malicious code via serialization attacks.
• Training Datasets: A reference to the exact version and hash of the dataset used, critical for reproducibility and bias auditing.
• Fine-Tuning Adapters: Low-Rank Adaptation (LoRA) weights and other adapters that modify a base model's behavior must be inventoried as distinct components.