DependencyCheck
OWASP dependency-check is a software composition analysis utility that detects publicly disclosed vulnerabilities in application dependencies.
Top Related Projects
Snyk CLI scans and monitors your projects for security vulnerabilities.
A vulnerability scanner for container images and filesystems
Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
🤖 Dependabot's core logic for creating update PRs.
Quick Overview
OWASP Dependency-Check is an open-source software composition analysis tool that detects publicly disclosed vulnerabilities in project dependencies. It scans project dependencies and checks if there are any known, publicly disclosed vulnerabilities associated with them, helping developers identify and mitigate potential security risks in their applications.
Pros
- Supports multiple programming languages and package managers
- Integrates with various build tools and CI/CD pipelines
- Regularly updated vulnerability database
- Generates comprehensive HTML, XML, CSV, and JSON reports
Cons
- Can produce false positives due to version matching issues
- Scanning large projects may be time-consuming
- Requires regular updates to maintain an up-to-date vulnerability database
- May not detect vulnerabilities in custom or internally developed libraries
Code Examples
- Running a scan using the command-line interface:
dependency-check --project "My Project" --scan /path/to/application
- Integrating with Maven:
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>7.1.1</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
- Using Dependency-Check with Gradle:
plugins {
id 'org.owasp.dependencycheck' version '7.1.1'
}
dependencyCheck {
formats = ['HTML', 'JSON']
scanConfigurations = ['runtimeClasspath', 'compileClasspath']
}
Getting Started
-
Install Dependency-Check CLI:
brew install dependency-check
-
Run a scan on your project:
dependency-check --project "My Project" --scan /path/to/application --format HTML
-
Review the generated report in the
dependency-check-report.html
file.
Competitor Comparisons
Snyk CLI scans and monitors your projects for security vulnerabilities.
Pros of Snyk CLI
- Offers real-time monitoring and continuous scanning for vulnerabilities
- Provides fix suggestions and automated pull requests for remediation
- Supports a wider range of programming languages and package managers
Cons of Snyk CLI
- Requires a Snyk account and authentication for full functionality
- May have limitations on the number of scans or projects in free tier
- Can be more complex to set up and integrate into CI/CD pipelines
Code Comparison
DependencyCheck:
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>6.5.3</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
Snyk CLI:
{
"scripts": {
"test": "snyk test",
"monitor": "snyk monitor"
},
"devDependencies": {
"snyk": "^1.685.0"
}
}
Both tools aim to identify and report vulnerabilities in project dependencies, but they differ in their approach and features. DependencyCheck is open-source and can be run locally without external dependencies, while Snyk CLI offers more comprehensive monitoring and remediation features but requires an account and may have usage limitations.
A vulnerability scanner for container images and filesystems
Pros of Grype
- Faster scanning speed, especially for large projects
- Better container image scanning capabilities
- More frequent updates to vulnerability database
Cons of Grype
- Less comprehensive language support compared to DependencyCheck
- Fewer integration options with CI/CD tools
- Limited reporting formats
Code Comparison
DependencyCheck:
<dependency>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>7.1.1</version>
<scope>test</scope>
</dependency>
Grype:
- name: Scan with Grype
uses: anchore/scan-action@v3
with:
image: "myimage:latest"
fail-build: true
severity-cutoff: high
Both tools aim to identify vulnerabilities in dependencies, but they differ in implementation and usage. DependencyCheck is more established and offers broader language support, while Grype excels in container scanning and performance. DependencyCheck is typically integrated into build processes, whereas Grype is often used as a standalone tool or in CI/CD pipelines. The choice between them depends on specific project requirements, such as the types of artifacts being scanned and the desired integration with existing workflows.
Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
Pros of Trivy
- Broader scanning capabilities: Covers containers, filesystems, git repositories, and more
- Faster scanning speed, especially for large projects
- More comprehensive vulnerability database, including OS packages and language-specific dependencies
Cons of Trivy
- Less mature project with potentially more frequent breaking changes
- May require more system resources for comprehensive scans
- Limited integration options compared to DependencyCheck's extensive plugin ecosystem
Code Comparison
Trivy command-line usage:
trivy image python:3.4-alpine
DependencyCheck command-line usage:
dependency-check --project "My Project" --scan /path/to/source-code
Both tools provide similar functionality for scanning dependencies, but Trivy's syntax is generally simpler for basic scans. DependencyCheck offers more granular control over scan parameters and report generation.
Trivy's output is typically more concise and focused on vulnerabilities, while DependencyCheck provides more detailed reports that include additional metadata about dependencies.
Overall, Trivy excels in speed and breadth of scanning capabilities, making it suitable for CI/CD pipelines and container-centric environments. DependencyCheck offers more customization options and integrations, making it a solid choice for projects requiring detailed dependency analysis and reporting.
🤖 Dependabot's core logic for creating update PRs.
Pros of Dependabot Core
- Automated pull requests for dependency updates
- Supports a wide range of package managers and ecosystems
- Integrates seamlessly with GitHub's native features
Cons of Dependabot Core
- Focused primarily on updating dependencies, not comprehensive security scanning
- May require more configuration for complex projects
- Limited to GitHub ecosystem
Code Comparison
DependencyCheck:
Engine engine = new Engine();
engine.scan(applicationPath);
engine.analyzeDependencies();
Dependabot Core:
dependencies = Dependabot::FileParsers.for_package_manager("npm_and_yarn").new(
dependency_files: files,
source: source,
credentials: credentials,
).parse
updated_deps = dependencies.map do |dep|
Dependabot::UpdateCheckers.for_package_manager("npm_and_yarn").new(
dependency: dep,
dependency_files: files,
credentials: credentials,
).up_to_date?
end
DependencyCheck focuses on scanning and analyzing dependencies for vulnerabilities, while Dependabot Core emphasizes automating dependency updates through pull requests. DependencyCheck provides a simpler API for scanning, while Dependabot Core offers more granular control over the update process. Both tools serve different primary purposes in the software development lifecycle.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Dependency-Check
Dependency-Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project's dependencies. It does this by determining if there is a Common Platform Enumeration (CPE) identifier for a given dependency. If found, it will generate a report linking to the associated CVE entries.
Documentation and links to production binary releases can be found on the github pages. Additionally, more information about the architecture and ways to extend dependency-check can be found on the wiki.
Notice
This product uses the NVD API but is not endorsed or certified by the NVD.
Mandatory Upgrade Notice
Upgrading to 10.0.2 or later is mandatory
Older versions of dependency-check are causing numerous, duplicative requests that
end in processing failures are causing unnecassary load on the NVD API. Dependency-check
10.0.2 uses an updated User-Agent
header that will allow the NVD to block calls
from the older client.
NVD API Key Highly Recommended
Dependency-check has moved from using the NVD data-feed to the NVD API. Users of dependency-check are highly encouraged to obtain an NVD API Key; see https://nvd.nist.gov/developers/request-an-api-key Without an NVD API Key dependency-check's updates will be extremely slow. Please see the documentation for the cli, maven, gradle, or ant integrations on how to set the NVD API key.
The NVD API Key, CI, and Rate Limiting
The NVD API has enforced rate limits. If you are using a single API KEY and multiple builds occur you could hit the rate limit and receive 403 errors. In a CI environment one must use a caching strategy.
Breaking Changes
9.0.0 contains breaking changes which requires updates to the database. If using an externally hosted database the schema will need to be updated. When using the embedded H2 database, the schema should be upgraded automatically. However, if issues arise you may need to purge the database:
- gradle:
./gradlew dependencyCheckPurge
- maven:
mvn org.owasp:dependency-check-maven:9.0.0:purge
- cli:
dependency-check.sh --purge
Gradle build Environment
With 9.0.0 users may encounter issues with NoSuchMethodError
exceptions due to
dependency resolution. If you encounter this issue you will need to pin some of
the transitive dependencies of dependency-check to specific versions. For example:
/buildSrc/build.gradle
dependencies {
constraints {
// org.owasp.dependencycheck needs at least this version of jackson. Other plugins pull in older versions..
add("implementation", "com.fasterxml.jackson:jackson-bom:2.16.1")
// org.owasp.dependencycheck needs these versions. Other plugins pull in older versions..
add("implementation", "org.apache.commons:commons-lang3:3.14.0")
add("implementation", "org.apache.commons:commons-text:1.11.0")
}
}
Requirements
Java Version
Minimum Java Version: Java 11
Internet Access
OWASP dependency-check requires access to several externally hosted resources. For more information see Internet Access Required.
Build Tools
In order to analyze some technology stacks dependency-check may require other development tools to be installed. Some of the analysis listed below may be experimental and require the experimental analyzers to be enabled.
- To analyze .NET Assemblies the dotnet 8 run time or SDK must be installed.
- Assemblies targeting other run times can be analyzed - but 8 is required to run the analysis.
- If analyzing GoLang projects
go
must be installed. - The analysis of
Elixir
projects requiresmix_audit
. - The analysis of
npm
,pnpm
, andyarn
projects requiresnpm
,pnpm
, oryarn
to be installed.- The analysis performed utilize the respective
audit
feature of each.
- The analysis performed utilize the respective
- The analysis of Ruby is a wrapper around
bundle-audit
, which must be installed.
Current Releases
Jenkins Plugin
For instructions on the use of the Jenkins plugin please see the OWASP Dependency-Check Plugin page.
Command Line
More detailed instructions can be found on the dependency-check github pages. The latest CLI can be downloaded from github in the releases section.
Downloading the latest release:
$ VERSION=$(curl -s https://jeremylong.github.io/DependencyCheck/current.txt)
$ curl -Ls "https://github.com/jeremylong/DependencyCheck/releases/download/v$VERSION/dependency-check-$VERSION-release.zip" --output dependency-check.zip
On *nix
$ ./bin/dependency-check.sh -h
$ ./bin/dependency-check.sh --out . --scan [path to jar files to be scanned]
On Windows
> .\bin\dependency-check.bat -h
> .\bin\dependency-check.bat --out . --scan [path to jar files to be scanned]
On Mac with Homebrew
Note - homebrew users upgrading from 5.x to 6.0.0 will need to run dependency-check.sh --purge
.
$ brew update && brew install dependency-check
$ dependency-check -h
$ dependency-check --out . --scan [path to jar files to be scanned]
Maven Plugin
More detailed instructions can be found on the dependency-check-maven github pages.
By default, the plugin is tied to the verify
phase (i.e. mvn verify
). Alternatively,
one can directly invoke the plugin via mvn org.owasp:dependency-check-maven:check
.
The dependency-check plugin can be configured using the following:
<project>
<build>
<plugins>
...
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
...
</project>
Gradle Plugin
For instructions on the use of the Gradle Plugin, please see the dependency-check-gradle github page.
Ant Task
For instructions on the use of the Ant Task, please see the dependency-check-ant github page.
Development Prerequisites
For installation to pass, you must have the following components installed:
- Java:
java -version
1.8 - Maven:
mvn -version
3.5.0 and higher
Tests cases require:
- dotnet core version 8.0
- Go:
go version
1.12 and higher - Ruby bundler-audit
- Yarn
- pnpm
Development Usage
The following instructions outline how to compile and use the current snapshot. While every intention is to maintain a stable snapshot it is recommended that the release versions listed above be used.
The repository has some large files due to test resources. The team has tried to clean up the history as much as possible. However, it is recommended that you perform a shallow clone to save yourself time:
git clone --depth 1 https://github.com/jeremylong/DependencyCheck.git
On *nix
$ mvn -s settings.xml install
$ ./cli/target/release/bin/dependency-check.sh -h
$ ./cli/target/release/bin/dependency-check.sh --out . --scan ./src/test/resources
On Windows
> mvn -s settings.xml install
> .\cli\target\release\bin\dependency-check.bat -h
> .\cli\target\release\bin\dependency-check.bat --out . --scan ./src/test/resources
Then load the resulting 'dependency-check-report.html' into your favorite browser.
Building without running tests
To speed up your turnaround cycle times, you can also compile without running the tests each time:
mvn -s settings.xml install -DskipTests=true
Please remember to at least run the tests once before opening the PR. :)
IntelliJ Idea
To be able to debug your tests in IntelliJ Idea, you can introduce a maven configuration that executes your test and enables debugging with breakpoints etc.
Basically, you do what´s described in https://www.jetbrains.com/help/idea/work-with-tests-in-maven.html#run_single_test and set the forkCount
to 0, otherwise debugging won´t work.
Step by step:
Run -> Edit Configurations
+ (Add new configuration) -> Maven
- Give the Configuration a name, e.g.
Run tests
- Choose working directory, e.g.
core
- In
command line
, enter-DforkCount=0 -f pom.xml -s ../settings.xml test
- Press
OK
Run -> Debug
, then choose the newly created run configuration
IntelliJ will now execute the test run for the core
subproject with enabled debugging. Breakpoints set anywhere in code should work.
Only test one function or one class
If you would like to speed up your turnaround cycle times, you can also just test one function or one test class.
This works by adding -Dtest=MyTestClass
or -Dtest=MyTestClass#myTestFunction
to the run configuration. The complete command line in the run configuration then would be:
-Dtest=MyTestClass#myTestFunction -DforkCount=0 -f pom.xml -s ../settings.xml test
Docker
In the following example it is assumed that the source to be checked is in the current working directory and the reports will be written to $(pwd)/odc-reports
. Persistent data and cache directories are used, allowing you to destroy the container after running.
For Linux:
#!/bin/sh
DC_VERSION="latest"
DC_DIRECTORY=$HOME/OWASP-Dependency-Check
DC_PROJECT="dependency-check scan: $(pwd)"
DATA_DIRECTORY="$DC_DIRECTORY/data"
CACHE_DIRECTORY="$DC_DIRECTORY/data/cache"
if [ ! -d "$DATA_DIRECTORY" ]; then
echo "Initially creating persistent directory: $DATA_DIRECTORY"
mkdir -p "$DATA_DIRECTORY"
fi
if [ ! -d "$CACHE_DIRECTORY" ]; then
echo "Initially creating persistent directory: $CACHE_DIRECTORY"
mkdir -p "$CACHE_DIRECTORY"
fi
# Make sure we are using the latest version
docker pull owasp/dependency-check:$DC_VERSION
docker run --rm \
-e user=$USER \
-u $(id -u ${USER}):$(id -g ${USER}) \
--volume $(pwd):/src:z \
--volume "$DATA_DIRECTORY":/usr/share/dependency-check/data:z \
--volume $(pwd)/odc-reports:/report:z \
owasp/dependency-check:$DC_VERSION \
--scan /src \
--format "ALL" \
--project "$DC_PROJECT" \
--out /report
# Use suppression like this: (where /src == $pwd)
# --suppression "/src/security/dependency-check-suppression.xml"
For Windows:
@echo off
set DC_VERSION="latest"
set DC_DIRECTORY=%USERPROFILE%\OWASP-Dependency-Check
SET DC_PROJECT="dependency-check scan: %CD%"
set DATA_DIRECTORY="%DC_DIRECTORY%\data"
set CACHE_DIRECTORY="%DC_DIRECTORY%\data\cache"
IF NOT EXIST %DATA_DIRECTORY% (
echo Initially creating persistent directory: %DATA_DIRECTORY%
mkdir %DATA_DIRECTORY%
)
IF NOT EXIST %CACHE_DIRECTORY% (
echo Initially creating persistent directory: %CACHE_DIRECTORY%
mkdir %CACHE_DIRECTORY%
)
rem Make sure we are using the latest version
docker pull owasp/dependency-check:%DC_VERSION%
docker run --rm ^
--volume %CD%:/src ^
--volume %DATA_DIRECTORY%:/usr/share/dependency-check/data ^
--volume %CD%/odc-reports:/report ^
owasp/dependency-check:%DC_VERSION% ^
--scan /src ^
--format "ALL" ^
--project "%DC_PROJECT%" ^
--out /report
rem Use suppression like this: (where /src == %CD%)
rem --suppression "/src/security/dependency-check-suppression.xml"
Building From Source
To build dependency-check (using Java 11) run the command:
mvn -s settings.xml install
Running dependency-check on dependency-check
Dependency-check references several vulnerable dependencies that are never used
except as test resources. All of these optional test dependencies are included in
the test-dependencies
profile. To run dependency-check against itself simple
exclude the test-dependencies
profile:
mvn org.owasp:dependency-check-maven:aggregate -P-test-dependencies -DskipProvidedScope=true
Building the documentation
The documentation on the github pages is generated from this repository:
mvn -s settings.xml site site:staging
Once done, point your browser to ./target/staging/index.html
.
Building The Docker Image
To build dependency-check docker image run the command:
mvn -s settings.xml install
./build-docker.sh
License
Permission to modify and redistribute is granted under the terms of the Apache 2.0 license. See the LICENSE.txt file for the full license.
Dependency-Check makes use of several other open source libraries. Please see the NOTICE.txt file for more information.
This product uses the NVD API but is not endorsed or certified by the NVD.
Copyright (c) 2012-2024 Jeremy Long. All Rights Reserved.
Top Related Projects
Snyk CLI scans and monitors your projects for security vulnerabilities.
A vulnerability scanner for container images and filesystems
Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
🤖 Dependabot's core logic for creating update PRs.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot