Continuous Security with OWASP's Dependency Check Maven Plugin

devops • documentation • github • java • maven • security • software • Spring

22 Dec 2015

Comments

On the heels of the previous post about continuously delivering documentation I wanted to show how easy it is to integrate dependency vulnerability checks and reports into a Maven-based delivery pipeline. The OWASP Top 10 2013 contains an entry about Using Components with Known Vulnerabilities, so being able to check project dependencies against a canonical list of vulnerable libraries is critical to compliance with the Top 10. The OWASP Dependency Check utility uses NIST’s National Vulnerability Database (NVD) to identify the vulnerable dependencies, so the list is always up-to-date.

The Dependency Check utility is conveniently wrapped by the dependency-check-maven plugin. The usage information contains several examples and the configuration allows plenty of tuning for the analyzer. With a single configuration parameter the plugin can fail a build if a vulnerable dependency is found.

CVSS Scores and the POM

The Common Vulnerability Scoring System (CVSS) uses several aspects of exploit-ability and impact to determine a base score. Each vulnerability in the NVD has a base score attached, and anything above 4.0 is considered Medium or High severity (CVSS overview).

Events following the publishing of a CVE can affect the CVSS score (e.g., an exploit kit is published). These adjusted scores are referred to as temporal scores, and CVSS provides a calculator to help understand the effect. The calculator is also quite handy to help understand what influences a score.

Thanks to the examples, configuring the POM is quite easy. Here’s the configuration I’m using in my pom.xml:

<project>
    <build>
        <plugins>
            <plugin>
                <groupId>org.owasp</groupId>
                <artifactId>dependency-check-maven</artifactId>
                <version>1.3.3</version>
                <configuration>
                    <cveValidForHours>12</cveValidForHours>
                    <failBuildOnCVSS>4</failBuildOnCVSS>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

The configuration above will fail the Maven run if a dependency with a CVSS score above 4 is found and will recheck the NVD only every 12 hours. To run a standalone dependency check:

mvn dependency-check:check

Report Integration

Integrating a dependency check report into the generated Maven site is also quite easy thanks to the examples. Here’s the relevant snippet of the pom.xml:

<configuration>
    <reportPlugins>
        <plugin>
            <groupId>org.owasp</groupId>
            <artifactId>dependency-check-maven</artifactId>
            <version>1.3.3</version>
            <configuration>
                <name>Dependency Check</name>
            </configuration>
            <reportSets>
                <reportSet>
                    <reports>
                        <report>aggregate</report>
                    </reports>
                </reportSet>
            </reportSets>
        </plugin>
    </reportPlugins>
</configuration>

A “Dependency Check” link will be added to the Project Reports page of the generated site that points to a page that looks like this:

For illustrative purposes I included a known vulnerable dependency. Running mvn site didn’t cause the build to fail because the plugin configuration used during the site lifecycle phase is separate from what was defined for the standalone check.

Summary

While not a full solution for security in your continuous delivery process, the dependency-check-maven plugin is a great way for a Java project to check the A9 box on the OWASP Top 10. Additionally, the visibility that the report gives dependency security is fantastic.

One handy feature I didn’t mention is that a suppression list can be used to ignore positives. This can be used for false positives, or to ignore acknowledged vulnerabilities currently awaiting resolution in the backlog. This would allow the CI process to continue to run while the project is brought into compliance.