What a Container Registry Audit Actually Checks

A container registry audit examines five separate domains of trust, not one CVE report. Container images now function as supply chain artifacts rather than simple deployment packages: every image that lands in a registry carries provenance, dependency, and integrity implications that a single vulnerability scan cannot surface on its own. The registry is the chokepoint. It is the place where supply chain security either happens or fails to happen, and the September 2026 evaluation from cybersecuritynews.com frames the controls that matter as image scanning, SBOM generation, signing, and admission policy, each treated as its own domain rather than a single pass/fail gate.

The threat data backs up the layered view. That is not a scanning problem alone. It is a provenance problem, an access problem, and, often, a reproducibility problem stacked on top of each other.

So an audit walks five domains in sequence: vulnerability scanning coverage and cadence, SBOM completeness and provenance, access controls and identity hygiene, image signing paired with admission enforcement, and environment reproducibility, otherwise known as drift. Each gets its own section below, in the order an auditor typically works through them. The Verizon DBIR found that exploitation of vulnerabilities became the most common initial access vector for breaches, rising to 31% of the reporting dataset, validating the layered framing since container registries are a primary delivery mechanism for those vulnerabilities.

How auditors evaluate vulnerability scanning

Start with the scale of the problem. Research cited by auditors puts the average container image at 604 vulnerabilities, and public repositories have been found to host roughly 704,000 malicious packages. Against numbers like that, "we scan on push" stops sounding like a control and starts sounding like a shrug.

Auditors do not ask whether scanning exists. They ask whether it is deep enough and frequent enough to matter. Depth means checking OS packages, language-specific packages, infrastructure-as-code files, secrets, malware, and licenses, beyond running CVE matches against OS packages. Cadence means scanning on every push, running scheduled scans tied to CVE feed updates from the NVD and distro advisories, and scanning again before an image gets promoted into a higher environment. An image that passed a scan two weeks ago has not been checked against whatever got disclosed since.

The mechanism matters too. Registry-integrated scanning, the kind Clair performs through static layer-by-layer analysis as images land in the registry, catches things that CI-only scanning misses, because CI-only scanning has no visibility into what happens to an image after it's pushed. An image that gets modified or re-tagged post-push can slip past a pipeline that only ever looked at the build-time artifact.

The cybersecuritynews.com scorecard from September 2026 weights scanning depth at 25% of its overall evaluation, tied with SBOM and provenance for the top spot. That weighting is itself a finding: depth and breadth of scanning matter as much as the simple fact of having a scanner switched on.

A sharper gap causes all of this, and the sections below show what it produces. Scanning tells you what is present in an image. It does not tell you what is exploitable once that image is running. Sysdig's approach to in-use vulnerability prioritization, which validates whether a flagged package is actually loaded at runtime, points at the direction auditors now expect teams to move toward: from static presence to runtime relevance. A scan result with no runtime context just generates a long list nobody triages properly.

None of this happens in a vacuum, either. PCI DSS v4.0.1 requirement 10.5.1 requires organizations to retain audit log history for at least 12 months, with recent logs available for analysis, and that's a documentation obligation an auditor checks independent of whatever the scan results say. Auditors also expect to see evidence tied to specific tool categories: registry-integrated scanning such as Clair's layer-by-layer, API-driven model, commonly built into the registry itself, and CI/CD or filesystem-level scanning through tools like Trivy, which covers OS packages, language packages, infrastructure-as-code, and Kubernetes manifests, alongside Grype, which scans images, filesystems, and SBOMs. SBOM generation paired with scanning represents something of an open-source floor for this work, a baseline many teams build from before adding anything more sophisticated.

SBOM completeness: what auditors look for

Most organizations that generate SBOMs say the practice helps them mitigate vulnerabilities more efficiently. Omdia's software supply chain security report finds that an even larger share of those same organizations say the generation process itself is still difficult. That gap, between value acknowledged and difficulty experienced, is the single biggest thing an SBOM audit finds: most teams are working from partial or inconsistently maintained SBOMs, and partial documentation fails an audit almost as reliably as no documentation at all.

An SBOM is, in essence, the ingredient list for a container image. It enumerates every component, library, and dependency inside the artifact, which is what makes vulnerability matching, license review, and regulatory attestation possible in the first place. Without a complete one, a vulnerability scan has nothing reliable to match against.

Auditors check past the binary question of an SBOM's existence. Format compliance is one axis: SPDX and CycloneDX are the formats widely accepted for EU Cyber Resilience Act compliance, though the CRA text itself only requires a commonly used, machine-readable format and does not formally name either standard. Freshness is another: an SBOM generated once at build time and never touched again does not reflect layers added or dependencies updated after the fact. SLSA alignment matters too, meaning whether the SBOM comes paired with provenance attestations, with SLSA Level 3 cited as the benchmark in current hardened image offerings. And taxonomy coverage has been expanding: CERT-In's 2024 SBOM guidelines, Version 1.0, focused narrowly on software components, but by July 2025, Version 2.0 broadened scope to cover CBOM, QBOM, AIBOM, and HBOM, and auditors working in regulated industries now expect that wider coverage as a matter of course.

The regulatory calendar is what turns SBOM completeness from a nice-to-have into an audit requirement. Under the EU Cyber Resilience Act, actively exploited vulnerabilities must be reported starting 11 September 2026, and a machine-readable SBOM becomes mandatory for products with digital elements placed on the EU market from 11 December 2027 onward, though not retroactively for products already on the market before that date. In the US, Executive Order 14028 requires federal software vendors to provide SBOMs, with NIST SP 800-218 defining the secure development practices auditors map their controls against. The money is following the mandate: the SBOM market is projected to grow from roughly €1.0 billion in 2024 to €5.4 billion by 2033, with large enterprises accounting for the majority of that spend, and that kind of investment curve reflects regulatory pressure building, not maturity arriving on its own schedule.

What auditors treat as leading practice goes past a static SBOM entirely. Execution lineage, sometimes packaged as a pipeline bill of materials, reveals which dependencies actually create risk in a running workload rather than simply which ones sit present in an image layer. That distinction, between present and consequential, runs through nearly every domain this piece covers.

Image signing and admission control: how auditors verify that provenance claims hold at runtime

Scanning and SBOMs answer the question of what's inside an image. Signing answers a different question: has this exact artifact been tampered with between the moment it was built and the moment it got deployed? Auditors treat these as separate, complementary controls, not overlapping onesc27. An image can carry a clean scan and a complete SBOM and still not be the image that was supposed to ship, if nothing verifies that the bits running in production match the bits that were attested at build time.

Signing catches what scanning cannot: a tampered image, or one that's been quietly rolled back to an older, vulnerable version, will often pass a CVE scan cleanly, because the scan only checks contents, not identity. The check auditors run here is concrete and specific. Is a Kubernetes admission controller configured to reject any pod whose image lacks a valid signature tied to the expected build identity, so that unsigned or manipulated images get blocked before they ever execute? Are policy gates enforced at the promotion step itself, so an image can't move from dev to staging, or staging to production, without a passing signature and SBOM attached?

The 2026 scorecard from cybersecuritynews.com weights enforcement, meaning admission control and policy gates together, at 20% of the total evaluation, third behind scanning and SBOM/provenance. But that ranking undersells the importance of the layer, because enforcement is where documentation stops being paperwork and starts being an operational control that actually blocks something.

The clearest illustration of what happens without it involves a widely used GitHub Action. Attackers modified historical Git tags on the action, which was in use across an estimated 23,000-plus repositories, and the tampered tags exposed CI/CD secrets in workflow logs that were publicly accessible. That's not a scanning failure. Nothing about that incident would have shown up in a CVE database. It's a signing and admission control failure: nothing verified that the tag pointed to the commit it claimed to point to.

The cost of failures like that one keeps climbing. Software supply chain attacks are estimated to cost the global economy more than $80 billion in 2026, a dramatic jump from 2023 levels, and the Jaguar Land Rover incident in August 2025 makes the abstract number concrete: production halted for five weeks, with financial damage on a large scale. Auditors treat a missing signature, accordingly, as a high-severity finding. It is not a documentation gap to note and move past. Scanning and SBOMs document what an image contains, while signing proves it has not been tampered with between build and deployment, and auditors treat these as distinct, complementary controls.

Access controls and identity hygiene: what auditors find when they map who can push, pull, and promote

A scanned, signed image can still be swapped out or poisoned if the credentials used to push to the registry are over-permissioned or sitting compromised somewhere. Access control makes every other control mean something, because signing and scanning both assume the registry itself hasn't been quietly subverted from the inside.

Palo Alto Networks' guidance on registry security has auditors map every identity with programmatic access to the registry: service accounts, CI/CD pipelines, individual developer credentials, and automation tokens, the full set. For each one, the check runs through the same questions. What provider issued it? What permissions does it hold, versus what permissions does it actually use in practice? When did it last authenticate? Is there a defined inactivity period after which stale accounts get disabled automatically, or do dormant credentials just sit there indefinitely, technically valid and unwatched?

Secrets management gets checked as its own line item, separate from the identity mapping. Auditors verify that API keys, registry credentials, and passwords live in a proper secrets manager, rather than sitting embedded in a container build file, a CI configuration file, or, worse, baked into an image layer where anyone who can pull the image can read them out. This has to be enforced structurally. Leaving it to developer discretion means it will not happen consistently, and auditors know that going in.

The scenario that ties all of this together is privilege escalation. An identity holding more permissions than its job requires can modify images after the fact, alter tags to point somewhere else, suppress scan results, or change the registry's own access policies. Each of those is a distinct path toward distributing a compromised image at scale, and each depends on the same root cause: permissions that were never scoped down to what the identity actually needed.

RBAC for Kubernetes workloads sits right next to this as the adjacent control to check. Least-privilege service accounts assigned per workload, and workload identity federation replacing static, long-lived tokens for cloud resource access, are both things auditors look for. Registry access controls and cluster access controls, scoped by two different teams at two different times, frequently end up tighter on one side than the other. An auditor checks whether the two are consistently scoped or has quietly drifted looser than the other.

Environment reproducibility and image drift: the registry audit dimension most teams do not expect

Containers are now mainstream infrastructure. The 2025 CNCF annual survey put the share of organizations using containers for production applications at 56%, and 82% of those container users run Kubernetes in production. At that scale, uncontrolled drift in a base image doesn't stay contained to one team's corner of the infrastructure. It propagates across an entire estate, often silently.

A registry audit does not stop at checking what images contain. It checks whether the registry is actually being used to enforce environment consistency, and it checks whether the inputs that produced a given image are deterministic enough that the same image could be rebuilt from scratch and come out identical. That second question turns out to be harder than most teams assume.

Pinning version numbers is not enough on its own. A 2026 arXiv study found that small build variations can sharply reduce reproducibility, and, more surprisingly, that much of the non-determinism traces back to the surrounding build infrastructure rather than to the packages being installed. Timestamps embedded during compilation, file ordering that varies by filesystem, build tool versions that drift underneath a pinned application dependency: these all introduce variance that pinning a package version does nothing to fix. Auditors look for pinned base image digests, locked dependency versions, and build steps that are actually deterministic, beyond nominal version control.

Practically, a short, specific list of checks captures this. Are images referenced by immutable digest, rather than by a mutable tag like latest that can point at a different artifact tomorrow without anyone touching the deployment manifest? Is the exact same binary artifact, one digest carried forward, promoted across dev, staging, and production, rather than a fresh rebuild triggered at each environment boundary? Is the build process hermetic, with no external fetches happening mid-build that could pull in something different from one run to the next? And can a team roll back to a known-good image in a single step, or does rollback actually require a full rebuild, with everything a rebuild might reintroduce?

There's a connection here to something familiar from pre-container infrastructure. The most common source of drift in non-containerized environments has always been manual changes made outside of version control. A registry audit that reveals undocumented, unstandardized base images shows the same failure mode wearing a different costume: a team has nominally adopted containers, but the discipline around what actually goes into those containers never caught up to the technology itself.

The principle auditors keep coming back to is that the manifest should be the source of truth. When an environment's definition is declarative and versioned, specifying exact package versions, exact base image digests, and exact build inputs in a file that lives in version control, an auditor can check that what's sitting in the registry actually matches what's written down. When that declarative definition doesn't exist, or has drifted out of sync with what's actually running, there is nothing left to verify against.

Onboarding and productivity risks that registry audit findings surface

A registry full of undocumented, inconsistently tagged images is a security problem, but it's just as much a productivity problem hiding behind a security framing. A new developer who can't pull a known-good environment on day one has to reconstruct that environment from whatever documentation happens to exist, and incomplete documentation means guesswork, and guesswork means lost time that compounds across every new hire who goes through the same process.

A Gartner report found that organizations that implement platform engineering practices see onboarding times drop substantially. That's the baseline an audit finding should get measured against: when an audit flags missing or undocumented base images, that finding isn't just a checkbox on a security scorecard. It represents actual onboarding time being lost, week over week, against what a well-governed registry would deliver.

Two specific checks fall under this heading. First, are images versioned and tagged consistently enough that a new hire can pull a known development environment without needing to ask three people what the current setup actually looks like? Second, does the registry actually include environment images, meaning development toolchains, CI runners, and build environments, alongside the application images, or are those managed ad hoc somewhere outside the registry's governance entirely?

That second question tends to be the one that catches teams off guard. Plenty of organizations govern their application images carefully while leaving CI runners and developer toolchains completely outside the same scrutiny, treating them as internal tooling rather than as artifacts that deserve the same scanning, signing, and access control applied everywhere else. An auditor walks into that gap and asks, reasonably, why one category of image gets the full review across vulnerability scanning coverage and cadence, SBOM completeness and provenance, access controls and identity hygiene, image signing and admission enforcement, and environment reproducibility, while another sits untouched. There usually isn't a good answer.