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 Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: 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 and supply-chain 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, while SPDX 3.x materials extend the BOM idea across software, security, licensing, datasets, AI models, and build information.

The practical point is interoperability. SPDX lets a producer or tool describe what is in an artifact, how elements relate, which licenses and identifiers apply, and which profile-specific evidence is present. It does not prove that the artifact is safe, complete, legally cleared, or fit for deployment.

Snapshot

Current Context

As of June 25, 2026, SPDX 3.x is the active community specification line, but the ISO status is still transitional. ISO lists ISO/IEC 5962:2021 as the published International Standard for SPDX V2.2.1 and says it is expected to be replaced by ISO/IEC DIS 5962, Information technology - SPDX Specification V3.0, within the coming months. Compliance records should therefore say exactly whether they rely on ISO/IEC 5962:2021, SPDX 3.0.1, or a draft/release-candidate SPDX version.

SPDX announced SPDX 3.1-RC1 for testing and validation on January 26, 2026. That release candidate expands the model beyond the existing 3.0.1 profile set, but the announcement warns that features can still be modified or reverted before the final stable release. This page therefore treats SPDX 3.0.1 as the stable 3.x reference and names 3.1 only as a release candidate.

For SBOM governance, SPDX also sits within the wider U.S. software-transparency baseline. NTIA's minimum-elements report defines baseline SBOM data fields such as supplier, component name, component version, other unique identifiers, dependency relationship, SBOM author, and timestamp. SPDX can carry much more than those minimum elements, but an SPDX file is only useful if it is generated at the right lifecycle point and tied to the artifact actually reviewed.

Boundary Tests

Not the same as an SBOM policy. SPDX is a format and data model for expressing BOM and related evidence. A policy still has to define when to generate it, what scope is required, who reviews it, and what happens on failure.

Not CycloneDX. CycloneDX is a different BOM standard with its own ECMA standardization path, capabilities, schemas, and tooling. Some organizations use both; they are not interchangeable without mapping rules.

Not Package URL. Package URL can appear inside SPDX as a package identifier, but PURL is an identity syntax, not a full BOM, license-expression model, vulnerability context, or profile system.

Not SLSA or in-toto provenance. SLSA Provenance and in-toto attest to build or supply-chain steps. SPDX Build can describe build evidence, but a BOM is not automatically a signed provenance attestation.

Not VEX or a vulnerability database. SPDX 3.0.1 has Security profile structures that can express vulnerability relationships and VEX-like status, but it does not replace CVE, OSV, exploitability analysis, or incident response.

Not an AI safety case. The AI profile can help document AI system and model artifacts. It does not prove that a model is safe, unbiased, lawful, aligned with policy, or suitable for high-impact use.

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. Conformance to one non-core profile does not imply support for all other profiles.

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.

AI supply-chain review should also separate public transparency from confidential evidence. A useful AI-SBOM may need to name models, datasets, prompt templates, tools, and risk attributes, but some details can reveal sensitive data, trade secrets, security posture, or attack paths. The governance question is not "publish everything"; it is which fields are public, which are shared under assurance agreements, and which are retained for regulator or incident review.

Failure Modes

Version ambiguity. A procurement or audit record says "SPDX compliant" without stating whether it means ISO/IEC 5962:2021, SPDX 2.3, SPDX 3.0.1, or an SPDX 3.1 release candidate.

Profile overclaim. A document conforms to Core and Software, but reviewers treat it as if it also included Security, Licensing, Dataset, AI, or Build profile evidence.

Wrong artifact scope. The SPDX record is generated from source code while the shipped container, hosted model endpoint, plugin bundle, or runtime image has different contents.

Identifier confusion. A package URL, SPDX license identifier, CPE name, component ID, hash, and vulnerability ID are treated as if they were the same kind of identifier.

License-expression shortcut. SPDX license expressions are treated as legal clearance even when source files, generated code, copied snippets, model licenses, data licenses, or attribution obligations were not reviewed.

Agent drift. A coding or operations agent changes dependencies, tools, containers, model routes, or prompt assets after the SPDX record was generated.

Redaction gap. Sensitive AI supply-chain information is either overpublished or fully omitted, leaving no controlled evidence path for auditors or incident responders.

Minimum Evidence Record

For consequential software or AI systems, an SPDX-backed governance record should preserve enough context to verify the file and understand its limits. At minimum, record:

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, the model and serializations section, a profile page, the conformance section, the SPDX License List, or the SPDX 3.1-RC1 announcement. 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.

When comparing SPDX with CycloneDX, SLSA, in-toto, SCITT, OSV, CVE, VEX, PURL, or model cards, name the question each artifact answers. SPDX can carry or reference many kinds of evidence, but it is still a BOM and supply-chain data model, not a substitute for provenance verification, vulnerability triage, legal review, or AI assurance.

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