Optionally orient results by CVE #1020
Merged
Conversation
This file contains 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
wagoodman
changed the title
wagoodman
force-pushed
the
orient-by-cve
branch
2 times, most recently
from
97dcf9b
to
27bd193
Compare
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
wagoodman
force-pushed
the
orient-by-cve
branch
from
27bd193
to
c428d99
Compare
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
wagoodman
force-pushed
the
orient-by-cve
branch
from
3699395
to
6ca32ae
Compare
kzantow
approved these changes
Dec 2, 2022
| @@ -167,6 +169,11 @@ func setRootFlags(flags *pflag.FlagSet) { | |||
| "ignore matches for vulnerabilities that are fixed", | |||
| ) | |||
|
|
|||
| flags.BoolP( | |||
| "by-cve", "", false, | |||
There was a problem hiding this comment.
nit: by-cve to me, at least, is not the most clear... maybe something like --cve-first, --orient-by-cve, or --group-by-cve?
There was a problem hiding this comment.
Yea I can see how a user could conflate it. I also agree none of the current options standout as a clear winner. I like that --by-cve does not show GHSA. That feels right. The inverse --by-ghsa would not show CVE.
I also ran it locally and it feels right for now, but might be biased since it was the first one I read.
I say ship, and if er end up hating it we can change up the ergonomics if it still feels bad.
Keith also had a good point of eventually making this the default.
|
Waiting for checks then will merge |
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
spiffcs
added a commit
that referenced
this pull request
Dec 13, 2022
* main: chore: add GitLab Community Edition image to quality gate (#1035) Update Syft to v0.63.0 (#1037) fix: Exclude binary packages that have overlap by file ownership relationship (#1024) docs: update quality gate docs (#1032) Optionally orient results by CVE (#1020) Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
|
@wagoodman thanks for this feature, I tried to run this on an elasticsearch image and don't see CVE IDs where CVE IDs look available. See output below and example: |
|
@anandgia is there a specific image to use to reproduce this? |
|
Yes @kzantow i put the image in the above description docker.elastic.co/elasticsearch/elasticsearch:6.8.23 |
|
I confirm the observation by @anandgia (and additionally notice Is there anything I can do to help debug this? Perhaps opening a dedicated issue for issues around |
|
@JipSogeti I created a new issue for the performance concern: #1185 |
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.
This PR introduces a new
--by-cveoption which will orient all results by CVE. For instance, if there is a GHSA that was directly matched on, then the results will instead show the equivalent CVE in the results in its place. If that CVE result was already being shown in the results, then the match details from the GHSA result will be appended to the existing result -- in this way there is always a record of how the CVE match was made (by GHSA).Additionally the JSON results are also re-oriented around CVEs. For example, before this PR a GHSA result would be shown similar to such:
After this change:
The specific changes made:
--by-cveoptionvulnerabilityIDattribute under thematch.Detail.Foundmap, since the vulnerability record shown may no longer match what was actually matched on during the search.grype.VulnerabiliyMatcherobject. This encapsulates much of the logic incmdinto something that is accessible in the API, allowing users to correctly apply ignore rules and evaluate severity thresholds without having to implement this themselves.Closes #204