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.

```text
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