docs: Clarify how suppress items are matched against files#8354
docs: Clarify how suppress items are matched against files#8354kwin wants to merge 1 commit intodependency-check:mainfrom
Conversation
|
|
||
| The latter three can optionally be given as regular expression. The `<packageUrl>` value is matched against the dependency | ||
| specific software identifiers (can be looked up from the report) and `<gav>` against these identifiers after they have been mapped | ||
| to coordinates via `PurlIdentifier.toGav()`. The latter is not always available while the former is mandatory. |
There was a problem hiding this comment.
Purls are not always available for dependencies, so it's not "mandatory", if that's what you were referring to?
Possibly also better to rephrase without using context-dependent latter/former, since it's a bit confusing given latter is also used a couple of lines above to refer to something different.
There was a problem hiding this comment.
In which cases are Purls not available? So only sha1 is available for all files?
There was a problem hiding this comment.
Purls have to be guessed/inferred for many analyzers as there is not always package metadata. E.g jars without POMs, arbitrary JavaScript files, dlls/assemblies, scanning inside packages or archives of one type which contain built artifacts of another vendored.within.
Especially when using the CLI/docker image to scan java projects.
Sometimes there just isn't sufficient metadata.
There was a problem hiding this comment.
Only hashes are always available, but it's usually a last resort for suppressing because it's obviously brittle, changes with version etc so can't be regexed.
| Additionally, there are several things that can be suppressed - individual CPEs, individual CVEs, or all CVE entries below a specified CVSS score. The most common | ||
| would be suppressing CPEs based off of SHA1 hashes or filePath (regexes) - these entries can be generated using the |
There was a problem hiding this comment.
Not critical, but given the above changes, we probably could rephrase this - it's pretty out of date to refer to suppressing by hash or file path as being the "most common".
The "most common" would probably be matching via purl regex, which is why we require this information when people file false positive reports - that's the most reliable way to suppress things. gav was most common pre-purl, when only Java artifacts really had a canonical designation.
nhumblot
changed the title
2 participants
This closes #8351
Description of Change
Documentation clarification
Related issues
#8351
Have test cases been added to cover the new functionality?
no