Open johannes-wannenburg opened 1 week ago
First question you should ask yourself is why you're scanning a build tool for its known vulnerable dependencies in a blocking step of a software delivery pipeline.
Looks like you're not scanning the right folders. Scanning the tool would be a good practice for a build tooling vulnerability monitoring pipeline, not for an individual software project I'd say.
So the best way to handle your current blockage is by making sure that you scan only your project and its (runtime) dependencies.
Upgrade of h2 is not foreseen until v 10.x (as the h2 upgrade could/would break builds) - https://github.com/jeremylong/DependencyCheck/pull/6132, but the vulnerability reported on it is disputed by the authors and applicable only to running h2 as a local db server with a web console, so not applicable to OWASP DC's usage of it as an embedded database engine.
Logback is referred in https://github.com/jeremylong/DependencyCheck/pull/6178 as an update requiring more work. If it's the same CVE that gets flagged then the usage of OWASP DC is not affected by it.
Bouncycastle would need some deeper look, but I'm away from computer until after the weekend.
Thanks for the feedback, I assumed it could be by design.
The config I used is spelling out the paths to scan, but I found the issue based on your feedback. I see that the previous person configured "-s .", causing this behaviour. I removed this and it is no longer reporting on OWASP.
Hi,
We receive these messages which appear to be related to Maven packages loaded by the scanning tool. Is this expected? How should we deal with these as they are blocking our pipelines.