Skip to content

docs: Clarify how suppress items are matched against files #8354

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.

Sign up for GitHub

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

Open
kwin wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: Clarify how suppress items are matched against files #8354

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions src/site/markdown/general/suppression.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,19 @@ A sample suppression file would look like:
The above XML file will suppress the cpe:/a:apache:struts:2.0.0 from any file with the a matching SHA1 hash.

The following shows some other ways to suppress individual findings. Note the ways to select files using either
the sha1 hash or the filePath (the filePath can also be a regex). 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

- their sha1 hash (via element `<sha1>),
- their package URL (via element `<packageUrl>`),
- their Maven like coordinates (groupId/namespace, artifactId/name and version via element `<gav>`), or
- their file path (via element `<filePath>`).

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.
Copy link
Collaborator

@chadlwilson chadlwilson Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@kwin kwin Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In which cases are Purls not available? So only sha1 is available for all files?

Copy link
Collaborator

@chadlwilson chadlwilson Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

@chadlwilson chadlwilson Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

The `<filePath>` value is matched against the OS-specific absolute file path of the according dependency
(for example a path inside the local Maven repository).

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
Comment on lines +37 to 38
Copy link
Collaborator

@chadlwilson chadlwilson Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

HTML version of the report. The other common scenario would be to ignore all CVEs below a certain CVSS threshold.

Expand Down
Loading