Skip to main content

Dependency Vulnerabilities Check

Why project dependencies should be checked​

JHipster uses many technologies, and the project is very careful at selecting them. But maybe the project missed one vulnerability in those many dependencies, or maybe you added or updated one dependency that triggered a new vulnerability.

According to OWASP Top 10 Most Critical Web Application Security Risks, using Components (ie. dependencies) with known vulnerabilities is ranked 9th, and there are many known stories of security breaches provided by (malicious or not) third-party dependencies.

Why the dependency check is not provided by default by JHipster​

Proposing a dependency check by default in JHipster build has been discussed a couple of times (#6329, #8191). To summarise, it is complicated to have a realistic report (removing false-positive) and context dependent (security is always a trade off between the actual risk/criticity and the effort to prevent it).

However we highly recommend using a dependency analysis tool such as Dependabot or Snyk if you are using JHipster in production.

What to do if you detect a vulnerability in one of JHipster's dependencies​

If you found a vulnerability in one of JHipster's dependencies, please check if there is not an existing issue already opened on that vulnerability.

If nothing is mentioned, please send us a security vulnerability report privately. Please read our security policy on how to send one. Include steps to reproduce the exploit, security report, blog post, etc.

Be sure that the JHipster team is committed to provide a high-quality, enterprise-ready and secure development stack and that this issue will be a top priority for us.

How to check a JHipster project's dependencies​

Checking on the Server side​

To check if a Java dependency has a known Common Vulnerabilities and Exposures (aka. CVE), visit the NIST National Vulnerability Database which maintains an up-to-date list.

The OWASP project provides Maven and Gradle plugins to check the whole dependency chain automatically, generate a report and even block a build (not recommended, it can be very aggressive when doing continuous integration).

Here is the documentation explaining how to read the dependency check report.

Using Maven​

See the OWASP Maven Dependency Check plugin documentation

Add the owasp dependency-check plugin:

<build>
...
  <plugins>
  ...
  <plugin>
      <groupId>org.owasp</groupId>
      <artifactId>dependency-check-maven</artifactId>
      <version>5.2.4</version>
      <executions>
        <execution>
          <goals>
            <goal>check</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  ..
  </plugins>
  ...
</build>

Running ./mvnw verify will generate a dependency check report under the target directory.

Using Gradle​

See the OWASP Gradle Dependency Check plugin documentation

Update the build.gradle file to apply the OWASP dependency-check-gradle plugin.

plugins {
  // Add the plugin in the existing plugins block
  id "org.owasp.dependencycheck" version "5.2.4"

}

if(project.hasProperty('strict-security')) {
  check.dependsOn dependencyCheckAnalyze
}

Running ./gradlew dependencyCheckAnalyze generates a dependency check report inside the build/report directory.

Updating continuous integration builds with a dependency check is done by running ./gradlew check -Pstrict-security

Checking on the client side​

Since version 6, NPM includes a security audit by default for each dependency installation. Check the About security audits page for more information.