Toolkit build fails due to dependency-check netty lib vulnerabilities

[ColoradoKiwi]

Hi, I downloaded this repository, and am trying to build locally to run the test/sample app. When I attempt the maven build of the parent project, it fails during the build of "java-saml Toolkit Core" with the following errors:

One or more dependencies were identified with known vulnerabilities in OneLogin java-saml Toolkit Core:

netty-codec-dns-4.1.66.Final.jar (pkg:maven/io.netty/netty-codec-dns@4.1.66.Final, cpe:2.3:a:netty:netty:4.1.66:::::::) : CVE-2021-37136, CVE-2021-37137 netty-transport-4.1.67.Final.jar (pkg:maven/io.netty/netty-transport@4.1.67.Final, cpe:2.3:a:netty:netty:4.1.67:::::::) : CVE-2021-37136, CVE-2021-37137

(I am building using JDk 8 - latest build "1.8.0_311")

After above failed, I figured perhaps just try building the sample project on its own (and let that build pull the dependent "java-saml" artifact directly from maven central, rather than trying to get the core toolkit built locally, as one I fold into our app, thats what we would do anyway).... However when I attempt to build the sample project I'm getting the following error:

(Again during the dependency-check maven plugin execution)... Unable to create temp file for suppression file'.nvd-suppressions.xml' Exception occurred initializing CPE Analyzer.

Am very familiar with java and maven (our internal processes all use the same), but am not familiar with the dependency-check maven plugin. Is this an issue with the onelogin toolkit build itself? or something I need to do differently?

Any assistance would be great. Thx

[ColoradoKiwi]

Sorry - forgot to note - this was using the repo download from the latest tag "v2.8.0".

[mauromol]

My humble opinion on this is that having the build fail because of this dependency-check plugin is quite annoying, because it makes it hard to build the project for test and development purposes and causes PRs to be marked with a red cross even if they are genuine and do not break anything...

I know that @pitbulk periodically updates dependencies to fix that, before releasing a new version. But meanwhile, what I do in my development environment is to just disable that Maven plugin...

[ColoradoKiwi]

Thanks for the response, After posting the above, I ended up in the same place, and commented-out the "dependency-check-maven" plugin invocation in the toolkit parent plugin. Which at least got me to a good local build, and was able to continue.

I'm okay with that, as once I have sample running, and folded in code to our real app, shouldnt have a need to build the toolkit locally? (I hope).

[pitbulk]

The initial idea about adding dependency-check was to make developers aware about CVEs

So even if the don't update java-saml, they could see if they are in risk and decide what to do in each case.

If I remove the

<failBuildOnCVSS>7</failBuildOnCVSS>

I'm pretty sure that the CVE report will be ignored by 99% of devs.

The real problem here is that most of the CVEs came from dependencies used by azure-identity azure-security-keyvault-keys, which were added to support HSM which is totally optional in my toolkit.

@mauromol Do you think there is an easy way to make such integration as an addon and not affect rest of the toolkit?

btw I updated master with new versions of azure-identity and azure-security-keyvault-keys so now such branch compiles

[ColoradoKiwi]

Understood. Thanks for the response. Will close this issue, as at least I have a way forward. Thanks for the support!

[mauromol]

@pitbulk I'm not a Maven expert (I normally use Gradle): perhaps the dependency-check plugin can be configured so that it causes a build WARNING instead of a FAILURE? IMHO it's useful to intercept CVEs before releasing a new version, or on a periodic build run basis, but not on every single CI run, for the reasons described above.

I also do not know GitHub actions: can a job be configured to, say, run once a day to just run the dependency-check task and then send an e-mail to the project maintainers when such task fails?