eddumelendez
commented
1 year ago Hi, JFTR before someone raises a PR related to this. I thought about it couple of weeks ago and even did a quick POC. Due to Testcontainers is already using gradle-build-action, it will be great to take advantage of Dependency Graph support. So, dependencies section in GH is updated and it will allow to export the SBOM
The reason why I didn't submit it yet to the main repository is because we need to discuss about it internally.
Module
Core
Proposal
(Note: I mentioned 'core' above but this will affect core and all modules)
Motivation
Companies are increasingly concerned about tracking known vulnerabilities in their software supply chain.
This is a deep issue but a good first step is incorporating the OWASP dependency analyzer in our maven or gradle build configuration files. This plugin checks all dependencies against a database of known vulnerabilities and creates a report that lists:
In addition you can configure this plugin to cause the build to fail if the vulnerability score is too high. This will force the developers to update their dependencies and hopefully reduce the likeliness of a nightmare situation where an "absolutely must fix" vulnerability, e.g., the recent log4j vulnerability, will trigger the forced upgrade of multiple dependencies at the same time with the concurrent increased risk of changed behavior.
There is a safety valve that allows vulnerable dependencies to continue to be used within contributing to the vulnerability score. This is warranted if you've determined that your application never accesses the vulnerable code.
Important - this scanner does not perform any static analysis (see: findbugs, veracode). The only thing it does is check the project's dependencies against a database of vulnerabilities.
build.gradle Changes
Very few changes to the root
build.gradlefile are required to add the OWASP plugin.Note: the most recent version of the plugin is 8.4.4 but it's not compatible with the current version of the JVM.
This produces a summary of the vulnerable dependencies on the console during builds, and a more detailed report (in multple formats) in
$buildDir/reports/dependency-check-report.*Sample Output (Console)
This is the console output on my 'testcontainers-extra' project - it contain several additional JdbcDatabaseContainers and new Hamcrest matchers.
Many of these are build dependencies and are not used in the final artifacts. Our community has not been concerned about these vulnerabilities in the past - but one of the key concepts in the Secure Software Supply Chain model is that vulnerabilities in the build dependencies are just as important as vulnerabilities in the final artifact.
This is a reasonable concern - a sophisticated attacker can almost always affect much more code with a compromised build dependency that injects malware into everything it touches with a compromised deployed dependency. Consider the damage that would be possible if
maven-jar-plugininjected code that recognized REST clients and attempted to exfiltrate the connection URL and credentials to a hostile site. This could be caught by static analysis of the final artifacts - but few sites do this and the injected code may be sufficiently obfuscated to avoid early detection.One Gradle Complication
Maven: clean reports
Gradle: lots of extra projects. It's not hard to mentally strip off the
:checkstyleandspotless-NNNNNNbut it would be nice if it could be avoided. This might be a simple fix in either thebuild.gradlefile or thedependencyCheckconfiguration. This is especially true when the same dependency is listed multiple times.It's easiest to attach an example: