Container registry vulnerability scanning checks the images stored in a registry, such as Amazon ECR, Azure Container Registry (ACR), Google Artifact Registry (the successor to GCR), or Harbor, against known CVE data. It runs when an image is pushed and keeps running afterward, so vulnerable images get flagged before they deploy and again when new CVEs are published. The registry is the right checkpoint because every image passes through it. CI builds land there, public images get promoted into it, and Kubernetes pulls from it. Each registry handles scanning differently, though. Some scan automatically while others need a paid add-on, some cover only OS packages, and few rescan old images unless you configure them to. This guide, current as of October 2026, explains how scanning works inside each registry, how the four compare, how to wire findings into CI/CD and admission control, and how to prioritise the results so your backlog shrinks instead of growing.
Key takeaways
- ✓Registry scanning works best as one stage in a chain of CI scanning, registry scanning, admission control, and runtime detection, not as a standalone control.
- ✓Amazon ECR, Azure Container Registry, Google Artifact Registry, and Harbor all scan images, but they differ on automatic triggers, language-package coverage, rescanning, and pricing model.
- ✓Tracking findings by immutable image digest instead of mutable tags is the only reliable way to know which scanned image is actually deployed.
- ✓Scheduled or continuous rescanning matters as much as scan-on-push, because most new CVEs affect images that are already sitting in the registry.
- ✓Prioritising by fix availability, exploitability, internet exposure, and whether the image is actually running cuts the backlog far more than sorting by CVSS alone.
What container registry vulnerability scanning covers
Registry scanning inventories the packages inside each stored image and matches them against vulnerability databases, then attaches the findings to that image’s digest. The general mechanics are the same as container image scanning. What differs is where the scan runs and when.
How a scan engine produces findings
- Unpack layers. The scanner reads each filesystem layer of the image, including layers inherited from the base image.
- Detect the OS. It reads the image’s OS release file to identify the distro, for example Debian 12, Alpine 3.20, or Ubuntu 24.04.
- Inventory packages. It parses OS package databases (dpkg, apk, rpm) and language manifests or lockfiles such as
package-lock.json,requirements.txt,go.sum, and JAR metadata. - Match versions. It compares each package version against vendor security trackers (Debian, Red Hat, Alpine secdb, Ubuntu) and sources such as NVD and GitHub Security Advisories.
- Assign severity. It reports a severity, which may come from the distro vendor’s rating or the NVD CVSS score. This is one reason two tools disagree.
Tags vs digests
Tags like :latest or :1.4 are mutable. A tag can point to a different image tomorrow. Digests (sha256:…) are content hashes, so they never change. Record scan results, policy decisions, and deployment references by digest. Otherwise a clean scan of app:1.4 on Monday tells you nothing about the app:1.4 that was re-pushed on Wednesday. Turning on tag immutability in the registry, which ECR, ACR, Artifact Registry, and Harbor all support, closes the gap further.
Where registry scanning fits
| Stage | What it catches | What it misses |
|---|---|---|
| CI scanning (e.g. Trivy or Grype in the pipeline) | Vulnerable packages and secrets before push; fails the build early | CVEs published after the build; images pushed outside CI |
| Registry-native scanning | Every image stored, including public images promoted in; rescans as new CVEs appear | Whether the image is deployed, exposed, or loading the vulnerable package |
| Admission control | Blocks unscanned, unsigned, or over-threshold images at deploy time | Anything already running before the policy existed |
| Runtime detection | Which packages are loaded, which workloads are internet-facing, active exploitation | Images that never get deployed |
How to scan ECR, ACR, GCR, and Harbor images
Each registry offers a basic native option and a richer tier or plugin. The right choice depends on whether you need language-package coverage and continuous rescanning.
Amazon ECR
How to enable: ECR offers basic scanning (OS packages, scan-on-push or manual) and enhanced scanning through Amazon Inspector (OS and programming-language packages, continuous rescanning).
From the AWS CLI, put-image-scanning-configuration with scanOnPush=true turns on scan-on-push for one repository. put-registry-scanning-configuration with the ENHANCED scan type and a CONTINUOUS_SCAN rule (for example, filtered to prod-* repositories) moves the registry to Inspector. describe-image-scan-findings returns the findings for one image digest.
- ✓Findings: Returned by the ECR API. Enhanced findings also appear in Inspector (
aws inspector2 list-findings), AWS Security Hub, and Amazon EventBridge events for routing to tickets or a SIEM. - ✓Strengths: Wildcard repository filters let you put continuous scanning on production repositories only, and the AWS integrations are deep.
- ✓Best for: AWS-centric teams that want continuous rescanning without running a scanner themselves.
Weaknesses: Basic scanning skips language packages and does not rescan automatically. Enhanced scanning is billed through Inspector.
Azure Container Registry
How to enable: ACR scanning comes from Microsoft Defender for Containers, enabled at the subscription level (az security pricing create --name Containers --tier Standard). Images are scanned on push and on import, and images that were recently pushed or pulled are rescanned periodically.
- ✓Findings: Surfaced as Defender for Cloud recommendations and queryable through Azure Resource Graph (the securityresources table, filtered to sub-assessments). They can be exported continuously to Log Analytics, Event Hubs, or Microsoft Sentinel.
- ✓Strengths: Rescanning is automatic and ties in with Azure Policy and AKS posture findings.
- ✓Best for: Azure and AKS shops already using Defender for Cloud.
Weaknesses: There is no free scanning tier inside ACR itself. Scanning is part of the Defender plan, and the findings live in Defender rather than in the registry API.
Google Artifact Registry (formerly GCR)
How to enable: Google Container Registry has been replaced by Artifact Registry. Turn on the Container Scanning API to scan automatically on push. The scanner keeps analysing recently pushed or pulled images as new CVE data arrives. The On-Demand Scanning API handles local or CI images.
From the gcloud CLI, enable the containerscanning.googleapis.com service, read an image’s findings with gcloud artifacts docker images describe and its show-package-vulnerability option, and scan a local or CI image on demand with gcloud artifacts docker images scan.
- ✓Findings: Stored as Artifact Analysis occurrences. Changes are published to Pub/Sub, which works well for ticketing and SIEM pipelines, and Binary Authorization can gate GKE deployments on them.
- ✓Strengths: Covers OS packages plus common language ecosystems, and offers on-demand scanning for CI.
- ✓Best for: GKE and Cloud Run teams that want scan results feeding deploy-time attestations.
Weaknesses: Continuous analysis stops for images that go unused for a while, so long-lived but rarely pulled images can go stale. Scanning is billed per scanned image.
Harbor
How to enable: Harbor ships with Trivy as its default scanner. It also supports pluggable scanner adapters, so you can register other engines. Turn on “Automatically scan images on push” per project, and schedule “Scan All” for periodic rescans.
A CI pipeline can trigger a scan through Harbor’s v2.0 API: a robot account sends a POST to the artifact’s scan endpoint, addressed by its digest.
- ✓Findings: Available through the v2.0 API and webhooks, with per-artifact severity summaries.
- ✓Strengths: A project setting can stop vulnerable images from being pulled above a chosen severity. CVE allowlists support expiration dates. Harbor also supports Cosign signatures and SBOM generation.
- ✓Best for: On-prem, air-gapped, and multi-cloud teams that want one registry policy everywhere.
Weaknesses: You run the infrastructure, keep the Trivy database current (which takes extra work in air-gapped setups), and build your own reporting.
Side-by-side comparison
| Capability | Amazon ECR | Azure ACR | Google Artifact Registry | Harbor |
|---|---|---|---|---|
| Scan triggers | Push, manual; continuous (enhanced) | Push, import, periodic rescan | Push, continuous analysis, on-demand | Push, manual, scheduled Scan All |
| OS packages | Yes | Yes | Yes | Yes (Trivy) |
| Language packages | Enhanced only | Yes | Yes | Yes (Trivy) |
| Rescanning | Continuous with Inspector, configurable duration | Automatic for recently used images | Automatic for recently used images | Scheduled |
| Pricing model | Basic free; enhanced via Inspector | Defender for Containers plan | Per scanned image | Open source; you pay for infrastructure |
| Suppression | Inspector suppression rules | Defender disable rules | Via Binary Authorization policy or tooling | CVE allowlist with expiry |
| API and integrations | ECR API, Security Hub, EventBridge | Resource Graph, Sentinel, Event Hubs | Artifact Analysis API, Pub/Sub, Binary Authorization | REST API, webhooks, scanner adapters |
When native coverage falls short, for example ECR basic scanning with Node.js or Java images, run Trivy or Grype in CI against the same digest and push the results as an attestation. Harbor can also swap scanners through its adapter interface without changing your pipeline.
Why scanners disagree: false positives, unfixed CVEs, and edge cases
Two scanners report different results for the same image because they use different data sources, package detection logic, and severity rules. Knowing the causes saves hours of triage.
- ✓Distro backports: Red Hat and Debian patch vulnerabilities without changing the upstream version number. A scanner that matches against NVD ranges instead of the distro tracker flags fixed packages as vulnerable.
- ✓Severity sources: Debian may rate a CVE “low” while NVD scores it 9.8. Check which source each tool uses before you compare counts.
- ✓Unfixed CVEs: Many findings are marked “will not fix” or have no patch yet. Some tools hide them by default (Trivy’s
, ignore-unfixed) and others show them. - ✓Package attribution: Binaries copied in with
COPYorcurlhave no package database entry, so OS-based scanners miss them. Go binaries are detected only when their build info is intact. - ✓Distroless and scratch images: Distroless images keep a minimal package database, so scanners can still read them. Scratch images often have none, so scanning depends on language metadata embedded in the binary. Generate an SBOM at build time for these.
- ✓Multi-arch images: An image index points to separate amd64 and arm64 manifests, each with its own digest and possibly different packages. Make sure your registry scans every platform manifest, including the ones your laptop didn’t pull.
Can a registry scan find secrets? Trivy and similar scanners can detect keys, tokens, and private key files baked into image layers, including files deleted in a later layer, which remain in the earlier one. Deleted-but-committed secrets in Git history and credentials in source code must be caught earlier with Git pre-commit and repository scanning. Once a secret reaches an image, rotate it, because rebuilding alone does not revoke it.
Building the pipeline: build, push, scan, gate, deploy, rescan
A working registry scanning workflow treats the registry scan as one gate in a digest-tracked chain from build to runtime. The countermeasures the Cloud Security Alliance lists for image vulnerabilities and untrusted images map directly onto these stages.
- Build: Scan in CI with Trivy or Grype, generate an SBOM (SPDX or CycloneDX, for example with Syft), and fail the build on fixable criticals.
- Sign and attest: Sign the digest with Cosign (Sigstore) and attach the SBOM and scan results as attestations, so you can trace later which source and dependencies produced the image.
- Push and registry scan: Push by digest with scan-on-push enabled. Promote public images, such as
nginxorpython, into a private “quarantine” repository first. Scan them there, then copy approved digests to the production repository. - Policy gate: Enforce thresholds with Kubernetes admission control. Kyverno
verifyImagesrules or OPA Gatekeeper can require a valid signature and a vulnerability attestation under the threshold. GKE teams can use Binary Authorization, and Harbor can block pulls itself. - Deploy: Reference images by digest in manifests (
image: app@sha256:…) so the deployed artifact is the one you scanned. - Rescan: Turn on continuous rescanning (ECR enhanced, Defender, Artifact Analysis) or schedule Harbor’s Scan All daily. Then periodically re-pull and rescan long-lived images that have dropped out of a registry’s continuous window.
- Export: Send findings to ticketing (Jira, ServiceNow) and your SIEM through EventBridge, Event Hubs, Pub/Sub, or Harbor webhooks. Keep a digest-level export for compliance evidence such as PCI DSS or SOC 2 vulnerability management controls.
Sample severity policy
| Environment | Critical | High | Medium/Low | No-fix CVEs |
|---|---|---|---|---|
| Production | Block if a fix exists | Block if fixable and exploited in the wild (e.g. listed in CISA KEV) | Report only | Allow with an exception that expires in 30 days |
| Staging | Block if a fix exists | Warn | Report only | Allow with an exception that expires in 90 days |
| Development | Warn | Warn | Report only | Allow |
Every exception should record the CVE, the digest, an owner, a justification, and an expiry date. Harbor’s allowlist expiry and Inspector suppression rules can enforce this natively. Review exceptions when a fix ships so they do not become permanent by default.
Prioritizing and fixing what registry scans find
The fastest way to reduce registry scan backlogs is to rank findings by real risk and fix them at the base image instead of CVE by CVE. A mature container vulnerability management program uses these signals:
- ✓Is the image running? Thousands of stored digests are never deployed. Match registry digests against cluster inventory first.
- ✓Is the package loaded? A vulnerable library that is installed but never executed carries far less risk than one in the active process.
- ✓Is it exploitable? Use CISA KEV listings and EPSS scores alongside CVSS.
- ✓Is it exposed? Weigh internet-facing services and workloads with privileged identities or access to sensitive data first.
- ✓Is a fix available? Fixable findings are actionable today. No-fix findings go to the exception process.
- ✓Is it inherited? If 40 services share a
node:20-bookwormbase image, one base image bump fixes all 40.
The remediation loop
- Detect: The registry rescan flags a new critical, such as an OpenSSL CVE in a base layer.
- Triage: Map the affected digests to running workloads and check exposure.
- Rebuild: Update the base image, ideally through automated PRs from Renovate or Dependabot, and rebuild dependent images.
- Verify: Rescan the new digest and confirm the finding is gone rather than suppressed.
- Redeploy: Roll out the new digest, then retire or expire the old one with registry lifecycle policies.
As a worked example, a team might start with 2,300 findings across 180 stored images. Filtering to the 35 digests actually deployed, then to fixable criticals and highs in internet-facing services, can leave a few dozen findings. Most of those trace back to two or three shared base images. Minimal bases such as distroless or Alpine-based images shrink the starting count further, because fewer packages mean fewer CVEs to match.
How Upwind adds runtime context to registry scan results
Upwind takes registry and CI scan findings and adds the runtime evidence native scanners lack. Its lightweight eBPF sensor shows which images are actually running and which vulnerable packages are loaded and reachable. It is a container vulnerability scanner that ranks CVEs by real exposure across ECR, ACR, Artifact Registry, and Kubernetes workloads in one platform. Upwind holds a 4.8/5 rating from 88 reviews on Gartner Peer Insights as of October 2026. Teams that run only a few repositories and just need free native scan-on-push may find a full CNAPP more than they need.
- ✓Highlights the vulnerabilities that are loaded in memory and reachable at runtime.
- ✓Correlates findings with internet exposure, identities, and sensitive data access.
- ✓Uses its Agentic Pack AI agents to validate exposure and generate fixes.
- ✓Connects posture, vulnerability management, and cloud detection and response across clouds.
Conclusion
Container registry vulnerability scanning works when you configure it deliberately instead of leaving it on defaults. Turn on scan-on-push and continuous or scheduled rescans in ECR, ACR, Artifact Registry, or Harbor, and fill coverage gaps with Trivy or Grype. Track every image by digest, sign it, and attach an SBOM. Enforce severity thresholds through admission control, with exceptions that expire. Prioritise by what is running, loaded, exposed, and fixable, and remediate at the base image so a single rebuild clears findings across many services.
FAQ
What is container registry vulnerability scanning?
Container registry vulnerability scanning checks images stored in registries such as Amazon ECR, Azure Container Registry, Google Artifact Registry, and Harbor against known CVE data. It typically scans images when they are pushed and, depending on the registry, may continue rescanning them later as new vulnerabilities are published.
Why should scan results be tracked by image digest instead of tag?
Tags such as latest or 1.4 are mutable and can point to different images over time, while digests are immutable content hashes. Tracking findings, policy decisions, and deployments by digest is the only reliable way to know that the scanned image is the same one actually deployed.
Do ECR, ACR, Artifact Registry, and Harbor all support rescanning?
Yes, but they do it differently. ECR supports continuous rescanning with enhanced scanning through Amazon Inspector, ACR rescans recently used images through Microsoft Defender for Containers, Artifact Registry continues analysing recently pushed or pulled images, and Harbor relies on scheduled rescans such as Scan All.
Why do different container scanners report different vulnerabilities for the same image?
Scanners can disagree because they use different vulnerability data sources, package detection methods, and severity rules. Differences are especially common with distro backports, unfixed CVEs, copied binaries that are not in package databases, and multi-architecture images that contain different manifests per platform.
Is registry scanning enough on its own to secure container images?
No. The article recommends using registry scanning as one stage in a wider chain that includes CI scanning, signing and SBOM attestations, admission control at deploy time, and runtime detection. Registry scanning shows what is vulnerable in stored images, but not whether the image is running, exposed, or actively loading the vulnerable package.