A transparent discovery signal based on current public GitHub metadata.
Recent activity35% weight
100
Community adoption25% weight
78
Maintenance state20% weight
85
License clarity10% weight
100
Project information10% weight
100
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
README preview
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 to 12.1.0+
Due to NVD API compatibility changes, an upgrade is mandatory. See #7463 for more information.
Breaking Changes in 11.0.0
Java 11 is now required to run dependency-check 11.0.0 or higher
H2 database upgrade
11.0.0 contains breaking changes using the local H2 database. A full download
of the NVD data will occur. Note that if you are using a shared data directory
the h2 database file is not compatible with older versions of dependency-check.
If you run into problems you may need to run a purge:
Dependency-check moved from using the NVD data-feed to the NVD API since 9.0.0+ (January 2024).
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.
Sonatype OSS Index mandatory authentication and migration to Sonatype Guide
In September 2025 Sonatype OSS Index started enforcing use of API tokens for authentication. In April 2026 a
subsequent migration to Sonatype Guide began, kicking off a transition to use of Sonatype Guide API Tokens that are
planned to replace the legacy OSS Index API keys/tokens before the end of 2026.
Without credentials, Dependency Check will automatically disable the OSS Index analyzer. Please see the documentation
for the CLI, Maven, Gradle, or Ant integrations on how to set the analyzer credentials for use of a Sonatype Guide token
or legacy OSS Index API key.
If you wish to use Sonatype OSS Index (via Guide) you must configure Dependency-Check and consider implications for the
migration to Sonatype Guide; whose commercial/usage model has changed. See the analyzer documentation
for more information.
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.21.2")
// org.owasp.dependencycheck needs these versions. Other plugins pull in older versions..
add("implementation", "org.apache.commons:commons-lang3:3.20.0")
add("implementation", "org.apache.commons:commons-text:1.15.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 requires mix_audit.
The analysis of npm, pnpm, and yarn projects requires npm, pnpm, or yarn to be installed.
The analysis performed utilize the respective audit feature of each.
The analysis of Ruby is a wrapper around bundle-audit, which must be installed.
$ ./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:
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:
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 t
