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

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.