Videos
We use OWASP DepCheck plugin as well, together with standalone SonarQube server.
Basically, you'll need to solve 2 issues to use OWASP DepCheck plugin effectively:
Avoid throttling during NVD DB updates by making sure the plugin uses the NVD API key. Hardcode it in
pom.xml, provide it via CLI option, or via evironment variable -- doesn't matter, choose whatever is easier to maintain. We chose Gitlab CI variables to avoid exposing the key in logs and/or repos.Avoid unnecessary DB updates by caching NVD DB downloaded by the plugin. You can use Gitlab CI/CD caching, Docker volumes or bind mounts if you use Docker-based Gitlab runners. We chose Docker bind mounts since we only have one mighty build server, and don't need to share the cache between hosts.
This is how it all comes together, giving you both a nice HTML report as a Gitlab artifact, and also the same info as part of the SonarQube scan report:
pom.xml
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>${dependency-check-maven.version}</version>
<configuration>
<dataDirectory>/tmp/owasp</dataDirectory>
<formats>
<!-- we need both HTML (for humans) and JSON (for machines) to make the report useful in Sonar -->
<format>html</format>
<format>json</format>
</formats>
</configuration>
</plugin>
/etc/gitlab-runner/config.toml:
[[runners]]
...
executor = "docker"
[runners.docker]
disable_cache = false
volumes = [..., "/usr/share/owasp:/tmp/owasp:rw", ...]
...
.gitlab-ci.yml:
sonar:
stage: test
image: node:${NODE_IMAGE_VERSION}
needs:
- job: generate-version
artifacts: true
- job: build
artifacts: true
variables:
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar" # Defines the location of the analysis task cache
GIT_DEPTH: "0" # Tells git to fetch all the branches of the project, required by the analysis task
GIT_STRATEGY: clone
cache:
key: "${CI_JOB_NAME}"
paths:
- .sonar/cache
script:
# run dependency check here before sonar task is executed
- mvn ${MAVEN_CLI_OPTS} -Drevision=${VERSION} -DnvdApiKey=${NVD_API_KEY} -DassemblyAnalyzerEnabled=false -Dsonar.qualitygate.wait=true verify dependency-check:aggregate sonar:sonar
allow_failure: true
artifacts:
when: always
name: "${CI_PROJECT_NAME}-v${VERSION}-owasp-depcheck-report"
expose_as: "OWASP Dependency Check report"
expire_in: 7 days
paths:
- 'target/dependency-check-report.html'
There are several issues to consider:
Make sure your API key is working.
Test your API key running following command line:
curl -H "Accept: application/json" -H "apiKey: 1230b944-xxxx-xxxx-xxxx-c51993ff5a17" \
-v https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:o:microsoft:windows_10:1607:\*:\*:\*:\*:\*:\*:\*
You should retrieve a long Json output (describing public CVEs in Windows build 1607). If no JSON is returned and/or you see a 404 error the API Key is invalid and you should request a new one.
Such things may happen if you click the activation link directly from your mail application instead of copy and paste it into your browser. (Found this hint in one of Jeremy Long's postings, was helpful for me.)
Create local copy of US National Vulnerability Database
To prevent the US National Vulnerability Database being misused (including for DOS attacks), the database has introduced rate limits. Therefore, it is recommended that you have a local copy of its data.
If you do not address this issue directly, a local copy of the NVD will be created in your .m2 cache. This technique may not work if you run the Dependency-Check Maven plugin in a Docker container, as the container always starts with an empty cache, or in a CI/CD environment.
You may consider following options to handle this problem:
Create a copy in a public directory somewhere in your network
- Find a directory within your network to which both stationary processes and your Docker container have access.
- Create a frequently running job (crontab or whatever) which creates (within 1st run) and updates (within following runs) this local copy of the NVD database.
mvn org.owasp:dependency-check-maven:update-only
- The following example shows part of the necessary configuration. The names of the keys used follow the version of the plugin (12.1.3). In older versions of the plugin, they may have different names.
<configuration>
...
<nvdApiKey>1230b944-xxxx-xxxx-xxxx-c51993ff5a17</nvdApiKey>
<nvdApiDelay>16000</nvdApiDelay>
<dataDirectory>${YouPublicDirectory}</dataDirectory> <!-- put your directory path here -->
</configuration>
- Within your Docker container, it is only necessary to define the data directory; an API key is not required. In my plugin configuration, I set "nvdValidForHours" to 168 (one week) to stop the NVD being requested.
mvn org.owasp:dependency-check-maven:check
(My personal opinion: Watching what happens during checks of this local copy of the NVD I decided not to go this way.)
Create an instance of a SQL database
Plugin documentations describes steps to do so. You find an initial script to install required database objects of several database servers. Page shows an example plugin configuration as well.
I have successfully tested both PostgreSQL and SQL Server. The documentation mentions the necessary changes to ' dbStatements.properties ' to handle various SQL dialects, but does not explain how to make these changes. Nevertheless, I did not find these changes useful; everything worked straight away.
Security issues
Protect the API key!
Your API key could be misused by an attacker while they penetrate the US National Vulnerability Database .
According to the rate limitations defined by the US National Vulnerability Database (NVD), your key could be blocked for further usage and your local copy of the NVD will become outdated. Therefore, your application is free to include new vulnerable 3rd-party libraries.
Restrict writing to your local copy of the US NVD!
An attacker could delete specific entries from your database in order to hide known CVEs in 3rd-party libraries.
Do not restrict read access to the database
All this data is public anyway, and anyone can copy it themselves.
Separate processes for updating and querying local copy of US NVD
It is possible, and this is how it is configured in our system, to separate the processes of updating and querying the local copy of the US National Vulnerability Database (US NVD).
The following consequences arise from this separation:
- You only need read access to the database to check it. This makes it easier to hide the password of the database owner.
- You never query the original US NVD during dependency checks in your Jenkins build pipelines. Consequently nobody needs to know the API key.
- You need to specify how long your US NVD copy is valid for. This time is supposed to be a long time to avoid querying die original US NVD from CI/CD.
- The local US NVD copy is frequently updated by a separate process. This process - and this process only - needs to know the API key and the password of the database owner.