Wiki · Concept · Last reviewed June 25, 2026

Package URL (PURL)

Package URL (PURL) is a compact identifier syntax for naming software packages across ecosystems, package managers, SBOMs, vulnerability data, and AI supply-chain records.

Category: Concept Updated: June 25, 2026 Tags: AI security, supply chain, PURL, SBOM, package identity, governance

Definition

Package URL, usually written PURL or purl, is a standard syntax for identifying software packages independently from their package manager, ecosystem, or distribution channel. Ecma International published the first edition as ECMA-427 in December 2025. The standard frames a PURL as a valid URL and URI made from seven components, with the package type defining ecosystem-specific meaning.

The problem PURL addresses is ordinary but consequential: package names are not globally unique. A name that is meaningful in npm may be unrelated to a similar name in PyPI, Maven, NuGet, RubyGems, a Linux distribution, or a container registry. SBOMs, vulnerability databases, advisories, exploitability reports, and dependency-management tools need a shared way to say which package they mean.

For AI systems, PURL is useful because agent frameworks, model-serving stacks, evaluation harnesses, plugins, container images, and build tools all depend on ordinary software packages. A model card may describe behavior, but a deployment record also needs precise identifiers for the packages that load, transform, serve, observe, and secure the model.

How It Works

A PURL has the general form pkg:type/namespace/name@version?qualifiers#subpath. The scheme is pkg. The package type names an ecosystem such as npm, pypi, maven, nuget, or gem. Namespace, name, version, qualifiers, and subpath add progressively more detail, depending on what that package ecosystem supports.

The official project documentation emphasizes normalization. Building a PURL is not just string concatenation: names, namespaces, versions, qualifiers, and subpaths may need type-specific normalization, UTF-8 handling, percent encoding, qualifier sorting, and removal of empty or unsafe path segments. This is why PURL generation should come from maintained libraries or well-tested SBOM tooling rather than improvised templates.

PURL is an identifier, not a safety proof. A PURL can name a package precisely without proving that the package is authentic, reachable, patched, licensed, or appropriate. It should therefore be paired with artifact digests, provenance, signatures, vulnerability status, policy decisions, and deployment context.

Agent Context

Coding agents and operational agents can add dependencies, install tools, edit lockfiles, build images, and select libraries from package registries. Human review often sees the diff, while later security review sees logs, SBOMs, alerts, and incident tickets. PURL gives those records a common package key.

That matters when evidence is joined across systems. A dependency selected by an agent can appear in a lockfile, SBOM, SCA report, vulnerability advisory, VEX statement, provenance record, and GUAC graph. If each system names the package differently, reviewers spend time reconciling identity instead of asking whether the package should be trusted.

PURL does not prevent dependency confusion, typosquatting, malicious maintainers, compromised registries, or prompt-driven tool misuse. It makes the package object legible enough that controls can attach to the same thing: allowlists, deny lists, signer requirements, sandbox policies, exception reviews, and incident searches.

Governance and Safety

A governance-grade package record should include the PURL, resolved version, artifact digest, registry or source location, lockfile entry, installer or build step, time of resolution, signer or attestation evidence, vulnerability-status decision, license review, exception rationale, and approving owner. In an AI Bill of Materials, that record should connect packages to model-serving code, plugins, datasets where relevant, evaluation tooling, and runtime containers.

The main governance failure is treating PURL as a magic label. A precise identifier can still point to a risky package, an unreviewed package, or a package whose vulnerability is irrelevant in one product but exploitable in another. PURL improves matching; it does not replace exploitability analysis, secure build policy, release approval, or incident response.

PURL belongs beside SLSA Provenance, Sigstore, The Update Framework, in-toto, GUAC, SBOMs, VEX, repository scoring, and sandboxed execution. It names the package so those other controls can reason about the same object.

Defense Pattern

Source Discipline

Claims about PURL should cite ECMA-427, the package-url project documentation, or the package-url specification repository. The older top-level PURL-SPECIFICATION.rst file now points readers to the project documentation and ECMA-427, so page citations should follow that move rather than relying on stale copies.

A source note should distinguish PURL from adjacent identifiers. It is not a CPE name, an SPDX license identifier, a registry download URL, a cryptographic digest, or an SBOM component ID, although it can appear alongside all of them. When making a package claim, record the PURL, generation tool, source document, date reviewed, and any normalization assumptions.

Spiralist Reading

Spiralism reads PURL as a small ritual of exact naming. Modern software arrives as a cloud of names: marketing names, repository names, import names, file names, image tags, vulnerability names, and dashboard names. Confusion at this layer is not cosmetic. It is how responsibility is misfiled.

PURL does not bless a package. It refuses to let the package drift as a vague object. The useful discipline is to name the dependency clearly enough that praise, blame, repair, and refusal can attach to the same thing.

Open Questions

Sources

Return to Wiki