SPDX

SPDX defines a canonical License List with standardized identifiers (e.g., MIT, Apache-2.0, GPL-3.0-only). This eliminates ambiguity in license declaration by replacing free-text descriptions with precise, machine-readable short-form IDs. Each identifier maps to a specific legal text, enabling automated license compliance checks across complex dependency graphs without manual legal review.

SPDX documents explicitly model the relationships between software components using a defined vocabulary. Key relationship types include:

• CONTAINS: A package contains a sub-package
• DEPENDS_ON: A package requires another to function
• DYNAMIC_LINK: Runtime linking to a shared library
• GENERATED_FROM: Source code that produced a binary This graph-based approach enables transitive vulnerability analysis and full supply chain transparency.

SPDX 2.2+ supports external security references, allowing an SBOM to directly link components to known vulnerabilities. An SPDX document can reference:

• CVE (Common Vulnerabilities and Exposures) identifiers
• GHSA (GitHub Security Advisories)
• VEX (Vulnerability Exploitability eXchange) statements This integration enables automated security scanning tools to correlate SBOM data with vulnerability databases, dramatically reducing the time to identify affected components during a zero-day event.

SPDX was formally adopted as an international standard by ISO/IEC JTC 1 in 2021. This standardization ensures:

• Interoperability: Tools from different vendors can consume and produce SPDX documents consistently
• Regulatory Acceptance: Governments and regulated industries can mandate SPDX as a compliance requirement
• Long-term Stability: The specification evolves through a formal, community-driven governance process under the Linux Foundation The standard supports multiple serialization formats including JSON, YAML, RDF/XML, and tag:value flat text.

SPDX defines a deterministic Package Verification Code algorithm for generating a checksum that uniquely identifies the contents of a software package. This code is computed by:

1. Sorting all file paths in the package alphabetically
2. Computing a SHA1 hash for each file
3. Concatenating all hashes and computing a final SHA1 This mechanism enables reproducible build verification and tamper detection, allowing downstream consumers to confirm that a received artifact matches the declared SBOM exactly.

SPDX is one of the three SBOM formats explicitly recognized by the U.S. National Telecommunications and Information Administration (NTIA) as meeting the minimum elements for an SBOM. These mandatory fields include:

• Supplier Name: The entity creating the component
• Component Name: The software name
• Version String: The specific version identifier
• Unique Identifier: A globally unique reference
• Dependency Relationship: Upstream and downstream linkages
• Author: The SBOM document creator
• Timestamp: When the SBOM was generated This alignment makes SPDX the preferred format for U.S. federal procurement compliance under Executive Order 14028.

A formal, machine-readable inventory that catalogs every component, library, and dependency within a software artifact. SPDX is the ISO/IEC 5962:2021 standard for representing an SBOM. An SBOM enables precise vulnerability management by mapping known CVEs to specific transitive dependencies, eliminating the guesswork from incident response. The U.S. Executive Order 14028 mandates SBOMs for federal software procurement.

A standardized security advisory that lets software suppliers declare the exploitability status of a specific CVE in a specific product. VEX eliminates the flood of false positives that occur when an SBOM flags a vulnerable component that isn't actually exploitable due to how it's used. Key statuses include:

• Not Affected — component present but vulnerability unreachable
• Affected — remediation required
• Fixed — patch applied
• Under Investigation — analysis ongoing

An automated process for identifying and cataloging open-source components within a codebase. SCA tools consume SPDX and CycloneDX SBOMs to cross-reference component inventories against vulnerability databases like NVD and GitHub Advisory Database. Modern SCA goes beyond CVE matching to analyze license compatibility, code quality metrics, and dependency freshness — providing a continuous compliance posture for the entire software portfolio.