trivy and grype report the same OpenSSL CVE under different identifiers

Not specified by the original author.

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.
2. Dedupe on normalized CVE plus package before opening tickets. Expected: the OpenSSL finding produces one ticket regardless of which scanner reported it first.
3. 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.
4. 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

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

Thread query: trivy and grype report the same OpenSSL CVE under different identifiers - the agent opened two tickets and nobody noticed for a month

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.

Not specified by the original author.

container image scanning in the build pipeline

TL;DR

Scan every image you build before it ships: add Trivy or Grype to CI, fail the build on critical (and high, once you are clean) CVEs, and fix findings by upgrading the base image or the package, not by ignoring them. Pair scanning with slim base images and regular rebuilds, because a scanned-once image rots the day after it is built.

container image scanning in the build pipeline

Use this when

• You need to add image scanning to a build pipeline
• A scan flags CVEs in your base image or app dependencies
• You are standardizing how the team builds containers
• Compliance asks for vulnerability scanning evidence on images

Not for this skill when

• You need runtime protection (different layer, different tools)
• The question is Kubernetes admission control
• You only want smaller images for speed (thats optimization, not security)

Steps

1. Scan your current images and see the baseline

Run the scanner locally first to see the baseline; expect noise on the first run, not zero findings on day one.

trivy image [registry]/[image]:[tag]

Expected: a table of CVEs by severity per layer and package. Note which findings are in the OS layer (fix by changing the base image) vs your app dependencies (fix by upgrading the package). Grype works the same way: grype [registry]/[image]:[tag].

2. Add the scan as a CI step that can fail the build

Put the scan after the image build and before the push to the registry. Start by failing only on critical severity; once the backlog is clean, add high.

trivy image --exit-code 1 --severity CRITICAL [registry]/[image]:[tag]

Expected: exit code 1 when a critical CVE is present, which fails the CI job. Keep an allowlist file for CVEs you have triaged as not applicable, with an expiry date on each entry so allowlists dont become permanent.

3. Fix findings at the right layer

OS-package CVEs get fixed by bumping or slimming the base image; app-dependency CVEs by upgrading the package and rebuilding.

grep -i "^FROM" Dockerfile

Expected: your base image lines. Prefer minimal bases (distroless, alpine-based official images, or your distro's minimal variant) and pin the digest, not just the tag, so rebuilds are reproducible.

4. Rebuild regularly, not just on code changes

Base images get security updates constantly; an image built six months ago carries six months of CVEs no matter how clean it was at build time. Schedule weekly rebuilds of your base images even when app code hasnt changed.

printf 'base-image rebuild: weekly, [day]\nowner: [team or name]\n' | tee -a image-maintenance.txt

Expected: a documented rebuild cadence with an owner. CI rebuilds the image from the pinned Dockerfile, rescans, and pushes only if the scan passes.

5. Scan before push and keep the evidence

Make the registry the enforcement point too: only scanned-clean images get pushed to the production repository. Save scan reports as CI artifacts so audits and incident response can see exactly what shipped.

trivy image --format json --output scan-report.json [registry]/[image]:[tag] && ls -la scan-report.json

Expected: a JSON report artifact attached to the CI run. When a CVE drops next month, you grep the saved reports to answer "which of our images are affected" in minutes.

Variant: trivy vs grype which to use

Both are good and free. Trivy covers more (misconfigurations, secrets, licenses) in one binary; Grype pairs naturally with Syft SBOMs. Pick one, standardize, and move on; the scanner you actually run beats the theoretically better one.

Variant: too many vulnerabilities in base image

Switch to a slimmer base first (most findings live in packages your app never uses), then pin the digest, then set up the weekly rebuild. If the official image is still noisy, check whether your distro publishes a minimal or hardened variant.

Variant: scan docker image before docker hub push

The pre-push hook version: run the scan locally with --exit-code 1 before docker push, or better, push only from CI where the scan is mandatory. Humans forget; pipelines dont.

Why this happens

Images bundle an entire OS userland plus your app, and every package in there is a CVE waiting to be disclosed. Nobody reads the full package list of a base image, so vulnerabilities accumulate invisibly until someone scans. Scanning in the pipeline turns "we think our images are fine" into a checked fact on every build.

Edge cases and pitfalls

• Scanner database lag: fresh CVEs take hours to appear in scanner DBs; a clean scan is "clean as of the last DB update," not a guarantee.
• Unfixable OS CVEs: some findings have no fixed version yet; allowlist with expiry and revisit, dont just suppress forever.
• Distroless debugging: minimal images have no shell, which complicates debugging; keep a debug-tag variant with busybox for incidents.
• Multi-arch images: scan every architecture you ship; CVEs can differ between amd64 and arm64 builds.
• Secrets in layers: scanners flag leaked secrets too; a secret in an old layer is still in the image even if a later layer deletes the file.
• Scan time on huge images: multi-GB images make CI slow; slimming the image fixes both the CVE count and the pipeline speed.

Provenance

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

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

Thread query: container image scanning in the build pipeline

TL;DR: Scan every image you build before it ships: add Trivy or Grype to CI, fail the build on critical (and high, once you are clean) CVEs, and fix findings by upgrading the base image or the package, not by ignoring them. Pair scanning with slim base images and regular rebuilds, because a scanned-once image rots the day after it is built.

Not specified by the original author.

TL;DR

GHSA-xxxx and CVE-2024-xxxxx are often the same bug wearing two IDs. Deduping each ID space separately guarantees double triage. Resolve aliases at ingestion (OSV and the GitHub Advisory Database both publish them), key findings on the canonical CVE when one exists, and merge the duplicates you already created.

the agent deduped GHSA IDs and CVE IDs separately and triaged the same bug twice

Use this when

• Two tickets describe the same package, same versions, same bug, under different IDs.
• Findings from GitHub Dependabot alerts (GHSA) and scanners (CVE) never collapse together.
• The backlog has pairs that an analyst keeps closing as duplicates by hand.

Not for this skill when

• The two IDs are genuinely different vulnerabilities in the same package. Check the description before merging.
• You only ingest one ID space. Then there is nothing to dedupe across.

Steps

1. Merge the existing duplicates: pick the CVE ID as the surviving ticket, link the GHSA ticket as a duplicate, and carry over the triage state. Verify: one ticket remains with both IDs recorded.
2. At ingestion, resolve aliases: query the OSV API or the GitHub Advisory Database for each GHSA and record its CVE aliases (and vice versa). Verify: a known GHSA/CVE pair resolves to a single canonical key.
3. Key findings on the canonical ID: CVE when the alias set includes one, otherwise the GHSA. Verify: ingest the same bug via both feeds and get one finding.
4. Handle withdrawn or changed aliases: re-resolve periodically, because alias sets do change. Verify: a changed alias updates the mapping instead of forking a new ticket.
5. Add a regression test with known alias pairs so a future pipeline change cannot reintroduce separate dedup. Verify: the test fails if dedup is keyed on raw IDs.

Variant phrasings

GHSA CVE dedup duplicate

The short phrasing.

same bug triaged twice GHSA CVE

The symptom search.

advisory alias dedup

The mechanism phrasing.

Compatibility: OSV API, GitHub Advisory Database GraphQL/REST, and NVD's references; all publish alias mappings.

Why it happens

Each feed speaks its native ID, and the dedup was written per-feed instead of per-vulnerability. The pipeline treated "ID" as identity, but in vulnerability data the ID is just a label; the alias graph is the identity. Two labels, one bug, two tickets.

Edge cases / pitfalls

• Some advisories have no CVE (yet); do not force a CVE key where none exists, or unrelated GHSA-only findings will collide.
• Alias data can lag: a brand-new GHSA may not yet map to its CVE. Re-resolve on a delay rather than assuming no alias means no relation.
• When merging, keep both IDs searchable on the surviving ticket; the security team will search by whichever ID they saw first.

Provenance

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

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

Thread query: the agent deduped GHSA IDs and CVE IDs separately and triaged the same bug twice

TL;DR: GHSA-xxxx and CVE-2024-xxxxx are often the same bug wearing two IDs. Deduping each ID space separately guarantees double triage. Resolve aliases at ingestion (OSV and the GitHub Advisory Database both publish them), key findings on the canonical CVE when one exists, and merge the duplicates you already created.