Allow to suppress by file path from report

[kwin]

The report only allows to generate suppressions snippets for packageUrl. However for shaded dependencies the filePath is more relevant.
For example with pkg:maven/com.github.jknack/handlebars@4.3.1 I see the following report

1. Title: handlebars-4.3.1.jar (shaded: org.apache.commons:commons-lang3:3.12.0)
2. File Path: /handlebars-4.3.1.jar/META-INF/maven/org.apache.commons/commons-lang3/pom.xml
3. Package URL: pkg:maven/org.apache.commons/commons-lang3@3.12.0
4. cpe:2.3:a:apache:commons_lang:3.12.0:*:*:*:*:*:*:*
5. CVE: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2025-48924

However I can only generate suppressions by package url and cpe or CVE. Would be nice to expose a button to also suppress by filePath for shaded dependencies.

[chadlwilson]

The report only allows to generate suppressions snippets for packageUrl. However for shaded dependencies the filePath is more relevant.

I don’t really agree with this assertion and personally don’t recommend doing this. Paths are brittle, especially inside other people’s dependencies where they are sensitive to ODC’s own logic for scanning as to which path is used on the match (since often there is no natural canonical path for a shaded dependency, ODC just has to choose one based on how it has been discovered).

The vulnerability is still matched via commons lang 3.12 as a logical package, which “happens” to have been discovered via a POM inside a specific version of handlebars, but could also have been discovered via other mechanisms inside the same jar which would create a different path. The component of your software which has the vuln is still commons lang, so IMO the vuln still needs to be suppressed against commons lang.

The path contains the handlebars version but not the commons-lang version so to me there’s not really a safe/sensible suppression that can be reliably suggested to users, and I think the tool would generally not want to suggest people go down a potentially wrong or “last resort” track.

[kwin]

For me the vulnerability impact on shaded/relocated dependencies are lot lower than on non-relocated ones. That is because the shaded ones are only used from the Jar itself in most cases but not from any other dependencies (due to the custom package name). Therefore I would argue that suppressing a CVE only in a relocated dependency is sensible but at the same time not suppress the CVE in general (for the non-relocated case).

[kwin]

However I agree that suppressions based on filePath are brittle (see #8351) so in the best case there is another way to distinguish relocated/shaded dependencies from unshaded/non-relocated ones.

[chadlwilson]

For me the vulnerability impact on shaded/relocated dependencies are lot lower than on non-relocated ones. That is because the shaded ones are only used from the Jar itself in most cases but not from any other dependencies (due to the custom package name).

The problem is that the term shaded is used loosely (both in ODC and shading plugins for maven/gradle etc). It doesn't necessarily mean "package relocated". Some "shaded" dependencies are actually fully on the classpath of the parent application as uber/fat jars; and ODC makes no attempt to determine the difference - IIRC it just includes anything implied by a nested META-INF/something/pom.xml.

So it doesn't generally hold true that they are only used by the jar itself.

I imagine if you really want to suppress just for the shaded dependency you can possibly suppress by the hash of the pom file, which is likely only going to match inside a dependency uber-jar anyway, since a "real" dependency will have the hash of the actual jar file.

[OrangeDog]

In general, you probably shouldn’t be using suppressions from the report at all. You should instead understand the context of the vulnerability, whether the detection is accurate, and the context of how you're depending on it, and always write the suppression manually to account for it.

For an shaded dependency that cannot "escape" its parent dependency and you know is mitigated there, yes write a file path suppression. You can decide whether you want the convenience of using a regex pattern to cover multiple versions, or the security of only an exact match that you have to re-evaluate on every upgrade.

[chadlwilson]

The report just helps suggest boilerplate syntax for either a CVE-specific suppression or a CPE one which is useful if you aren't super familiar with the syntax options. That's all it is really.

Users still have to apply their judgment before putting it in their suppressions files, and ideally change the CDATA/comment to explain why, scope it down more finely to a specific package version range - or perhaps more widely if the same false positive affects a group of packages.