trivy and grype report the same OpenSSL CVE under different identifiers - the agent opened two tickets and nobody...

Trivy and grype reported the same CVE under different identifiers

TL;DR

Normalize every scanner's identifiers to canonical CVE IDs through an alias table before ticketing, then dedupe on CVE plus package. Trivy reports CVE IDs while grype can surface distro or vendor advisory IDs for the same bug (common with OpenSSL), so raw identifier strings never match across scanners. Normalization makes the two scanners agree on one ticket, and a weekly cross-scanner reconciliation catches the next mismatch in days instead of a month.

The failure

two tickets open for one month for the same OpenSSL CVE
(trivy filed under the CVE ID, grype filed under a distro advisory ID, no normalization)

Steps

1. Map each finding's identifiers to canonical CVE IDs at ingest. Grype's "related vulnerabilities" field usually carries the CVE behind a distro advisory ID. Expected: both the trivy and grype findings resolve to the same CVE ID.

1. Dedupe on normalized CVE plus package before opening tickets. Expected: the OpenSSL finding produces one ticket regardless of which scanner reported it first.

1. Merge the existing duplicates: find open ticket pairs on the same package whose normalized CVEs match, and close one as a duplicate of the other. Expected: the month-old double ticket collapses.

1. Add a weekly cross-scanner reconciliation report that flags same-package findings with different raw identifiers. Expected: the next identifier mismatch surfaces within a week, not a month.

Use this when

• two scanners file separate tickets for the same vulnerability
• the same package shows different CVE counts per scanner
• grype findings carry distro or vendor IDs instead of CVE IDs
• ticket volume exceeds the real vulnerability count

Not for this skill when

• the scanners genuinely disagree on whether the CVE applies (that is a matcher dispute, investigate it)
• both scanners already report canonical CVE IDs and still duplicate (check your dedup key instead)
• the duplicate tickets are for different packages (those are separate findings)
• you only run one scanner (nothing to reconcile)

Variant phrasings

• trivy grype same vulnerability different ID duplicate tickets
• scanner identifier mismatch duplicate CVE tickets
• reconcile trivy and grype findings same CVE

Why it happens

Scanners do not speak the same identifier language. Trivy leans on CVE IDs, while grype matches against distro security trackers and reports the distro's advisory ID, which only sometimes equals the CVE. Your ticketing pipeline keyed on the raw identifier string, so "CVE-2024-XXXX" and "DLA-YYYY" looked like two different vulnerabilities even though they describe the same OpenSSL bug. Identifier normalization is the translation layer the pipeline was missing: every scanner's native IDs get mapped to CVE IDs once, at ingest, and everything downstream works in one language.

Edge cases

• Some distro advisories cover multiple CVEs or a CVE spans multiple advisories. The alias table must handle one-to-many mappings, not just one-to-one.
• A finding with no mappable CVE (embargoed or brand-new distro advisory) should still file, tagged as unmapped, rather than being dropped by the normalizer.
• Scanner upgrades can change which identifier they prefer. Re-run the reconciliation report after every scanner version bump.
• Do not merge tickets across scanners when the affected versions differ. Same CVE, different version ranges can be genuinely separate remediation tasks.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst3f3i1HZI9EI-zcpbxgmiw