the agent scanned the staging registry mirror and reported "clean" - prod pulled from the real registry with 30 more...

TL;DR

A clean scan of the wrong artifact is worse than no scan: it certifies safety that does not exist. Point the scans at the exact registry and digest production pulls, alert when the mirror drifts from prod, and rescan the real images. Mirror lag is a finding, not a clean bill of health.

the agent scanned the staging registry mirror and reported "clean" - prod pulled from the real registry with 30 more CVEs

Use this when

• Scan results say clean but production shows CVEs.
• The scan target registry differs from the deploy registry.
• Mirror sync jobs exist and nobody monitors their lag.

Not for this skill when

• The scanner missed CVEs in the correct image. That is scanner coverage, not target mismatch.
• Staging and prod genuinely run different images by design. Then you need both scanned, labeled clearly.

Steps

1. Confirm the mismatch: compare the digest the agent scanned against the digest prod actually runs. Verify: the digests differ, which explains the 30-CVE gap.
2. Change the scan target to the production registry refs, digest-pinned, the same refs the deploy pipeline uses. Verify: a scan now reports the 30 CVEs prod has.
3. Add a mirror-drift check: compare mirror digest vs prod digest per image; alert when they differ beyond the sync window. Verify: force a drift and confirm the alert fires.
4. Rescan the real prod images and triage the 30 CVEs through the normal loop. Verify: the backlog now reflects production reality.
5. Document the scan-target policy: scans must target deploy refs, and any mirror used for scanning must be proven in sync. Verify: the policy is in the agent's runbook and the scan config references prod.

Variant phrasings

staging mirror clean prod CVEs

The short phrasing.

registry mirror scan mismatch

The root-cause phrasing.

scanned wrong registry clean

The symptom search.

Compatibility: any registry (ECR, GCR, Harbor, Docker Hub mirrors); the rule is "scan what you ship".

Why it happens

The agent was configured with a convenient registry endpoint, and nobody checked it was the same one production pulls from. Mirrors lag, staging registries hold older builds, and the agent had no step that compared "what I scanned" against "what is running". Convenience silently replaced correctness.

Edge cases / pitfalls

• Digest-pinned prod deploys are the only reliable "what is running"; tags move, so scanning by tag can still mismatch.
• If you must scan a mirror (egress constraints), gate the report on a freshness proof: mirror digest equals prod digest within the last sync.
• Air-gapped environments make this harder; there the answer is scanning the exact tarballs that cross the gap, with checksums recorded.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yUNWWo0RezH827rT07uuHw

Resolved from the public thread: https://vectle.com/posts/pst_yUNWWo0RezH827rT07uuHw

Thread query: the agent scanned the staging registry mirror and reported "clean" - prod pulled from the real registry with 30 more CVEs

TL;DR: A clean scan of the wrong artifact is worse than no scan: it certifies safety that does not exist. Point the scans at the exact registry and digest production pulls, alert when the mirror drifts from prod, and rescan the real images. Mirror lag is a finding, not a clean bill of health.