feat: package and utilize generated suppression file

[jeremylong]

Description of Change

First of three PRs around cleaning up the differences between the generated and base suppression file. This PR enhances the build to download the current generated suppression file, packages it into the core lib, and loads both the base and generated suppression files during execution.

[Copilot]

Pull Request Overview

This PR introduces a mechanism to package a generated suppressions file with the application during build time by downloading it from a hosted URL. The downloaded file is then loaded alongside the existing base suppression file.

• Adds Maven exec plugin to download suppressions from a hosted URL during the build process
• Extends the suppression loading logic to include the downloaded generated-suppressions.xml file
• Refactors the packaged suppression loading method to accept a filename parameter for reusability

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
pom.xml	Adds version management for exec-maven-plugin
core/pom.xml	Configures exec-maven-plugin to download suppressions file using wget during build
core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java	Adds constant for generated suppressions filename and refactors loading logic to support both base and generated suppression files

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chadlwilson]

With this approach, ODC needs to load the generatedSuppressions twice, once off packaged, and again off "hosted" suppressions within the HostedSuppressionsDataSource - which will largely overlap. Does it de-duplicate these in memory at least? Is this a significant source of slowness?

It's slightly more complex, but I wonder if it would be cleaner to make this self contained somewhere within the below to just pre-populate the user's cache in the data directory on disk; to keep all logic and workflow related to these suppressions self-contained, and with consistent language?

With this approach it would happen

• on first use, prior to any attempt to update
• after hosted suppressions are purged
• regardless of whether hosted suppressions updates are enabled.

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java

Lines 260 to 264 in a9f313a

	if (!repoFile.isFile() || repoFile.length() <= 1L) {
	repoEmpty = true;
	LOGGER.warn("Hosted Suppressions file is empty or missing - attempting to force the update");
	getSettings().setBoolean(Settings.KEYS.HOSTED_SUPPRESSIONS_FORCEUPDATE, true);
	}

[chadlwilson]

If we keep this approach, perhaps we could try and align on language to make it a bit less confusing.

Right now it is referred to as

• "hosted" suppressions (main runtime terminology at runtime in ODC; but implies a remote source)
• "generated" suppressions (really refers to the automation workflows and the special branch they are tracked on)
• "published" suppressions (the file name when promoted to GitHub pages from source control, and bootstrapped here)

I wonder if referring to as dependencycheck-published-suppression-snapshot.xml would be better, or dependencycheck-hosted-suppression-snapshot.xml.

[nhumblot]

With this approach, ODC needs to load the generatedSuppressions twice, once off packaged, and again off "hosted" suppressions within the HostedSuppressionsDataSource - which will largely overlap. Does it de-duplicate these in memory at least? Is this a significant source of slowness?

It's slightly more complex, but I wonder if it would be cleaner to make this self contained somewhere within the below to just pre-populate the user's cache in the data directory on disk; to keep all logic and workflow related to these suppressions self-contained, and with consistent language?

With this approach it would happen

* on first use, prior to any attempt to update

* after hosted suppressions are purged

* regardless of whether hosted suppressions updates are enabled.

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java

Lines 260 to 264 in a9f313a

	if (!repoFile.isFile() || repoFile.length() <= 1L) {
	repoEmpty = true;
	LOGGER.warn("Hosted Suppressions file is empty or missing - attempting to force the update");
	getSettings().setBoolean(Settings.KEYS.HOSTED_SUPPRESSIONS_FORCEUPDATE, true);
	}

On my machine, a forced update took 148ms to be loaded on 4G connection with a phone.

We seem to load all elements in a List<SuppressionRule> and we add them through a void addAll(List<SuppressionRule>) call. I don't see any de-duplication so my guess is we are duplicating suppression rules between base and hosted suppressions as of now. It does not change much from now, so I may say it can be a future improvement opportunity (impact would have to be more thoroughly investigated) that could be tracked, and not a necessary change in this PR 🤔

[nhumblot]

issue: this seems to generate the following warning when performing a mvn -s settings.xml clean install:

[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.owasp:dependency-check-core:jar:12.1.10-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for com.googlecode.maven-download-plugin:download-maven-plugin is missing. @ line 103, column 21
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 

[nhumblot]

Suggested change

	<groupId>com.googlecode.maven-download-plugin</groupId>
	<groupId>io.github.download-maven-plugin</groupId>

[chadlwilson]

Oops, missed this in my proposed edit earlier - thx!

[chadlwilson]

My concern is more about evaluation/analysis rather than loading the file.

I haven't looked at how smart the algorithm is or how parallelized, but my concern would be that there is an O(n^2) issue here, e.g if every suppression is evaluated for every single possible dependency. We also don't really have any automation to ensure the regexes aren't insanely expensive which might have a multiplicative effect.

On a bigger project with, say, 1,000 dependencies (JavaScript!!) and lots of FPs due to use of CLI and generic dependency names, that might be an issue - either slowness or excessive junk/GC production.

Aside from perf, I also think it's a bit confusing to have 3 data sources in the code to reason about, which is why I suggest using this file essentially as an initial cache value for HostedSuppressions instead (when working offline, or if stale) since it is not valid/useful to have both the packaged version and a version received remotely. I'm happy to test and suggest a PR to this one if @jeremylong wants to see what it might look like.

That'd avoid having to do any de-duplication of individual suppressions since we can generally assume there are very limited duplications between base and hosted/generated/published (especially after Jeremy's adjacent cleanup PRs).

I think that helps us as it's already quite tough figuring out why we might not be able to replicate a given FP given combinations of (ODC version, ODC variant, enabled analyzers, enabled data sources, available data sources, hosted suppressions currentness, offline status, available local tools)

[jeremylong]

I like the idea of the embedded being the initial cache - especially if you don't mind putting together the PR ;).

I was also going to make sure there was a mechanism to prevent loading the same rule twice...