Security Requirements for Selecting an Artifact and Container Registry: criteria, vendor questions and tests

Every container your clusters run and every package your builds pull passes through a registry, so a registry chosen without security requirements becomes the easiest place to swap trusted software for malicious software. This vendor-neutral guide sets out what to require when selecting an artifact repository or container registry: cloud-provider registries, standalone SaaS registries, self-hosted universal artifact managers and pull-through caches for public ecosystems. It covers authentication for people and machines, immutability, signing and attestation support, scanning and policy gates, upstream proxying, audit and the platform's own security. It is for platform, DevOps and application security teams writing an RFP or comparing options. Day-to-day hardening of a registry you already run is covered in the Container Registry Security Guide.

Key takeaways

• Write access is the crown jewel. NIST SP 800-190 asks for authentication on all write access and on sensitive images, with developers able to push only to repositories they own. Score vendors on how narrowly they can scope push rights for pipelines.
• Digests and immutable tags beat mutable names. Require tag immutability, digest references and controlled deletion so that what you scanned and signed is what runs.
• Supply chain metadata must live next to the artefact. Support for the OCI 1.1 referrers API lets signatures, SBOMs and provenance attach to an image and be discovered by verifiers.
• Machine credentials decide your blast radius. Prefer short-lived, federated credentials for CI and clusters over long-lived robot passwords and tokens.
• Upstream proxying is a security control. A pull-through cache with allow lists, quarantine and malware checks is where you stop poisoned public packages entering the build.

Define requirements

• Artefact formats: OCI images and artefacts, Helm charts, and language packages (Maven, npm, PyPI, NuGet, Go modules and others). A universal manager covers many formats in one policy model; a cloud registry is often OCI only.
• Consumers: Kubernetes clusters and container runtimes, CI pipelines, developer workstations, serverless platforms, air-gapped or edge sites. Each needs a pull credential and a network path.
• Publishers: which pipelines may push, whether humans ever push directly (they should not to production repositories), and whether you publish to customers or the public.
• Deployment model: cloud-provider registry (native IAM, regional, little to run), third-party SaaS (multi-cloud reach), or self-hosted (full control and air-gap support, but you own patching, storage, backups and the server's own secrets).
• Assurance target: SLSA build provenance levels you need to verify, NIST SP 800-53 CM-14 (Signed Components) and SR-4 (Provenance), and contractual evidence for customers that receive your software.

Capability areas

Authentication and authorisation

• Federated human access: SSO for the web console and CLI login, with MFA and automatic deprovisioning. NIST SP 800-190 section 4.2.3 recommends federating registry accounts with the existing directory.
• Workload identity for machines: CI jobs and clusters authenticate with OIDC federation or cloud IAM roles and get short-lived tokens, rather than static robot passwords stored as pull secrets. The OpenSSF Principles for Package Repository Security place short-lived OIDC trusted publishing at Level 3.
• Fine-grained permissions: separate pull, push, delete, overwrite and administer rights per repository or path, so a build for one service cannot overwrite another service's images.
• Anonymous access off by default: public pulls only for repositories explicitly marked public, with an alert when visibility changes.

Integrity: tags, digests and deletion

• Tag immutability: per repository or by tag pattern, so release tags cannot be repointed. NIST SP 800-190 section 4.2.2 advises immutable, version-specific names rather than relying on "latest".
• Digest support: content addressing per the OCI Distribution Specification, so consumers can pull by digest and verify that content matches.
• Controlled deletion: the specification lets a registry disable deletion. Require delete rights separate from push, retention locks for released artefacts and audit of every delete.
• Retention and pruning: policy-driven pruning of stale and vulnerable images by age and label (SP 800-190 section 4.2.2) that never removes an image still running in production.

Signing, attestations and the referrers API

• OCI 1.1 referrers: support for GET /v2/<name>/referrers/<digest> and the manifest subject field, so signatures, SBOMs, vulnerability reports and SLSA provenance attach to an image and travel with it. Registries without it force clients onto the fallback tag schema, which is slower and easier to clutter.
• Signature formats: store and serve Sigstore and Notary Project signatures without stripping them on replication or promotion. Keyless Sigstore verification checks the signer's certificate identity and OIDC issuer against a transparency log. See the Sigstore Guide.
• Promotion that preserves metadata: copying an image between development, staging and production repositories must carry its referrers, or verification at deploy time fails.

Scanning and policy gates

• Vulnerability scanning on push and continuously: rescans when new CVEs are published, with results available through an API and as attached reports.
• Quality gates: SP 800-190 section 4.1.1 recommends policy-driven gates that stop non-compliant images moving forward. Ask whether the registry can block pulls of images that fail policy, or whether that must happen at cluster admission. See the Kubernetes Admission Control Guide.
• Secret and malware detection: scanning layers for embedded credentials and known malware. Public images carrying live secrets are common; see the 2025 study of 10,456 public images that exposed keys.

Upstream proxying and public ecosystems

• Pull-through caches: one controlled path to public registries and package indexes, with allow and block lists by package, namespace and version.
• Quarantine and cooldown: hold new upstream versions until scanned, and block packages reported as malicious. Worm-style package compromises such as the Shai-Hulud npm campaign spread through automatic version upgrades.
• Dependency confusion protection: internal namespaces resolved only from internal repositories, never from the public index.
• Credential boundaries: the OCI specification says credentials for an upstream registry should not be sent to a proxy unless the owner configures it, and clients must not forward authorisation headers across hosts. Ask how the proxy stores and uses upstream credentials.

Transport, network and data protection

• TLS only: SP 800-190 section 4.2.1 says tools, orchestrators and runtimes should connect to registries only over encrypted channels.
• Private connectivity: private endpoints or allow lists so production pulls never cross the public internet.
• Encryption at rest: with customer-managed keys where images contain proprietary code or regulated data.

Audit, resilience and exit

• Audit log scope: logins, token creation, push, pull, delete, tag changes, permission and policy changes, replication and proxy configuration. SP 800-190 asks for audit of reads and writes of sensitive images.
• Replication and availability: geo-replication, rate limits that will not starve clusters during a scale-out, and behaviour when the registry is down.
• Export: bulk export of artefacts with their referrers and metadata, so migration does not strip signatures. See the Artefact and container registry migration playbook.

Evaluation criteria

A small team on one cloud usually gets the most security per effort from the provider's native registry with federated IAM, tag immutability and an admission check for signatures. Multi-cloud estates, software publishers and organisations with heavy open source consumption gain more from a universal artefact manager that applies one policy model to every format, at the cost of running or paying for another platform.

Questions to ask vendors

• How does a CI job and a Kubernetes node each authenticate without a stored long-lived secret, and how short are the resulting tokens?
• Can push rights be limited to one repository or path per pipeline identity, and can overwrite and delete be granted separately from push?
• Do you implement the OCI Distribution Specification 1.1 referrers API, and are referrers preserved on replication, promotion, proxying and export?
• Which signature and attestation formats can you store and verify, and can policy block pulls of unsigned images?
• How do you rescan stored artefacts when new vulnerabilities are published, and how do results reach us?
• How does your proxy decide whether a new upstream package version is allowed, and how quickly do you act on a published malicious package report?
• Which audit events are logged for pull, push, delete and permission changes, and can we stream them?
• For SaaS: how are tenants isolated, and how would you tell us if your own systems or the tokens stored in them were exposed?
• For self-hosted: which secrets does the server hold (database, object storage, upstream credentials) and how are they protected and rotated?

Red flags

• Only long-lived username and password robot accounts for automation, with no expiry or scope beyond the whole registry.
• Mutable tags with no immutability option, or deletion rights bundled into push.
• Signatures and SBOMs dropped when an image is copied or replicated.
• Public or anonymous pulls enabled by default on new repositories.
• No audit of pulls at all, which leaves you unable to tell who downloaded a leaked or poisoned artefact.
• A proxy that pulls any upstream version on demand with no allow list, quarantine or malicious package feed.

Where identity fits

Registry credentials are non-human identities with outsized reach: a single repository key can expose everything a business ships. The SAP artefact repository key exposure involved a key with access to 95 million artefacts, and the 2019 Docker Hub breach exposed linked source control tokens for 190,000 accounts. Require an API that lists every robot account, token and federated trust with owner, scope and last use, and feed it into your NHI inventory. See the CI/CD Pipeline Identity Security Guide for federating pipeline identities.

Proof of concept

1. Configure OIDC federation from your CI platform and from one cluster, and confirm no static secret is needed to push or pull.
2. Give a pipeline identity push rights to one repository, then try to push to a second repository and to overwrite an immutable release tag. Both must fail and be logged.
3. Push an image with a signature, an SBOM and SLSA provenance attached through the referrers API, promote it to a production repository and replicate it, then confirm all three are still discoverable.
4. Enable signature enforcement at cluster admission and deploy an unsigned image to prove the block works.
5. Through the proxy, request a package version on your block list and a newly published version under quarantine, and confirm both are held.
6. Push an image containing a test credential and check that the scanner flags it.
7. Stream audit logs to your SIEM and trace each action above to an identity.
8. Export a repository with its referrers and restore it to a clean instance; record the time and any lost metadata.

After go-live, measure whether the registry is delivering what you bought it for. Useful indicators are the share of production deployments pulled by digest and verified at admission; the number of long-lived robot credentials still in use, trending to zero as federation replaces them; median time from a malicious package report to a block at the proxy; the share of release repositories with tag immutability on; and the count of images older than your retention policy still referenced by running workloads.

Framework mapping

At control level the requirements also sit in CIS Controls v8.1 Control 2 (Inventory and Control of Software Assets), Control 7 (Continuous Vulnerability Management) and Control 16 (Application Software Security).

Standards and references

• NIST: SP 800-190 Application Container Security Guide
• Open Container Initiative: Distribution Specification
• OpenSSF: Principles for Package Repository Security
• Sigstore: Verifying signatures with Cosign
• SLSA: Specification v1.2
• NIST: SP 800-53 Rev. 5
• OWASP: Top 10 CI/CD Security Risks

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for registry and artefact platforms, including the robot accounts and federated identities that push and pull. Browse vendors in our NHI and AI products directory or contact us.

Related NHI Mgmt Group resources: Container Registry Security Guide · SLSA and Build Provenance Guide · Container Image Security Guide · If your artefact and container registry is compromised · Security Requirements for Selecting a Managed Kubernetes Service