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.

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 dependant (security is always a trade off between the actual risk/criticity and the effort to prevent it).

What to do 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 create an issue and follow the template (including 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

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).