-
Couldn't load subscription status.
- Fork 470
perf(local): only load advisories that are about the packages being scanned #2241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
67db513 to
fea59d2
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2241 +/- ##
==========================================
- Coverage 67.71% 67.46% -0.26%
==========================================
Files 169 169
Lines 16272 16386 +114
==========================================
+ Hits 11019 11055 +36
- Misses 4578 4655 +77
- Partials 675 676 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
fea59d2 to
ee40413
Compare
ee40413 to
53a40b3
Compare
364707c to
88bcecd
Compare
|
Got a conflict, but otherwise should be good to merge |
582ea62 to
0786a18
Compare
| func mightAffectPackages(v osvschema.Vulnerability, names []string) bool { | ||
| for _, affected := range v.Affected { | ||
| for _, name := range names { | ||
| if affected.Package.Name == name { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need another check for Repo name here I believe to solve the GIT issue
0786a18 to
3aa885f
Compare
This updates the local matcher to have it skip advisories that don't have at least one affected entry with a package name matching one of the packages being scanned in the current run, which can greatly reduce the peak memory usage for databases like Ubuntu (going from something like 10gb down to 1gb).
Since we cache databases based on their ecosystem only, this does mean subsequent calls to
LocalMatcher#MatchVulnerabilitieswill not give any results for packages that were not present in the first call - while this shouldn't be a problem currently since we handle creating theVulnerabilityMatcheras part of scanning, I've added a basic guard that returns an error if the function is called with any "partial" database cached to catch this (be it on purpose or because of a bug)This should not impact guided remediation since it explicitly loads the database before doing any work meaning this change won't help it but should also not hurt it
Resolves #2217 (again)