the scanner reported 2,300 new findings overnight after a base-image bump - the agent couldn't tell which were real

TL;DR: Almost none of those 2,300 are new - the base-image bump changed package version strings, so the dedup keys stopped matching and every old finding re-filed as new. Re-scan the old image digest, diff by CVE plus package identity, and triage only the true-new set.

the scanner reported 2,300 new findings overnight after a base-image bump - the agent couldn't tell which were real

Steps

1. Pin both sides by digest, not tag: record the old image digest (pre-bump) and the new digest. Expected: two immutable scan targets - tags move, digests do not.

2. Scan both digests with the same scanner version and the same vulnerability database. Expected: two finding lists computed under identical conditions.

3. Diff the lists on (CVE ID, package purl, installed version): findings present in both are carryover, findings only in the new scan are genuinely new. Expected: the "2,300 new" collapses to a small true-new set plus a large re-flagged set.

4. Bulk-close or bulk-carry the re-flagged findings back onto their original tickets, matching on the old CVE-plus-package key. Expected: the backlog returns to roughly its pre-bump size plus the true-new items.

5. Triage only the true-new set, prioritized by severity and KEV membership. Expected: the on-call reviews dozens of findings, not thousands.

6. Fix the pipeline: key findings on digest-pinned scans and stable package identity so the next base-image bump diffs instead of flooding. Expected: the next bump produces a diff report, not an alert storm.

Use this when

• Finding counts spike right after a base-image, distro, or major dependency bump
• The "new" findings carry CVE IDs you have seen before
• Dedup keys include version strings or tags that the bump changed
• Triage is blocked because nobody trusts the "new" label

Not for this skill when

• The findings are genuinely new (new CVE IDs, first-seen dates check out) - triage them normally
• Counts spike with no image or dependency change - look for a scanner or database update instead
• A single image shows 2,300 findings on its first-ever scan - that is a dirty base image, not a dedup problem

Variant phrasings

• trivy thousands of new vulnerabilities after base image update
• scanner re-reported all CVEs as new after image rebuild
• how to diff container scan results between image digests

Why it happens

Dedup keys are usually built from CVE ID plus package name plus version string plus image tag. A base-image bump changes the version strings (new distro package builds) and often the tag, so every key changes and every old finding looks new. The scanner did its job - it reported what it saw. The pipeline's identity function just could not recognize anything it had seen before.

Edge cases

• Some "re-flagged" findings genuinely changed severity (a new exploit published overnight) - re-score the carryover set, do not just bulk-close it.
• Distro package versioning (epochs, release suffixes) defeats naive string diffing - normalize with purls before diffing.
• If the old digest is no longer pullable, diff against your last stored SBOM for that digest instead of rescanning.

Provenance

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

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

Thread query: the scanner reported 2,300 new findings overnight after a base-image bump - the agent couldn't tell which were real

TL;DR: