feat: Allow multiple base suppression files coming from several dependencies#7541
feat: Allow multiple base suppression files coming from several dependencies#7541nMoncho wants to merge 2 commits intodependency-check:mainfrom
Conversation
|
@nMoncho The only real difference between "regular" suppressionFile and the baseSuppressionFile is that the baseSuppressionFile is directly packaged by this project as an embedded resource. Your project can simpy publish a suppressionFiles. You can already feed multiple suppression files to have some suppressions managed centrally. |
|
Hi @aikebah, yep that difference is clear. Say you've 3 projects: Instead of having the same suppression rule across 3 different repositories/projects (ie. 3 different files), we'd package the suppression in |
|
For such a case I think it's better to create a new, default switched off, feature for using 'library-embedded-suppressions' with a default but customizable resource-name (where the default name would deviate from ODC's base suppressions file). |
|
These suppression files would not be loaded unless the JAR that embedded them were on the classpath - which by default "analyzed" JARs are not on the classpath. We would need an analyzer that would retrieve the suppression file from the analyzed JAR files. |
|
The idea has merit - I just don't think this implementation will work. |
|
@jeremylong you're completely, it would another classpath entirely. The approach we're taking on our project is actually to use SBT to get all the JARs, extract their content, and look for the suppression file. I forgot about what would be loaded when the analysis is ran. Thanks for taking the time to review this. |
Description of Change
By allowing multiple packaged base suppression files, projects can export their suppressions so other downstream projects can reuse these suppressions.
On our project we follow an approach where we've a "commons" library pulls most of the dependencies that will be used transitively. In order to avoid duplicating the suppression file on each downstream project, we package the "commons" suppression file, and we aggregate it with any other suppressions on the downstream projects.
There is at least one potential downside to this, in that some library could suppress a vulnerability that we as users disagree with. This is nonetheless the current case with the packaged suppression, as there is no way to disable them.
Please let me know if this PR would be a desirable feature, otherwise feel free to close it.
There is one issue with the implementation though. In order to keep the base/non-base status of the suppression depending where it's used (ie. if it's packaged or if it's used by the project that defined it), it's possible for force the "base" attribute when loading the packaged suppressions with "setBase(true)". If the feature is desirable, I can make an update to the PR.
Have test cases been added to cover the new functionality?
no