Keep vulnerable libraries out!

Modern applications development is a mix of custom code and many pieces of open source. The developer is normally very knowledgeable about their custom code but less familiar with the potential risk of the libraries/components they use. A study from Black Duck which covers more than 200 applications shows that 95% of the projects use open source libraries (see open source security analysis). Important side note is we only use a fraction of all the libraries imported into a project.

Last couple of months some critical issues were found in Struts 2 which enabled attackers to perform a remote-code-execution through a malicious content-type.

One way to track whether you are using vulnerable components is to use the OWASP Dependency-Check. This tool uses the National Vulnerability Database to search components for well known published vulnerabilities.

Example

Let’s take a look at the well known Spring Pet Clinic project and integrate OWASP Dependency-Check, first we add the following plugin to the Maven pom.xml:

The plugin supports all kind of configuration items, in this example our build will fail if the Common Vulnerability Scoring System (CVSS) score if above 8.

CVSS is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat. Scores are calculated based on a formula that depends on several metrics that approximate ease of exploit and the impact of exploit. Scores range from 0 to 10, with 10 being the most severe. While many utilize only the CVSS Base score for determining severity, temporal and environmental scores also exist, to factor in availability of mitigations and how widespread vulnerable systems are within an organization, respectively.

If we run Dependency-Check the build will fail due to:

HTML report

If we look at the report we will see the mysql connector has more than 400 CVEs and the build fails due to the CVSS score above 8 (in this case there is even a CVE with CVSS score 10). Based on this score this library should be replaced with a more up-to-date version.

Because Dependency-Check offers many ways to integrate into your build pipeline it is easy to get it up-and-running. It is also possible to
integrate with Sonar which makes it even more visible to your team.

Don’t forget

The plugin is only triggered during the build phase. It is also important keep analyzing your software after it has been put into production. Make sure you run the plugin at least once a week and create organisational rules how to deal with new vulnerabilities.

Other tools

OWASP Dependency-Check is one of the tools you can use to scan your project for vulnerable components, there are also commercial tools available, like Nexus Firewall and snyk.io.

Conclusion

In our daily projects we use a lot of libraries, it is important to know if a specific version of a library has a critical vulnerability. Dependency-Check is easy to set up and it gives you the information you need next time your manager asks you: “Are we using this vulnerable component in one of our projects?

References

1. https://cve.mitre.org/
2. https://nvd.nist.gov/vuln
4. https://jeremylong.github.io/DependencyCheck/index.html
5. https://github.com/spring-projects/spring-petclinic
7. https://info.blackducksoftware.com/rs/872-OLS-526/images/OSSAReportFINAL.pdf

3 thoughts on “Keep vulnerable libraries out!

  1. Dat ziet er zeer handig uit, maar wellicht in de praktijk niet haalbaar. Je hebt geen controle over de libraries waar je zelf niet aan mee ontwikkelt, en soms laten nieuwe versies op zich wachten. Als wij deze check aanzetten krijgen we ook false positives, zoals op Lombok 1.16.18 en libraries van Spring Boot zelf (android-json-0.0.20131108.vaadin1.jar). Je build hierop laten falen betekent dat je niet meer verder kunt.

    Zie ook https://stackoverflow.com/questions/43978228/cve-2010-1807-vulnerablity-from-android-json-in-spring-boot-1-5-3

    • Hoi Rick,
      je kan altijd zelf nog een bestand aanmaken met suppressions voor false positives. Hiermee kan je dan aangeven dat je niet de functionaliteit gebruikt die de violation veroorzaakt. Vanuit de gemaakt HTML pagina is er zelfs een knop voor die de juiste syntax (XML) voor de suppressions file maakt.

Leave a Reply

Your email address will not be published. Required fields are marked *