This is a simple project demonstrating how to use the dependency-submission GitHub action to detect
vulnerable dependencies in a Gradle project, and various techniques to address these vulnerabilities.
You may find it useful to fork this repository, which will allow you to follow this guide, viewing and resolve Dependabot alerts. Note that GitHub Actions workflows are not automatically enabled for repository forks. To start the process, you'll need to:
- Fork the repository
- Navigate to "Settings -> Code security and analysis" to enable Dependency graph and Dependabot alerts (see below)
- Navigate to the "Actions" tab to enable GitHub Actions workflows
- Push a commit to the 'main' branch in order to trigger the initial
dependency-submissionworkflow to run. A change to the README will be sufficient.
In order to receive alerts about any vulnerable dependencies for this repository:
- Dependency graph and Dependabot alerts are enabled
- A simple
dependency-submissionworkflow is configured to run on any push to themainbranch
Note that the workflow is configured to publish a Build Scan® on each run. This Build Scan will contain information about your project structure and dependencies, and will be useful later as we attempt to identify and resolve any vulnerable dependencies.
See the full dependency-submission documentation for more details on adding a dependency-submission workflow.
After executing the dependency-submission workflow, the repository has 5 current Dependabot alerts for vulnerable dependencies.
These are not publicly visible in the repo, but here is the list:
In the following sections we will step through the process of investigating, isolating and addressing different types of vulnerabilities.
- Updating a direct dependency to non-vulnerable version
- Updating a vulnerable transitive dependency by updating a direct dependency
- Updating a transitive dependency using a dependency constraint
- Updating a Plugin classpath dependency using a dependency constraint
In this example repository, a dependency on org.apache.commons:commons-text:1.9 results in the following
Dependabot alert:
In this simple case, the vulnerable dependency is declared directly in the Gradle project, and a newer, non-vulnerable version is available.
The fix is as simple as bumping the version in the project. Here is a pull-request that will address this vulnerability.
We see 2 vulnerabilities reported for org.apache.commons:commons-compress:1.24.0, like this:
But there isn't anywhere in our Gradle project where we add depend on commons-compress, which means this vulnerability
must involve a transitive dependency. The first step is to identify which direct dependency is responsible.
The easiest way to do this is with a Gradle Build Scan®, which is why our workflow is configured to automatically publish a Build Scan for every dependency submission. You'll find the build-scan link in the summary for each workflow run.
By inspecting the Build Scan for the latest submission on 'main', we can see that commons-compress is required by io.minio:minio:8.5.8, which is a direct dependency of our project.
Searching for newer versions reveals that there's an updated version of minio available (8.5.9),
and when we update our project to this version, the commons-compress library is updated to 1.26.0.
Here's the pull-request that will update the version of minio,
resolving the 2 Dependabot alerts triggered by org.apache.commons:commons-compress:1.24.0.
At times when you won't be able to update a direct dependency to resolve a transitive dependency vulnerability. This can occur if there isn't a newer version of the direct dependency available, or perhaps your project isn't compatible with the newer version.
In this case, you can directly control the transitive dependency version using a dependency constraint. A dependency contraint allows you to specify a transitive dependency version to use, without adding a direct dependency on that version.
This pull-request adds a dependency constraint that causes the build
to use a newer version of commons-compress, thereby resolving the Dependabot alert.
If you inspect the resulting Build Scan,
you can see that the version of commons-compress is updated, but the version of minio is not changed.
In addition to things you declare in a dependencies block, any Gradle plugins that you apply to your build
will likely have library dependencies.
Vulnerabilities in these plugin dependencies are detected by the dependency-submission action.
The final 2 Dependabot alerts in this project are due to com.squareup.okio:okio-jvm:3.2.0 and com.squareup.okio:okio:3.2.0.
When inspecting the Build Scan for these vulnerable versions, we note that they are not listed in the
"Dependencies" section.
This is because these vulnerable versions are actually brought in by the com.github.ben-manes.versions plugin:
you can see this by searching for 'okio' in the "Build Dependencies" section of the Build Scan.
Although vulnerable plugin dependencies like this can be trickier to identify, they can be resolved in much the same way as regular transitive dependencies, either by updating to a new version of the plugin, or by using a dependency constraint.
In this case there is no newer version of the plugin available, so we must add a dependency constraint to force a newer version of okio to be used.
This pull request adds a dependency constraint to the buildscript classpath, w
hich fixes the security vulnerablitity in okio that is introduced by the com.github.ben-manes.versions plugin.
The resulting Build Scan demonstrates that the build dependencies no longer include the vulnerable dependency versions.
