If you've pushed an image and seen a notification or log line that says new tag scanned, it means the registry's built-in scanner just finished analyzing that specific tag against a vulnerability database and posted the results back to you, usually within a few minutes of the push completing. It's an event, not a product — the phrase shows up in GitHub's audit log, in Amazon ECR's EventBridge notifications, and in equivalent Docker Hub and GitLab container registry hooks, and in each case it marks the same underlying action: a tag arrived, and a scan ran against it automatically.
What triggers a "new tag scanned" event?
The event fires the moment a registry's scan-on-push setting is enabled and a docker push (or equivalent CI step) completes for a repository under that policy. On the github container registry (GHCR), this is tied to GitHub's code scanning integration — pushing an image with a new tag triggers Dependabot-style vulnerability scanning against the image's OS packages and, where supported, application dependencies. Amazon ECR calls the equivalent feature "enhanced scanning" (built on Amazon Inspector) or basic scanning (built on Clair), and both re-scan on push by default if you've turned the setting on for the repository. The important detail: it's the tag that's scanned, not the repository as a whole, so pushing myapp:v1.2.4 generates its own independent scan even if myapp:v1.2.3 was clean yesterday.
What does the scan actually check?
Most registry-native scanners work from the image's manifest and layers, extracting an inventory of installed OS packages (via APT, APK, or RPM metadata baked into the layers) and, for some scanners, language-level manifests like package-lock.json or a Python requirements.txt if they were copied into the image. That inventory is matched against known-vulnerability feeds — the National Vulnerability Database, vendor advisories, and distro security trackers — to produce a list of CVEs by severity. This is fundamentally the same technique as software composition analysis, just scoped to what's inside a built container rather than a source repository's dependency tree, which is why registry scans and CI-stage SCA scans can report slightly different results for the same code: they're often reading from different manifests at different build stages.
Why does the same tag sometimes get rescanned later?
A registry that only scanned on push would miss the CVEs disclosed after the image was built, so most registries also run periodic rescans against their existing tag inventory using an updated vulnerability feed. This is why an image that scanned clean on Monday can show a new critical finding on Thursday, with no code change at all — the underlying package didn't change, but the vulnerability database did. Teams that only look at "new tag scanned" events and ignore rescan alerts end up with stale confidence in old, unpatched tags still sitting in production registries.
Should you rely on registry-native scanning alone?
Registry-native scanning is a reasonable free baseline, but it typically checks fewer sources, has shallower severity context, and rarely maps findings to exploitability or reachability. A registry scanner will tell you a base image has a critical glibc CVE; it generally won't tell you whether your application's code path ever calls the vulnerable function, which is the difference between a finding that needs an urgent patch and one that can wait for the next scheduled rebuild. Platforms built specifically for container and dependency scanning — including Safeguard's SCA and container scanning — layer reachability analysis, SBOM generation, and policy gating on top of the same underlying CVE data, so a "new tag scanned" alert becomes an actionable, prioritized finding instead of a raw CVE count. Pairing registry-native alerts with a dedicated scanner in your CI/CD pipeline, gated before merge rather than after push, closes the gap between "we know it's vulnerable" and "we fixed it before it shipped."
How should a team respond to a "new tag scanned" alert?
Treat it as a checkpoint, not a verdict: pull the finding list, filter to criticals and highs with a known fix version, and check whether the affected package is actually reachable from your application's entry points before triaging. If the tag is already deployed, cross-reference the finding against your running image digest (not just the tag name, since tags are mutable and can be overwritten) to confirm what's actually live. Teams running a real DevSecOps pipeline typically wire this alert into a Slack or ticketing integration so a human reviews new critical findings within a day, rather than letting scan results accumulate unread in a registry dashboard.
FAQ
Does "new tag scanned" mean my image is safe?
No — it means a scan completed, not that the image is clean. Check the actual finding count and severity attached to the event; a zero-findings scan is a much stronger signal than the event itself.
Why did I get a "new tag scanned" notification with no CVEs listed?
Some registries send the notification for every scan regardless of outcome, as an audit-trail record that the policy ran. Absence of listed CVEs in that specific notification usually means a clean result, but confirm in the registry's scan detail view rather than assuming from the notification text alone.
Can I disable scan-on-push and only scan on a schedule?
Yes, most registries let you configure scan frequency, but disabling scan-on-push means a vulnerable image can sit live in production for however long your schedule interval is before anyone's notified — most teams keep push-time scanning on and add scheduled rescans on top, not instead.
Is registry scanning the same as SAST or DAST?
No. Registry scanning is a form of software composition analysis focused on package inventories inside built images. It doesn't analyze your source code logic like SAST does, and it doesn't probe a running application like DAST does — the three are complementary, not interchangeable.