An artefact or container registry is the last trusted hop before code runs in production, yet it is rarely reviewed after go-live: machine tokens accumulate, tags get overwritten, stale images with known vulnerabilities stay pullable and nobody checks whether the signatures attached to artefacts are still there. This health check is a recurring, measurable review of a live registry that stores container images, language packages, Helm charts or other build outputs, whether self-hosted or delivered as a service. It turns the questions an auditor or platform security lead would ask into twelve metrics with formulas, thresholds and evidence, so each quarter can be compared with the last. It is written for registry and platform owners, DevSecOps leads, internal audit and the CISO's office.
This page measures; it does not explain how to configure a registry. For control design, read the Container Registry Security Guide, and return to it for every finding this review raises. If a red flag turns out to be an intrusion, switch to If your artefact and container registry is compromised.
What this health check covers
The review covers the registry service and its storage, the people and machine identities that push and pull, repository permissions, tag and digest behaviour, attached signatures and attestations, scanning and retention, upstream proxies and mirrors, and the registry's audit trail. The CI/CD server that builds the artefacts and the clusters that run them have their own reviews and appear here only where they depend on the registry.
- Who runs it: the registry or platform owner collects the figures; the DevSecOps or application security lead reviews them; the head of platform engineering and the CISO or delegate sign off red items.
- How it differs from the companion checks: the CI/CD server health check measures credentials, agents and whether deployments verified provenance. This check measures what the registry itself holds and allows: who can write, whether references are immutable, whether integrity evidence is stored beside each artefact and whether stale content is still served.
- Why the identity angle matters: most writes to a registry come from machines. Push tokens, robot or service accounts, pull secrets and federated build identities are non-human identities, and they are where most findings land.
- Search terms it answers: "container registry security audit", "artefact repository health check", "registry access review checklist" and "how to audit image signing coverage".
Key takeaways
- Write access is the crown jewel. Count every identity that can push or delete in production repositories, and every one that is long-lived or ownerless.
- Tags move, digests do not. The OCI Distribution Specification treats tags as movable pointers; measure how many production repositories block tag overwrite.
- Integrity evidence must be stored with the artefact. Measure the share of production artefacts with an attached signature and provenance, not the share of pipelines able to create them.
- Stale content is a deployment risk. NIST SP 800-190 warns that old, vulnerable images in a registry raise the chance of accidental deployment; prune and measure.
- Thresholds are a starting point. The bands below are NHI Mgmt Group recommendations; agree your own and keep them stable between quarters.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this artefact and container registry health check at the cadence below. Collect each figure from the data source types described, score it against the green, amber and red bands, and log every amber or red result as a finding with an owner and a due date. Run it per registry instance if you operate several, and keep each completed review so the quarter-on-quarter trend is visible.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Machine token and robot account inventory | Monthly | Registry owner | NHI or secrets management lead | Token and account export (metadata only), last-used dates, owners |
| Registry software and storage update status | Monthly (self-hosted) | Registry owner | Platform engineering lead | Version inventory, outstanding security updates with age |
| Full metrics review (this page) | Quarterly | Registry owner | Head of platform engineering and CISO or delegate | Metrics table with figures, raw exports, findings log |
| Repository permission and admin review | Quarterly | Registry owner | Security risk or GRC | Role and permission export, approved list, changes since last review |
| Independent sample test | Annually | Internal audit or second line | Audit committee | Sample of running workloads traced back to a registry digest, signature and provenance |
| Event-driven review | After a registry or upstream package compromise advisory, migration or major upgrade | DevSecOps lead | CISO or delegate | Affected repositories, digests and tokens, rotation evidence |
The people who administer the registry should not be the only ones signing off figures about its own permissions, in line with separation of duties under NIST SP 800-53 Rev. 5 AC-5.
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Production repository" means any repository that a production deployment pulls from. "Write identity" means any human or machine identity that can push, overwrite, delete or change repository settings.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| AR-01 | Registry administrators on the approved list | Holders of registry-wide admin rights who are on the approved list and use a named account ÷ all holders | Registry role export, identity provider group membership | 100% and five or fewer holders | 100% but more than five holders | Below 100%, or any shared admin account |
| AR-02 | Machine write identities to production repositories | Machine identities with push, overwrite or delete on production repositories that map to exactly one build pipeline ÷ all machine write identities on those repositories | Registry token and robot account export with scopes, CI pipeline inventory | 100% | 90% to below 100% | Below 90% |
| AR-03 | Long-lived registry tokens | Registry tokens or robot account secrets with no expiry or older than your rotation period ÷ all registry tokens | Token metadata export (creation, expiry, last used) | Below 5% | 5% to 20% | Above 20% |
| AR-04 | Unused registry tokens | Tokens and robot accounts with no authenticated request in 90 days ÷ all tokens and robot accounts | Token last-used metadata, registry access logs | Below 5% | 5% to 15% | Above 15% |
| AR-05 | Anonymous or public read on private content | Count of repositories holding internal artefacts that allow unauthenticated pull | Repository visibility settings export | 0 | None (no amber band) | 1 or more |
| AR-06 | Tag immutability on production repositories | Production repositories that block overwriting or deleting existing release tags ÷ all production repositories | Repository settings export | 100% | 90% to below 100% | Below 90% |
| AR-07 | Tag overwrite events | Count of pushes in the quarter that moved an existing release tag in a production repository to a new digest | Registry audit log (push events with previous and new digest) | 0 | 1 to 2, each with an approved change | 3 or more, or any without an approved change |
| AR-08 | Signature coverage in production repositories | Artefacts pulled by production in the quarter that have a valid signature attached in the registry ÷ all artefacts pulled by production | Referrers or attached artefact listing per digest, production pull logs | 95% or more | 80% to below 95% | Below 80% |
| AR-09 | Provenance and SBOM attachment | Production artefacts with both a provenance attestation and an SBOM attached ÷ all production artefacts | Referrers or attached artefact listing filtered by artefact type | 90% or more | 60% to below 90% | Below 60% |
| AR-10 | Stale vulnerable artefacts still pullable | Artefacts with a critical vulnerability that has had a fix available for more than 30 days and that remain pullable from production repositories ÷ all artefacts in production repositories | Registry scan results, retention and quarantine settings | Below 2% | 2% to 10% | Above 10% |
| AR-11 | Upstream pulls through governed proxy | Builds that resolve public images and packages through the organisation's proxy or mirror repository ÷ all builds that use public content | Proxy repository logs, egress firewall or DNS logs from build agents | 95% or more | 80% to below 95% | Below 80% |
| AR-12 | Secrets found in stored artefacts | Confirmed secrets detected in image layers or package contents in the quarter; report the count and time to revocation | Secrets scanning results over registry content | 0, or all revoked within 24 hours | Any, all revoked within 72 hours | Any not revoked within 72 hours |
AR-08 and AR-09 measure evidence held by the registry. Whether a deployment checked that evidence is measured by CI-10 in the CI/CD server health check, so do not count it twice.
How to collect the data
- Identities and permissions (AR-01 to AR-04): export the registry's role assignments, token and robot account list with scopes, creation, expiry and last-used dates. Join machine identities to the CI pipeline inventory to find tokens that serve several pipelines or none. Export metadata only, never token values.
- Visibility and immutability (AR-05, AR-06): export repository settings. Mark production repositories from deployment manifests or admission policy configuration, not from naming conventions.
- Tag movement (AR-07): read push events in the registry audit log and flag any where a tag already existed with a different digest. The OCI tag list endpoint (
/v2/<name>/tags/list) shows current tags; comparing quarterly snapshots of tag to digest mappings catches overwrites when the audit log is thin. - Attached evidence (AR-08, AR-09): for registries that implement the OCI referrers API (
/v2/<name>/referrers/<digest>), list the manifests whosesubjectis each production digest and filter byartifactTypefor signatures, provenance and SBOMs. Where the referrers API is not offered, clients use the referrers tag schema, which stores the same index under a derived tag. - Scanning and staleness (AR-10): use the registry's scan results or an external scanner run across production repositories, joined to fix availability dates.
- Upstream (AR-11): compare proxy repository request logs with egress logs from build agents to find builds pulling public content directly.
- Secrets (AR-12): scan image layers and package archives, not only source repositories. Images inherit files from every layer, including ones later deleted in the build.
Red flags that need action now
- A machine token with delete or overwrite rights on production repositories that has no owner or has not been used for 90 days.
- Any repository holding internal artefacts that allows anonymous pull. NIST SP 800-190 says all access to registries containing proprietary or sensitive images should require authentication.
- A release tag in a production repository that moved to a new digest without an approved change. Treat it as possible tampering (ATT&CK T1525 Implant Internal Image) until proven otherwise.
- Signatures or attestations missing from artefacts that had them last quarter, which can indicate deletion or a re-push.
- Registry connections from builds or clusters over unencrypted channels; NIST SP 800-190 recommends connecting to registries only over encrypted channels.
- A confirmed secret in a pushed image that has not been revoked. Public exposure of this kind is common: see the 2025 study of 10,456 public container images that exposed cloud, CI and AI keys.
- Registry audit logging disabled, or a gap of more than 24 hours in registry events reaching the SIEM.
- An outstanding registry software update for a vulnerability in the CISA Known Exploited Vulnerabilities catalogue (self-hosted).
Findings log
Keep one running log across quarters. Escalate a finding that stays red for two consecutive quarters to the CISO, and one that repeats three times to the risk register.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-AREG-01 | [n] machine write identities on production repositories shared by several pipelines | AR-02 | [Red / Amber] | [Registry owner] | [Date] | [Open / In progress / Closed] |
| HC-AREG-02 | [n] production repositories without tag immutability | AR-06 | [Severity] | [Platform engineering lead] | [Date] | [Status] |
| HC-AREG-03 | [n] production artefacts pulled without an attached signature | AR-08 | [Severity] | [Release manager] | [Date] | [Status] |
| HC-AREG-04 | [n] stale artefacts with fixed critical vulnerabilities still pullable | AR-10 | [Severity] | [Service owner] | [Date] | [Status] |
| HC-AREG-05 | [Finding] | [Metric ID] | [Severity] | [Owner] | [Date] | [Status] |
Remediation map
| Finding type | Where to fix it |
|---|---|
| Excess administrators, broad write identities, anonymous pull | Container Registry Security Guide: access control for people and machines |
| Long-lived or unused registry tokens | Workload Identity Federation Guide; Secrets Management Guide |
| Mutable tags and tag overwrites | Container Registry Security Guide: tags, digests and immutability |
| Missing signatures | Sigstore Guide; Code Signing vs Artifact Attestation |
| Missing provenance or SBOM | SLSA and Build Provenance Guide; SBOM Guide |
| Builds pulling public content directly | Malicious Package and Dependency Confusion Guide |
| Secrets in image layers | How to find secrets in CI logs and build artefacts |
| Unverified pulls reaching clusters | Kubernetes Admission Control Guide |
Related guides
- Container Registry Security Guide: the control design this check measures.
- If your artefact and container registry is compromised: response when a red flag is an attack.
- Artefact and container registry migration playbook: keeping digests, signatures and referrers intact when moving platforms.
- CI/CD server health check: the companion check on the build side.
- Container Security Maturity Model: the wider programme view.
References
- NIST: SP 800-190, Application Container Security Guide (sections 3.2 and 4.2, registry risks and countermeasures)
- Open Container Initiative: Distribution Specification
- Open Container Initiative: Image Manifest Specification (subject and artifactType)
- OWASP: Top 10 CI/CD Security Risks (CICD-SEC-7 Insecure System Configuration, CICD-SEC-9 Improper Artifact Integrity Validation)
- NSA and CISA: Defending Continuous Integration/Continuous Delivery (CI/CD) Environments
- OpenSSF SLSA: Build track basics (v1.2)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-5, AC-6, IA-5, AU-2, SI-7, SR-4, SR-11, RA-5)
- CIS: Software Supply Chain Security Benchmarks
Related NHI Mgmt Group resources: Container Registry Security Guide, If your artefact and container registry is compromised, CI/CD server health check, CI/CD server rollout playbook.