Artifact Registry Immutability as a Chain of Custody Requirement

Artifact registries are no longer storage. A registry used to be a place where finished work landed after the real decisions had already been made. Now it sits in the middle of those decisions, resolved thousands of times a minute by systems that never pause to ask whether what they just pulled is what they think it is.

The scale involved is the thing to hold onto first. Sonatype's 2025 State of the Software Supply Chain report documents download activity across Maven Central, PyPI, npm, and NuGet at a level the report describes as critical internet infrastructure under sustained strain. That framing is not rhetorical. These four registries alone handle the dependency resolution for most of the world's software builds, and each resolution is an act of trust extended automatically, without a person in the loop to catch a mistake.

At that scale, a small gap in artifact integrity stops behaving like a marginal risk and starts behaving like a systemic one. When a pipeline forgets what it resolved in a prior run and re-resolves against a registry that has changed underneath it, the cost of that forgetting does not stay local. It propagates through every consumer downstream.

Attacker strategy has shifted to target the registry directly. The registry did not become infrastructure by accident. It became infrastructure because it is where trust gets manufactured at scale, and infrastructure of that kind draws exactly the kind of attention its criticality deserves.

How mutable registries turn supply-chain controls into theater

Mutability is the single mechanism that turns a well-instrumented supply chain into a fiction. If an artifact can change after it has been created and verified, then every consumer downstream, a human developer, a CI runner, an AI agent, is working from a premise that cannot actually be checked. The verification happened once, against one version of the artifact. Nothing guarantees the version served tomorrow is the same one.

The mechanism matters because it recurs across incidents regardless of the specifics of any single one: consider the shape of this failure in the abstract. An artifact gets built, scanned, and signed. It passes every check a pipeline has in place. Then, after that verification has already happened, something changes it: a compromised plugin portal, a poisoned cache, a registry that accepts a new upload under an old reference. The controls ran and passed. They ran. They passed. And the thing they certified is no longer the thing being served. A Gradle plugin compromise in the second quarter of 2026 followed exactly this pattern: a plugin widely used across Android and enterprise Java builds was modified at the portal level after it had already cleared verification, and downstream builds that trusted their own prior checks had no mechanism left to catch the change.

Version tags make this worse, not better. A version tag is a label, not a guarantee. A digest describes what something is. A version tag only describes what someone decided to call it, and names can be reassigned in ways that contents cannot.

The natural objection is that signing already solves this: if artifacts are signed, any mutation should be detectable. But signing proves who published something and when they published it. Signing answers one question. Mutability raises an entirely different one, and no amount of signing closes that gap on its own.

Signing and SBOMs without an immutable artifact

Signing and software bills of materials are necessary. Both are necessary, but they depend structurally on registry integrity, a dependency easy to overlook until something breaks. Both describe and attest to an artifact, but the registry is what has to hold that artifact constant over time. If it doesn't, the attestation and the thing it was meant to describe quietly come apart, and nothing in the signing or SBOM process is built to notice.

Take a standard CI pipeline using Sigstore and Cosign for signing. But it does not record which registry eventually distributed that artifact, and it cannot confirm that the artifact sitting at a given registry reference today is still the one that was signed at that earlier moment. The entire distribution path, everything that happens between signing and consumption, is invisible to the signing record. The log can tell you about the past. It cannot tell you what's currently being served.

SBOMs carry the same structural weakness. An SBOM is only as trustworthy as the artifact it describes, and if a registry allows an artifact to be silently replaced, the SBOM and the thing actually deployed can diverge with no audit trail anywhere that captures the gap. Research surveying 47 delivery platforms, 20 CI/CD platforms and 27 model-serving and agent platforms, found exactly this kind of hole: of fifteen repositories chosen specifically because they had adopted attestation tooling, seven published source-only releases. That means the binding those workflows claim to establish cannot actually be checked on the surface where the claim is made. The declaration lives in one place. The evidence that would let someone verify it lives somewhere else, and nothing connects the two.

The standard response to all of this is a full attestation pipeline: SLSA provenance and a CycloneDX SBOM, both signed with Cosign in keyless mode, the signing event logged to Rekor with an inclusion proof, and a policy controller at deploy time checking that signature and provenance against the expected OIDC issuer before anything is allowed to run. But it is only sound on the condition that the OCI registry holding the signed image, its signature, its provenance, and its SBOM attestation cannot itself be altered. Signing and SBOMs are controls that assume the registry beneath them holds the artifact constant. When that assumption fails, the controls remain technically present and functionally meaningless.

How regulatory requirements operationalize the chain-of-custody record

What has so far been an engineering argument is becoming a legal one. The EU Cyber Resilience Act turns what used to be a best-practice recommendation into a verifiable obligation: organizations have to be able to demonstrate supply chain integrity, not simply assert that it exists. That distinction, between demonstrating and asserting, carries the regulation's full force, and it maps directly onto the risk that an artifact can change after it has been verified.

The timeline is not abstract. The CRA entered into force on 10 December 2024. For many organizations building or shipping software that touches the EU market, this is a compliance deadline already on the calendar, not a hypothetical future requirement to think about later.

What "demonstrating integrity" means in practice is specific. The SBOM generated for an artifact has to be the same SBOM referenced by the vulnerability scan performed against it, and that scan result has to trace back to the exact dependency list that produced that specific version of the artifact, not a generic scan run against "latest" and disconnected from whatever is actually deployed in production. This is a traceability requirement, and it is also, quietly, an immutability requirement. The chain collapses the moment a registry allows an artifact to change after its SBOM was generated, because at that point there is no longer one artifact with one history. There are two artifacts sharing one name, and the paperwork only describes one of them.

The audit logs, role-based access control, and lifecycle records that a well-run registry produces are themselves chain-of-custody documents, and they only mean something if the artifact they describe could not have been silently swapped out from under them. An audit log that records a governance decision against an artifact that may no longer exist in the form that was reviewed is a historical note about something that used to be true, not an audit trail. Sonatype's report states this directly: the regulatory and commercial direction is toward demanding evidence produced by the build process itself, not assurances assembled after the fact to satisfy a checklist.

Registries enforcing immutability as first-class policy

The registry is starting to behave less like a warehouse and more like a checkpoint, enforcing policy at the moment an artifact arrives rather than leaving integrity checks to whatever happens downstream.

Harness made its Artifact Registry generally available in February 2026, after an 18-month public beta, with supply chain security positioned as a central part of the release. Artifacts that fail these checks can be quarantined until they meet policy. Harness has said it continues to expand the registry's capabilities, including stronger support for immutability, auditing, and AI automation across the platform. Drax Group, a UK-based renewable energy company that had already begun consolidating its software delivery tooling on Harness, was among the early customers to bring multiple container and package types into the new registry module, reaching full adoption across its teams.

KitOps, a CNCF Sandbox project, takes a different but related approach, aimed specifically at AI and machine learning artifacts. It packages models as OCI artifacts called ModelKits, which can bundle agent skills, prompts, MCP server definitions, and code into a single versioned, immutable OCI artifact. A tag like :v2.1 or :champion applies to the entire bundle at once, not to scattered pieces of it that might drift independently, which enforces atomic versioning at the level of the whole artifact rather than at the level of its individual components.

What connects these two implementations, despite their different scopes, is the same architectural principle: governance happens when the artifact enters the registry, not when something later decides to pull it. That is a meaningful inversion of how registries have traditionally worked, and it is the direction the rest of the industry appears to be following.

AI agents as supply-chain actors and the urgency of immutability

AI agents that resolve and consume artifacts on their own introduce a new category of chain-of-custody risk, because an agent acts on whatever the registry hands it, at a speed and volume that leaves no room for a person to step in and check. A human developer might notice something was off about a dependency update. An agent resolving thousands of such decisions per hour will not.

Research on accountability structures in agentic software engineering, surveying the same 47 delivery platforms referenced earlier, found that no platform's default record expresses a content-addressed identity for the full behavioral tuple an agent actually runs at deployment, meaning its model version, its instructions, its tool definitions, its retrieval and runtime configuration, considered together as one bound object. The gap between what a pipeline declares it deployed and what is verifiably running is structural, built into how these platforms currently version things.

A second problem compounds this from the opposite direction. AI-driven dependency resolution can therefore introduce artifacts into a pipeline that were never meaningfully vetted, and a mutable registry will serve them up without any resistance, because nothing in a mutable system is built to challenge a request just because the thing being requested is suspicious.

Some corners of the registry ecosystem are already responding. Apicurio Registry's evolution into an AI-native platform in February 2026 treats AI-specific artifacts, Agent Cards, prompts, model schemas, as first-class citizens in the registry alongside traditional schema types, and introduces a built-in MCP server to support agent-based access directly. The tooling to prevent the agent layer from repeating the registry layer's old mistakes already exists. Whether it gets adopted before the mistakes repeat at scale is the open question.

An immutability-grounded chain of custody end to end, including the environment layer

A real chain of custody needs content-addressed identity at every layer where an artifact gets defined, stored, promoted, or run, and the registry is the load-bearing layer in that chain, but it is not the only one.

The attestation pipeline is the anchor point: a source commit triggers a CI build, which produces an artifact along with SLSA provenance and a CycloneDX SBOM. Both get signed with Cosign in keyless mode and logged to Rekor with an inclusion proof. Layered on top of that, the SBOM generated for the artifact has to be the exact SBOM a vulnerability scan references, so that a CVE finding traces back to the precise dependency list that produced that specific artifact version. None of this holds if the registry can silently serve a different artifact under the same reference somewhere along the way.

But registry immutability alone does not eliminate environment drift, and that risk persists even in systems that have gotten everything above exactly right. Declarative, version-controlled environment definitions, where the entire toolchain is expressed as a manifest with pinned references rather than assumed to be whatever happens to be installed, extend the same content-addressed logic from the registry down to the developer's laptop and the CI runner. That closes the gap between what the registry holds and what actually ran.

One objection to all of this deserves a direct answer. Registry-centric immutability concentrates trust at a single perimeter, and an attacker who compromises that perimeter from above has not been stopped by any of the controls described here. Hardening a registry does not, by itself, make trust portable across mirrors, proxies, content delivery networks, or air-gapped transfers, where the same artifact may pass through several hands before it reaches its final consumer. Signing is what makes trust portable across those hops. Immutability makes the registry's own record of custody honest. Neither one substitutes for the other. A team that locks down its private registry perfectly but pulls from an upstream proxy without re-verifying at the point of pull has protected exactly nothing. The complete architecture needs both pieces working together, registry immutability as the foundation and portable, verifiable signing as the mechanism that carries trust across every hop beyond it.