Repository navigation
fix(output): group vulnerabilities transitively regardless of order - #3114
Merged
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3114 +/- ##
==========================================
+ Coverage 82.09% 82.11% +0.02%
==========================================
Files 118 118
Lines 7658 7667 +9
==========================================
+ Hits 6287 6296 +9
Misses 1371 1371 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
G-Rath
marked this pull request as ready for review
September 29, 2026 00:19
another-rex
pushed a commit
that referenced
this pull request
Sep 29, 2026
#3116) This new test shows how our current grouping behaviour is wrong due to considering the `upstream` as an alias: each of these advisories should be in their own group as they only share an `upstream`, but our current logic results in the groups `{DSA-1543-1, DSA-1819-1, DTSA-132-1}` and `{DTSA-125-1}`. #3114 will improve this by making the grouping consistent, but we'll still incorrectly put all the advisories into a single group. Relates to #3107
Ly-Joey
approved these changes
Oct 12, 2026
Ly-Joey
left a comment
Ly-Joey
left a comment
Contributor
There was a problem hiding this comment.
LGTM!
Some minor nits to appease the lint gods (I'm surprised modernize lint isn't already flagging this)
Collaborator
Author
G-Rath
added a commit
that referenced
this pull request
Oct 12, 2026
G-Rath
added a commit
that referenced
this pull request
Oct 12, 2026
…re correct (#3138) Working on #1275 made me realize the output tests are just too artificial, which lead me down a bit of a rabbit hole to try and centralize how we build our groups so that it all lives in one place. Most of this is diff is just adding tests, with the two main changes otherwise being moving a bunch of stuff to `grouper.Build` and modifying the `output` tests to use `grouper.Build`. There's some follow-up changes I'll do like making `grouper.Group` private, but I'm going to wait until #3114 is landed to avoid nasty conflicts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently when grouping if a pair shares an identifier we only update the group of those two vulnerabilities, leaving any other vulnerabilities in the original group.
This means connected vulnerabilities can end up getting split across multiple groups depending on the order they're encountered, which is incorrect.
For example these should be all one group, but currently
GHSA-bbbbends up on its own:GHSA-aaaawith the aliasCVE-1GHSA-bbbbwith the aliasCVE-3GHSA-ccccwith the aliasesCVE-2andCVE-3GHSA-ddddwith the aliasesCVE-1andCVE-2To address this I've rewritten the pairwise comparison to use a union-find, so that connected vulnerabilities are always grouped together regardless of order.
Resolves #3107