Wiki · Concept · Last reviewed June 25, 2026

System Package Data Exchange (SPDX)

SPDX is an open standard for exchanging bill-of-materials and supply-chain information about systems with software components, including profiles for software, security, licensing, datasets, builds, and AI systems.

Category: Concept Updated: June 25, 2026 Tags: AI security, SPDX, SBOM, AI-SBOM, licenses, supply chain, governance

Definition

SPDX is a Linux Foundation open standard for exchanging bill-of-materials information about systems with software components. The project now expands SPDX as System Package Data Exchange; older specifications, the ISO page, and many practitioners still use Software Package Data Exchange. SPDX began as a software package and license-compliance format, then expanded into a broader system evidence model.

ISO identifies ISO/IEC 5962:2021 as Information technology - SPDX Specification V2.2.1 and describes it as a standard data format for communicating component and metadata information associated with software packages. The SPDX project page describes the specification as a freely available international open standard, and SPDX 3.x materials extend the BOM idea across software, security, licensing, datasets, AI models, and build information.

How It Works

An SPDX document is structured evidence. It can describe packages, files, snippets, relationships, creation information, external references, hashes, license expressions, security information, and other metadata. SPDX 3.0.1 defines a data model based on RDF and allows serialization in JSON-LD, Turtle, N-Triples, RDF/XML, and canonical JSON. That structure lets tools exchange, validate, and join records instead of treating a BOM as a spreadsheet.

SPDX 3.0.1 uses profile compliance points. Core is mandatory for other profiles. Software covers artifacts. Security covers vulnerability severity and how a vulnerability may affect a specific software element. Licensing covers SPDX license expressions and the SPDX License List. Dataset covers dataset names, versions, sources, metadata, licensing, characteristics, and related attributes. Build covers inputs, outputs, procedures, environments, actors, and build evidence.

The AI profile is the Spiralist-relevant extension. The SPDX conformance text says the AI profile covers information about software components and dependencies associated with AI and ML models and systems. The SPDX AI overview frames an AI-SBOM as a machine-readable record that can include software dependencies, AI models, data assets, prompt templates, AI agents, licenses, compliance information, and ethical or security attributes. It gives institutions a shared place to record what they claim is in the system.

Agent Context

Agentic systems make SPDX more than a compliance artifact. A coding agent can add a package, update a lockfile, generate a Dockerfile, call a model API, copy a snippet, or install a tool without a human noticing every dependency edge. Later, the reviewer needs a machine-readable record of what changed, which licenses moved with it, and which vulnerability records apply.

SPDX can give that review a common data shape. Package URLs can identify packages. SPDX license identifiers can standardize license references. Security profile records can connect vulnerabilities, CVSS, EPSS, SSVC, and VEX-like status relationships to specific elements. AI and dataset profiles can name model and data artifacts when the system is more than ordinary application code.

Governance and Safety

A governance-grade SPDX workflow should store the SPDX version, profiles, generator tool and version, source artifact, generation time, package identities, hashes, license information, license-list version where relevant, vulnerability references, security assessments, and the approval decision made from the evidence. For AI systems, the same record should state whether models, datasets, prompt templates, agents, and model-serving infrastructure are in scope or omitted.

SPDX should not be treated as proof that a system is safe, licensed, or vulnerability-free. A generated record can be stale, too shallow, scoped to the wrong artifact, missing runtime services, or disconnected from deployment reality. It becomes useful when paired with OSV, CVE, VEX, SLSA Provenance, Sigstore, GUAC, and incident-response practice.

Defense Pattern

Source Discipline

Claims about SPDX should cite the specific artifact: the official project page, ISO/IEC 5962:2021, the SPDX 3.0.1 specification, a profile page, the conformance section, or the SPDX License List. ISO/IEC 5962:2021 refers to SPDX Specification V2.2.1, while the ISO page reviewed for this entry showed SPDX Specification V3.0 as a draft international standard under development.

The SPDX License List is related but distinct. Its page says the list is an integral part of the specification and provides standardized short identifiers, full names, license texts, and canonical URLs for licenses and exceptions. Those identifiers are useful in source files and BOMs, but they are not package identifiers or vulnerability identifiers.

Spiralist Reading

Spiralism reads SPDX as a discipline against solitary-machine mythology. A system is a lineage of packages, licenses, datasets, tools, build steps, vulnerabilities, and institutional decisions. Naming those inheritances does not redeem the machine. It makes accountability possible.

Open Questions

Sources

Return to Wiki