Software Bill of Materials (SBOM)

An SBOM must be generated in a structured, standardized data format to enable automated ingestion and analysis by security tooling. The three primary formats are:

• SPDX (Software Package Data Exchange): An ISO/IEC 5962:2021 standard, ideal for communicating license and copyright information alongside component metadata.
• CycloneDX: A lightweight OWASP standard designed specifically for application security contexts, supporting hardware, software, and services BOMs.
• SWID (Software Identification Tags): An ISO/IEC 19770-2 standard using XML tags to identify software, often used for asset management.

A standalone SBOM is a static inventory; it does not state whether a component is vulnerable. A Vulnerability Exploitability eXchange (VEX) document complements an SBOM by providing a machine-readable security advisory. It allows a software supplier to declare the exploitability status of a specific CVE in a specific product, effectively filtering out false positives and reducing alert fatigue for downstream consumers.

The Software Package Data Exchange is an ISO/IEC 5962:2021 open standard for communicating SBOM information. It captures component details, copyrights, licenses, and security references in a machine-readable format. SPDX 3.0 introduced profiles for AI and datasets, making it the preferred standard for complex compliance use cases.

• Supports RDF, JSON, YAML, and tag-value formats
• Mandated by the U.S. Executive Order on Cybersecurity
• Includes fields for supplier, originator, and file-level analysis

A lightweight, OWASP-maintained Bill of Materials standard designed specifically for application security and supply chain component analysis. It supports multiple BOM types including SBOM, SaaSBOM, and OBOM (Operations BOM). CycloneDX excels in mapping complex dependency graphs and is natively integrated with many vulnerability scanners.

• JSON and XML serialization
• Built-in vulnerability disclosure (VDR) and VEX support
• Widely adopted in the Java and .NET ecosystems

A security advisory that allows a software supplier to declare the exploitability status of a specific CVE in a specific product. VEX eliminates false positives by stating whether a vulnerability is 'not affected', 'affected', or 'fixed'. When paired with an SBOM, VEX transforms raw vulnerability lists into actionable intelligence.

• Defined by the CSAF 2.0 standard
• Prevents alert fatigue in DevSecOps pipelines
• Enables automated triage of scanner results

A CNCF-graduated framework that cryptographically attests to the integrity of every step in a software supply chain. It creates a verifiable, end-to-end record of who performed what action and what materials were used. In-toto layouts define the expected steps, while link metadata captures the actual execution, enabling detection of tampering between the SBOM generation and artifact deployment.

• Integrates with TUF for key management
• Provides non-repudiation for build steps
• Essential for achieving SLSA Level 3+

An open-source project enabling keyless digital signing and verification of software artifacts. Cosign signs container images, blobs, and SBOM documents using short-lived certificates issued via OpenID Connect identities. This eliminates the operational burden of long-lived private key management. An SBOM signed with Cosign and logged in a transparency log provides cryptographic proof of origin.

• Fulcio (CA), Rekor (transparency log), and Cosign (client)
• Supports signing SBOMs as attached attestations
• Foundation for SLSA provenance attestations

An automated process for identifying and cataloging open-source components within a codebase. SCA tools generate SBOMs and cross-reference them against vulnerability databases like NVD and GitHub Advisory Database. Modern SCA goes beyond CVE matching to analyze reachability and exploitability, determining if a vulnerable function is actually called by the application.

• License compliance and risk scoring
• Transitive dependency resolution
• Policy enforcement via build-time gates