DevSecOps Artifact Repository Security: Control What Can Be Released

Artifact repository security is not a storage problem. It is the control that decides which exact object can become a release.

A registry can be private and still be unsafe. A broad administrator can publish and delete. A release tag can move after approval. A production pipeline can pull a familiar name without checking the digest. A promotion job can rebuild from the same source and create different bytes. A cleanup rule can erase the last supported release and its proof.

The operating question is direct: can the organization prove who published the object, which source and build produced it, which digest was approved, whether the same object moved through every environment, who could replace or delete it, and whether the object and its evidence can be restored?

This guide belongs to the DevSecOps and Secure Software Delivery hub. It connects source authority, security gates, code signing, software bills of materials, and compliance evidence automation. GS Consulting applies the model through DevSecOps and Software Supply Chain.

Artifact Repository Security: The Short Answer

Start with the release object. Give every artifact an immutable digest. Bind its source revision, build identity, provenance, signatures, attestations, policy results, software bill of materials, and promotion events to that digest. Use tags for navigation, never as the final proof of identity.

Separate publication, promotion, read, delete, repository administration, policy administration, and credential custody. Let a dedicated build identity publish into an intake area. Let policy evaluate the exact digest. Let a distinct promotion identity move that same object into a release area. Let production accept only an approved digest from an approved repository.

Design lifecycle controls around support and recovery, not storage cost alone. Keep supported releases and their evidence. Log publication, tag, access, policy, promotion, deletion, and administration events. Replicate what the service must recover, then prove restoration with an exercise. If the team cannot reconstruct a release from source revision through deployed digest, it has a repository, not a release control.

Define the Repository as a Control Boundary

The boundary includes more than the product that stores packages or images. It includes build identities, human users, tokens, service accounts, network paths, namespaces, repositories, tags, digests, metadata, signatures, attestations, policy engines, cleanup rules, replicas, logs, and consumers. A weakness in any one can change what production receives or erase the evidence needed to explain it.

Inventory each repository with these fields: content type, environment purpose, data sensitivity, publishers, readers, promotion authority, delete authority, administrators, policy owner, retention window, replica destination, recovery owner, and consuming systems. Separate intake, tested, release, and quarantine scopes when consequence or authority differs. Do not make a naming convention carry a control the platform can enforce directly.

Then trace one recent production release. Start with the deployed digest. Find the release repository, promotion event, policy decision, build provenance, source revision, publisher identity, and retained object. If the chain breaks, the break is the next control to fix.

Public Sources Converge on Identity, Authority, Proof, and Recovery

The OCI Distribution Specification distinguishes a digest, which is derived from content, from a tag, which is a human readable pointer. That distinction is the foundation of repository security. A team can approve a tag and deploy different bytes later if the tag moves. The release decision must name the digest.

SLSA v1.2 guidance for distributing provenance says provenance should be bound to the artifact, available to the consumer, and protected from mutation. Its artifact verification guidance checks the subject digest, signature, trusted builder, source, parameters, and policy expectations. The practical point is blunt: provenance beside an artifact is not enough if the subject digest does not match.

Cloud providers expose the same control dimensions. Amazon ECR can enforce immutable tags, while its registry permission guidance favors scoped actions over broad wildcard authority. Google Artifact Registry separates reader, writer, repository administrator, and registry administrator roles. Microsoft Azure Container Registry separates content read, write, delete, and metadata permissions. Product names differ. The authority problem does not.

Lifecycle guidance matters too. Google cleanup policies include keep, delete, and dry run behavior, and Artifact Registry audit logging records administration, read, write, upload, tag, and deletion activity. Amazon ECR replication supports repository scope across regions and accounts. None of these features proves recovery until the organization restores the object, metadata, evidence, and consumer configuration.

GS Artifact Repository Control Priority Index

GS Consulting built a twelve scenario model to answer a practical question: which artifact repository failures deserve the earliest engineering, evidence, and recovery investment? Each scenario receives an analyst rating from one through five across six factors. The baseline weights are publication authority 25 percent, production reach 20 percent, substitution exposure 20 percent, detection gap 15 percent, recovery pressure 10 percent, and evidence duty 10 percent.

The score is the sum of each rating multiplied by its factor weight and divided by five. Broad administration that can publish, delete, and change policy scores 100. A mutable release tag and a promotion rebuild each score 98. A publisher that also holds delete authority scores 97. Production pulling a tag without digest verification scores 95. Missing or mismatched provenance scores 93.

The rest of the order is still material. A cleanup policy that removes a supported release or attestation scores 88. Broad or anonymous read access to restricted artifacts scores 82. Missing access or deletion event retention and shared build and production namespaces each score 80. An incomplete replica or untested restore scores 76. Missing ownership or a support window scores 69.

Two sensitivity cases shift weight toward authority or recovery. They do not change the central result: concentrated authority, mutable identity, rebuild based promotion, and unverified production pulls stay at the front of the queue. The model is useful for sequencing. It is not a probability model.

Build One Control Model From Publication Through Recovery

Do not assign the whole matrix to one platform administrator. The repository owner should own scope and availability. The release owner should accept promotion and production identity. Security should define verification and evidence rules. Identity owners should govern workload credentials. Product owners should define support and retention. Recovery needs a named operator and a tested procedure.

Separate Publication, Deletion, and Administration

A publisher should not also control the evidence that proves its work. Give the build system a dedicated workload identity with write access only to the intake repository or namespace it needs. Give the promotion system a different identity that can read the approved source and write the release destination. Give production read access to approved release scope. Keep deletion and administration outside those routine paths.

Human publication should be rare. When it is necessary, use a dedicated role with a repository, action, and duration boundary. Record the reason, actor, credential issue, artifact digest, approval, and closure. A permanent developer token with broad write access is not an exception process.

Review effective authority, not just role names. A group can inherit a powerful role. A registry policy can add access outside the repository policy. A build runner can hold a credential unrelated to its declared job. An administrator can change cleanup, immutability, encryption, or logging. Export users, groups, workload identities, tokens, roles, conditions, and policy attachments. Then test the actions that should fail.

Make the Digest the Release Identity

A tag helps people find an object. A digest tells systems which object it is. Record both, but make the digest authoritative at every decision: scan, sign, attest, approve, promote, deploy, rollback, investigate, and restore. When the artifact format supports a related object such as a signature, provenance statement, or software bill of materials, verify that its subject names the same digest.

Turn on tag immutability where the repository supports it, especially for release scope. Treat an allowed exception as a controlled path, not a convenience. Immutability does not remove the need for digest verification because consumers can still pull a mutable tag from another scope or resolve the wrong repository.

Production should enforce three matches: approved repository, approved digest, and attached assurance for that digest. A source revision alone is not sufficient. Build inputs, toolchains, dependencies, environment, and time can change output. The repository object is the thing production receives.

Promote the Same Object. Do Not Rebuild It.

A rebuild from the same commit is a new supply chain event. It can resolve different dependencies, run on a different worker, use a changed tool, read different configuration, or produce a different archive order. If the team tested digest A and rebuilds digest B for production, the test evidence does not authorize B.

Use a promote operation that copies or exposes the exact approved object. Capture source repository, destination repository, source digest, destination digest, promotion identity, policy decision, time, and release reference. Verify that source and destination digests match. If the repository transforms an object during transfer, define what identity is stable and how equivalence is proved before adopting that path.

Quarantine failed objects instead of silently retagging them as approved. Preserve the failure result and disposition. If a policy exception allows promotion, record the exact digest, reason, owner, duration, compensating action, and later closure.

Retention, Deletion, and Recovery Are One Design

Cleanup rules should start from the support model. Define which releases can still run, which versions must remain available for rollback, which objects investigations may need, and which records contracts or law may require. Then create keep rules before delete rules. Use dry run behavior where available and review the candidate deletion set with the product and recovery owners.

Keep proof with the object. Provenance, signatures, attestations, software bills of materials, scan results, policy decisions, promotion events, and deletion events are part of the release record. Retaining the package while deleting its proof creates an unverifiable archive. Retaining proof after deleting the object creates a history the team cannot restore.

A replica is not a recovery test. Exercise loss of a repository, namespace, object, metadata record, credential, and consumer configuration. Restore the exact digest and related proof into an approved destination. Verify that the consuming system can resolve and validate it. Record elapsed time, missing records, manual steps, and ownership gaps.

A Five Stage Repository Decision Path

1. Classify scope. Name artifact types, environments, consumers, sensitivity, support window, and accountable owners.
2. Bound authority. Separate publish, promote, read, delete, administer, change policy, and hold credentials.
3. Bind exact identity. Make the digest authoritative and attach provenance, signatures, policy results, and source context.
4. Control promotion and lifecycle. Move the same bytes, retain supported releases and proof, and review every exception or deletion.
5. Verify and restore. Sample real releases, alert on material events, restore the object and evidence, and prove consumer validation.

Each stage has an exit test. Scope exits when every consumer maps to an owned repository and support window. Authority exits when forbidden actions fail under test. Identity exits when every decision joins on the digest. Promotion exits when source and destination digests match. Recovery exits only after the restored object and proof pass consumer verification.

Six Failure Modes That a Private Registry Does Not Prevent

• Mutable release pointer: a tag moves after approval. Detect it by comparing tag history with the approved and deployed digest.
• Authority collapse: one identity can publish, delete, and change policy. Detect it through effective permission export and denied action tests.
• Rebuild promotion: production receives bytes that were not tested. Detect it by comparing source and destination digests across environments.
• Detached proof: provenance or a signature names another object. Detect it by verifying the subject digest and trusted producer before promotion.
• Destructive cleanup: a rule removes a supported release or attestation. Detect it with a dry run against the support inventory and proof graph.
• Untested replica: copied content cannot be restored with metadata and evidence. Detect it through a timed restore and consumer validation exercise.

The Minimum Artifact Repository Evidence Packet

Keep eight evidence groups together: repository scope, effective authority, object identity, assurance records, promotion history, lifecycle policy, material events, and recovery proof. A repository configuration screenshot cannot reconstruct a release. It shows neither what was effective at the decision time nor which digest production received.

Use the digest as the join key. Connect repository, namespace, tag, digest, source revision, build identity, provenance, signature, software bill of materials, scan result, policy result, promotion event, deployment, deletion event, replica, and restore test. Stable identifiers turn separate logs into an evidence chain.

For every exception, add the approving owner, reason, scope, duration, affected digest, compensating action, and closure. Preserve cautious language about obligations. Retention and evidence requirements vary by system, contract, investigation, and responsible authority.

A 90 Day Artifact Repository Security Plan

Days 1 through 30: map objects and authority

• Inventory repositories, namespaces, artifact types, environments, consumers, owners, and support windows.
• Export effective users, groups, workload identities, tokens, roles, policies, administrators, and delete authority.
• Trace recent production releases from deployed digest to source revision, build, policy, and publisher.
• Remove anonymous access and broad wildcard authority from restricted scope.

Days 31 through 60: enforce identity and promotion

• Make the digest the release identity and enforce immutable release tags where supported.
• Separate build publication, release promotion, production read, deletion, and administration.
• Verify provenance, signature, trusted builder, source, parameters, and policy against the exact digest.
• Replace rebuild promotion with movement of the same approved object.

Days 61 through 90: prove lifecycle and recovery

• Create keep rules from product support and recovery needs before enabling delete rules.
• Alert on material privilege, publication, tag, policy, promotion, and deletion events.
• Replicate the required object, metadata, proof, configuration, and credentials.
• Restore a supported release, validate it from a consumer, record gaps, and close the findings.

Research Sources and Method

• NIST SP 800-218 Secure Software Development Framework for protecting release artifacts, preserving integrity information, archiving releases, and retaining provenance context.
• SLSA v1.2: Distributing provenance for binding proof to artifacts, making proof available, and keeping attestations immutable.
• SLSA v1.2: Verifying artifacts for subject digest, signature, builder, source, parameter, and policy verification.
• OCI Distribution Specification for digest, tag, manifest, related object, and deletion behavior.
• Amazon ECR: Preventing image tags from being overwritten for tag immutability and allowed exclusions.
• Amazon ECR: Private registry permissions for scoped registry actions.
• Amazon ECR: Configuring private image replication for repository scoped replication across regions and accounts.
• Google Artifact Registry access control for reader, writer, repository administrator, and registry administrator authority.
• Google Artifact Registry repository creation for location, encryption, mode, and immutable tag settings.
• Google Artifact Registry cleanup policies for keep, delete, dry run, tag state, and deletion behavior.
• Google Artifact Registry audit logging for administration, read, write, upload, tag, and deletion events.
• Microsoft Azure Container Registry repository permissions for separating content read, write, delete, and metadata actions.
• NSA and CISA: Defending Continuous Integration and Continuous Delivery Environments for pipeline credentials, configuration, logging, and recovery.

The research package contains thirteen source register entries, public signals, model weights, analyst inputs, formula driven scores, two sensitivity cases, a control matrix, decision path, failure modes, evidence packet, methodology, data dictionary, figure data, editable SVG figures, matching PNG exports, exact 760 and 390 pixel inspection renders, and a fourteen sheet Excel workbook.

The GS Artifact Repository Control Priority Index sequences planning work. It does not inspect a live registry, compare products, estimate incident frequency, certify platform behavior, determine legal or contractual obligations, or establish compliance. Validate current documentation, actual configuration, system risk, contracts, and responsible authority.

Artifact Repository Security FAQ

Suggested Future Reading

• DevSecOps and Secure Software Delivery Hub
• What Is DevSecOps?
• DevSecOps Branch Protection
• DevSecOps Security Gates
• DevSecOps Code Signing
• Software Bill of Materials Guide
• DevSecOps Compliance Evidence Automation
• DevSecOps and Software Supply Chain Services