Open Source InfoSec Using Gradle

Information security needs to be a part of any application. Solutions range in price from no cost to very expensive. However, quality is usually proportional to cost (but not always). We are going to look at no cost solutions that integrate with the Gradle build system.

Open Source Library Vulnerabilities

Libraries used in your application may have vulnerabilities that you don’t want to try finding yourself. There are third-party scanners that will inspect the binaries but these are expensive and time consuming. The CVE database is one publicly available database of vulnerabilities that can be leveraged to quickly identify offending libraries.

The OWASP Dependency Check plugin matches your dependencies against the National Vulnerability Database (NVD) hosted by NIST.

// build.gradle
plugins {
    id "org.owasp.dependencycheck" version "4.0.0.1"
}
 
dependencyCheck {
    format='ALL' // the default is HTML only
}
$ ./gradlew dependencyCheckAnalyze
 
Generating report for project pet-store
Found 175 vulnerabilities in project pet-store
 
 
One or more dependencies were identified with known vulnerabilities:
 
springloaded-1.2.8.RELEASE.jar: ids:(cpe:/a:springsource:spring_framework:1.2.8, org.springframework:springloaded:1.2.8.RELEASE) : CVE-2011-2730, CVE-2013-4152, CVE-2013-6429, CVE-2013-7315, CVE-2014-0054, CVE-2014-1904
scala-library-2.12.3.jar: ids:(org.scala-lang:scala-library:2.12.3, cpe:/a:scala-lang:scala:2.12.3) : CVE-2017-15288
...
 
$ ls -1 build/reports/dependency-check-*
build/reports/dependency-check-report.csv
build/reports/dependency-check-report.html
build/reports/dependency-check-report.json
build/reports/dependency-check-report.xml
build/reports/dependency-check-vulnerability.html

In addition to the console output, it also produces a very nice HTML report and several machine readable formats.

OWASP Dependency Check Report

Static Code Analysis with SonarQube CE

SonarQube scans source code for quality issues. One area of quality is vulnerability scanning. SonarQube has both commercial and community offerings. It does require a database and server running, but for small projects it can be run on the development machine. There are Docker images available that make it easy to manage.

// build.gradle
plugins {
    id "org.sonarqube" version "2.6.2"
}
# gradle.properties
systemProp.sonar.host.url=http://127.0.0.1:9000
systemProp.sonar.login=abcdef0123456789
$ ./gradlew sonarqube
SonarQube Dashboard

SonarQube Dashboard from https://www.sonarqube.org

ZAP Dynamic Scanning

Dynamic scanning is attacking your application (in this case a web application) as it is running to find vulnerabilities. It’s the equivalent of end-to-end testing for security and as such the most expensive. The most thorough dynamic scanning is done by humans but tools can reveal quite a bit so it’s worth automating.

OWASP ZAP is an open source tool with an impressive API allowing automation. I improved upon a Gradle plugin to facilitate automation. My plugin source is at https://github.com/double16/zap-gradle-plugin, credit to https://github.com/PROSPricing/zap-gradle-plugin.

// build.gradle
plugins {
    id 'com.patdouble.zap' version '2.0.2'
}
 
zapConfig {
    applicationUrl = "http://localhost:8080/"
}
$ ./gradlew zapStart runApp zapSpider zapActiveScan zapStop
$ ls -1 build/reports/zap
zapReport.err.log
zapReport.html
zapReport.json
zapReport.md
zapReport.out.log
zapReport.xml

OWASP ZAP Report

The complexity of using this plugin varies with the application. It needs to know the URLs to scan which may or may not need authentication. You must code that authentication into the build script. As you add protections, such as CSRF tokens, you will need to account for that in authentication. The plugin source has examples for some popular vulnerable web applications.

Spidering starts at a known URL (such as http://localhost:8080 seen above) and visits links to try to get all the URLs of the application. This has various levels of success. If you’re using functional tests that drive a web browser, you can configure the web browser to use ZAP as a proxy and thereby populate ZAP with the list of URLs. The zapSpider task won’t be needed and zapActiveScan will use the URLs visited in the functional test.

You may also consider using this plugin to validate specific vulnerabilities or key areas and not spider and scan the whole application. Note that with all of the ZAP plugins installed, it can take a bit of time to scan the whole application.

Conclusion

Every application must be secured at some level. For application developers it can feel like a tax to be paid. Any pieces of the puzzle that can be automated will increase the quality of the code. As every user base and organization is different, be sure to carefully consider where automation fits into your security posture.

Happy coding!

Leave a Reply

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

*

*