Repository navigation
Pair advisory labels to the CVE grype reports them as - #719
Merged
Merged
Conversation
- label format 1.0.1 adds an optional `aliases` on a label whose vulnerability is an advisory (ELSA, ALAS2, ...): the ids grype may report that advisory's match under instead, i.e. the CVE `--by-cve` normalizes it to - an advisory label now also pairs a match reported under exactly one of its aliases, and decides it as it would its own; it still never joins an alias group or pairs another advisory naming the same CVE - the year filter keeps an advisory label when its id or any alias is in range, so it stays with the CVE match it pairs - `claims validate` and the writer refuse aliases on a non-advisory label or naming a non-disclosure id; a relabel that names no aliases keeps the prior ones - `schema-1.0.1.json` sits beside 1.0.0 Without this, every advisory label in the corpus is unpaired under grype's quality gate config (`by-cve: true`), so regressions on Oracle and Amazon images land as undecided and pass. Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
When a more specific fp label (e.g. a subject label over a global one) decides a match, the tp label it overrode still counted as a satisfied recall unit, so the same match was an fp and a recall hit at once. A candidate adding that match could raise its F1 and pass `f1NotWorse`. - a match a label or hypothesis calls fp no longer satisfies a tp label, and a tp label whose every paired match is called fp is no unit at all - applies to the per-subject checks and to the per-gate expectations Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
`claims validate` already refuses a file with two labels on one package and vulnerability, but `score` silently took the last one, so the verdict depended on label order in the file. Reading such a file now fails with the file and key named. Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
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.
Advisory labels (ELSA, ALAS, ...) never paired with grype's
--by-cveoutput, since grype reports those matches under a CVE and pairing only took the exact advisory id. On images whose labels are mostly advisories (oraclelinux:6,amazonlinux:2) the gates couldn't fail: a dropped TP or added FP just landed as undecided.aliases, the CVE(s) grype reports it as. An advisory label then also pairs a match reported under an alias, and the year filter considers aliases. Only advisory labels may carry aliases, and only CVE/GHSA-style idstplabel overridden by a more specificfplabel for the same match was still counted as a satisfied recall unit, so one match was both an FP and a recall hit (an added FP could raise F1)scorenow refuses a claims file listing the same package+vulnerability twice instead of silently taking the last one (claims validatealready rejected it)Labels to go with this are in anchore/claims#5