Software Bill of Materials (SBOM)

A robust SBOM captures the full transitive dependency tree, not just top-level libraries. This includes:

• Direct Dependencies: Components explicitly linked by the developer.
• Transitive Dependencies: Libraries pulled in by direct dependencies, often creating hidden attack surfaces.
• Depth of Analysis: A complete SBOM recursively enumerates all sub-components down to the root level, preventing the exploitation of deeply nested, unpatched vulnerabilities like those seen in the Log4Shell incident.

To prevent tampering, an SBOM must reference the immutable identity of each component via cryptographic hashes. This ensures the component analyzed is the exact one deployed.

• SHA-256/SHA-512: The preferred hashing algorithms to uniquely identify a file.
• Content-Addressable Storage: By referencing a component by its hash, any modification to the upstream library immediately invalidates the SBOM entry.
• Non-Repudiation: When combined with digital signatures, the hash provides proof that the listed artifact is the one the builder intended.

An SBOM must describe the origin of each component to distinguish a trusted internal build from a malicious public package. Key provenance data includes:

• Supplier: The entity that authored or distributed the component.
• Build Tools: The compiler, build script, and environment used to create the artifact.
• Source Repository: The exact commit hash from the version control system. This data enables the verification of SLSA (Supply Chain Levels for Software Artifacts) attestations, ensuring the binary matches the reviewed source code.

An SBOM is a static inventory; a VEX document provides the dynamic context needed to prioritize remediation. VEX answers the question: 'Is this specific vulnerability actually exploitable in my specific product?'

• Status Labels: Not Affected, Affected, Fixed, Under Investigation.
• Justification: Explains why a component is not exploitable (e.g., vulnerable code cannot be reached, runtime mitigations exist).
• Integration: VEX data is consumed by security scanners to suppress false positives, reducing alert fatigue for SecOps teams.

A critical function of an SBOM is the exhaustive listing of software licenses for all constituent components to prevent legal liability. This includes:

• SPDX License Identifiers: Standardized tags like MIT, GPL-3.0-only, or Apache-2.0.
• License Conjunctions: Handling complex dual-licensing or multi-licensing scenarios (MIT OR GPL-2.0-only).
• Copyleft Detection: Automated flagging of reciprocal licenses (e.g., GPL) that may impose obligations on the proprietary software that incorporates them.

An MBOM extends the SBOM concept specifically to machine learning models. It catalogs the full AI supply chain, including training datasets, preprocessing steps, model architecture, and framework dependencies. This transparency is critical for auditing model provenance and identifying vulnerabilities introduced through poisoned data or compromised base models.

A cryptographically signed statement asserting a verifiable fact about a software artifact. Common attestation types include:

• Provenance: Describes how and where an artifact was built
• Vulnerability Scan: Reports the results of a security scan at a specific point in time
• SBOM: Attests that a specific component inventory is accurate for a given artifact Attestations are the mechanism by which an SBOM becomes a verifiable claim rather than just a document.