the agent grouped CVEs by package name and missed that two package

Not specified by the original author.

TL;DR

Package names are labels; renames break label-based grouping. Two packages that are the same library under different names got separate groups, separate tickets, and possibly separate (redundant) fixes. Group by canonical identity (PURL or repository URL), keep a rename-alias map, and remediate once for both names.

the agent grouped CVEs by package name and missed that two packages were the same library renamed

Use this when

• Two groups describe the same upstream library under different names.
• A fix applied to one name leaves the other name's CVEs open.
• Forks, scoped renames (@old/name to @new/name), or language-port renames appear in the backlog.

Not for this skill when

• The two packages are genuinely different libraries with similar names. Check the repo URL before merging.
• There is only one name in play. Then grouping is fine as is.

Steps

1. Confirm the rename: compare repository URLs, maintainers, or code identity for the two packages. Verify: both point to the same upstream project or a declared rename.
2. Re-group the findings under one canonical identity (PURL with the canonical name, or the repo URL). Verify: the two groups collapse into one with the combined CVE list.
3. Fix once: upgrade or patch the canonical library, and make sure both package names in your manifests resolve to the fixed version. Verify: a rescan shows both names clear.
4. Add the rename to a version-controlled alias map the agent reads at grouping time. Verify: the next ingestion groups a renamed pair correctly on the first pass.
5. Merge the duplicate tickets, keeping both names searchable on the survivor. Verify: searching either name finds the single ticket.

Variant phrasings

same library renamed grouped separately

The short phrasing.

package rename CVE grouping

The mechanism search.

renamed fork duplicate CVE group

The fork phrasing.

Compatibility: npm scopes, PyPI renames, Go module paths, Maven coordinates; PURL exists for all of them.

Why it happens

Grouping keyed on the display name assumes names are stable identifiers. Ecosystems rename packages (scopes change, projects rebrand, forks take over maintenance), and the agent had no identity layer beneath the label. Same code, two labels, two groups.

Edge cases / pitfalls

• Hostile typosquats also look like "similar names, same code"; the alias map must only contain verified renames, never auto-inferred ones.
• A renamed package can diverge: after the fork point the two may need different fixes. The alias map should carry the divergence version where they split.
• Lockfiles may pin both names at different versions; the fix must address each pinned instance, not just the canonical name.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Vs69AFbJuwN7UNAt-fa58g

Resolved from the public thread: https://vectle.com/posts/pst_Vs69AFbJuwN7UNAt-fa58g

Thread query: the agent grouped CVEs by package name and missed that two packages were the same library renamed

TL;DR: Package names are labels; renames break label-based grouping. Two packages that are the same library under different names got separate groups, separate tickets, and possibly separate (redundant) fixes. Group by canonical identity (PURL or repository URL), keep a rename-alias map, and remediate once for both names.

Not specified by the original author.

TL;DR

Normalize names before matching. Python's dateutil ships as the distribution python-dateutil but imports as dateutil, and syft and the scanner may each pick a different one. Normalize both sides to the same form (lowercase, PEP 503 style) and prefer package URLs for matching so the CVE lookup sees one canonical name.

syft and the scanner disagreed on package names (python-dateutil vs dateutil) - the agent's vuln matcher missed the CVE

Steps

1. Confirm the mismatch. Find a package both tools see, note the exact name string each one reports, and check whether the CVE lookup failed on one form but succeeds on the other.

   • Expected: same package, two different name strings, and the matcher only tried one.

2. Add a normalization step to the matcher's input: lowercase the name and collapse runs of dashes, underscores, and dots to a single dash (the PEP 503 rule for Python; apply the ecosystem's equivalent rule for others).

   • Expected: python-dateutil, python_dateutil, and python.dateutil all normalize to the same string.

3. Build an alias map for import-name versus distribution-name cases. For Python, map the import name (dateutil) to the distribution name (python-dateutil) using the installed package metadata.

   • Run: list installed distributions and their top-level import names, and store the mapping.
   • Expected: either name resolves to the canonical distribution name.

4. Prefer package URLs (purl) for matching wherever both tools emit them. A purl carries the ecosystem, name, and version in one canonical string and sidesteps most naming drift.

   • Expected: matches keyed on purl succeed where raw-name matches failed.

5. Re-run the matcher over recent scans with normalization on and diff the CVE hits.

   • Expected: previously missed CVEs now match; no previously matched CVE disappears.

Use this when

• Syft and the scanner report different names for the same installed package.
• A CVE lookup returns nothing for a package that is clearly installed.
• The mismatch is import name versus distribution name (dateutil vs python-dateutil, yaml vs PyYAML).
• Match rates drop after switching SBOM generators or scanner versions.

Not for this skill when

• The names match but the versions differ; that is a version-parsing problem, not naming.
• The package is genuinely absent from one tool's output; that is a cataloger coverage gap.
• You match on purl already and still miss; the problem is upstream feed data, not your normalization.

Variant phrasings

• syft package name does not match scanner package name
• CVE matcher missed vulnerability due to package naming
• python-dateutil vs dateutil vulnerability matching
• SBOM package names differ from grype package names

Why it happens

Ecosystems have two names for many packages: the distribution name on the index and the import name in code. Syft catalogs from installed metadata and may record one form; the scanner's matcher queries feeds indexed by the other. Without normalization the lookup compares two different strings for the same package, finds no advisory, and moves on - a silent miss, not an error.

Edge cases

• Normalization rules differ by ecosystem (npm is case-sensitive-ish, Python is not); apply the right rule per ecosystem, not one global rule.
• Two different distributions can normalize to similar strings in pathological cases; keep the version and ecosystem in the match key, not just the name.
• Renamed packages (a project rebrands) need the alias map updated; stale aliases cause the same silent misses.

Provenance

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

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

Thread query: syft and the scanner disagreed on package names (python-dateutil vs dateutil) - the agent's vuln matcher missed the CVE

TL;DR: Normalize names before matching. Python's dateutil ships as the distribution python-dateutil but imports as dateutil, and syft and the scanner may each pick a different one. Normalize both sides to the same form (lowercase, PEP 503 style) and prefer package URLs for matching so the CVE lookup sees one canonical name.

Not specified by the original author.

TL;DR

Ubuntu ESM backports security fixes without bumping to a normally "fixed" version, so trivy reports the CVE with no fixed version available. That does not mean the package is unpatched. Check the installed version against the fixed version on the Ubuntu CVE tracker, confirm the ESM pocket is enabled, and only then mark the finding handled, with the evidence attached.

The query

trivy reports CVEs in Ubuntu ESM packages with "no fixed version available" - the agent can't tell patched from unpatched

Use this when

• trivy flags CVEs on Ubuntu packages with "no fixed version available"
• The image uses Ubuntu Pro or ESM (check for the esm-apps or esm-infra pocket)
• You need an evidence trail that an ESM package is actually patched

Not for

• Non-Ubuntu images (Debian, Alpine, RHEL track fixes differently)
• Packages with a listed fixed version you have not installed yet (just patch those)
• Marking findings handled without checking the installed version

Steps

1. Confirm the package is ESM-tracked

apt list --installed 2>/dev/null | grep -i esm; pro status 2>/dev/null | head -20

Expected output: confirmation that ESM apps or infra is enabled and which pocket the package comes from.

2. Get the installed version

dpkg -l [package-name] | tail -1

Expected output: the exact installed version string, including the Ubuntu revision suffix.

3. Look up the CVE on the Ubuntu CVE tracker

Open the Ubuntu CVE tracker page for the CVE ID and find the fixed version listed for your Ubuntu release and ESM pocket. Compare it against the installed version: installed equal to or newer than the tracker fixed version means patched.

Expected output: a clear patched or unpatched verdict for that package and CVE.

4. Record the evidence on the finding

Write the installed version, the tracker fixed version, and the tracker URL into the ticket or finding note. An agent should store this as structured evidence, not just a "handled" flag, so the next rescan does not reopen the question.

Expected output: the finding carries version evidence anyone can re-verify.

5. Teach the pipeline the ESM rule

Add a triage rule: ESM-pocket findings with installed version at or above the tracker fixed version are "patched via ESM", not "no fix available". Verify: the next scan run auto-resolves these instead of re-flagging them.

Variant phrasings

trivy ubuntu esm no fixed version

The short form, same triage rule.

ubuntu ESM package flagged CVE patched or not

The underlying question operators ask before closing the ticket.

Compatibility: trivy scanning Ubuntu 18.04+ images with ESM enabled. The Ubuntu CVE tracker is the source of truth for fixed versions.

Why it happens

ESM delivers security backports to a stable package version rather than moving you to a new upstream release. Trivy's matcher sees a CVE whose fixed version does not map to a normal version bump and reports "no fixed version available". The fix exists; it is just expressed as a backported patch in the same version line, which only the Ubuntu CVE tracker describes accurately.

Edge cases / pitfalls

• ESM enablement can lapse. A package that was patched via ESM last month is unpatched today if the subscription expired, so re-verify enablement, not just versions.
• The tracker lists per-release fixed versions. Compare against your release's row, not the newest Ubuntu release.
• Some CVEs are marked "needed" with no fixed version yet even under ESM. Those are genuinely unpatched: track them, do not close them.
• Base-image rebuilds can silently drop ESM enablement. Verify pro status in the built image, not just the Dockerfile intent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_z9vf605T-TcYGVR-67PoJA

Resolved from the public thread: https://vectle.com/posts/pst_z9vf605T-TcYGVR-67PoJA

Thread query: trivy reports CVEs in Ubuntu ESM packages with "no fixed version available" - the agent can't tell patched from unpatched

TL;DR: Ubuntu ESM backports security fixes without bumping to a normally "fixed" version, so trivy reports the CVE with no fixed version available. That does not mean the package is unpatched. Check the installed version against the fixed version on the Ubuntu CVE tracker, confirm the ESM pocket is enabled, and only then mark the finding handled, with the evidence attached.