Developers keep finding new ways to deliver higher-quality software faster—and . But to avoid introducing new flaws at that same hurry-up pace, security needs to be integrated directly into the development lifecycle.
For many modern dev shops, (continuous integration/continuous delivery). Jenkins and its community have given rise to hundreds of plugins, including those that automate security. There’s no reason why repetitive tasks, such as determining how an application handles malicious inputs or checking for known vulnerable components, must be performed manually. Jenkins’ thriving marketplace of plugins can deliver the automated security testing you need.
Developers want fewer roadblocks and organizational silos, so they can focus on code. Automated unit, integration, and acceptance tests act as critical quality controls in CI/CD because they assure developers that they’re working on stable code. If automated tests fail, then developers know a bug that needs to be fixed—before software reaches production.
Jenkins is highly extensible, so the first and most obvious approach is to download security plugins from the Jenkins marketplace. But you can also integrate Jenkins with external security platforms, so Jenkins can kick off the tests on the scanner and retrieve the results. Finally, if the security testing tool can run from the command line or from a Docker container, it’s trivial to invoke them from Jenkins Pipeline (the suite of plugins that automates CI/CD).
to get the latest version of the tool.
ZAP analyzes the code to find security vulnerabilities in the application and generates an XML, XHTML, or JSON report listing all the issues found and the corresponding threat level for each. For example, ZAP would be able to flag error messages or warning text in the application that disclose too much information about the application’s file structure.
Once the plugin has been installed, create a postbuild step to automatically run ZAP. This way, the plugin will kick off the tests every time the application completes its build. It can also run prebuild as part of a Selenium test.
for Jenkins, as well. Ruby on Rails applications lend themselves well to continuous testing and automated deployments, so teams using Jenkins for Rails applications should go with Brakeman. By scanning the code after every push, Brakeman will be able to flag any security vulnerabilities the moment they are introduced.
Like OWASP ZAP, Brakeman generates a report of all possible vulnerabilities—errors and warnings—in the application and assigns a confidence level for each one.
Let Jenkins tell you what’s wrong
Security vulnerabilities can frequently be found by aggregating the information written to various logs during the build process, says R. Tyler Croy, a longtime member of the Jenkins community. He suggests using the to aggregate compiler warnings in the console log and other application log files. Developers can also create their own parser for new warning types.
The Warnings plugin is part of a suite of static code analysis tools in Jenkins, which includes the Task Scanner plugin, Android Lint plugin, and the OWASP Dependency-Check plugin. The isn’t security-specific, but it’s useful because it looks for open tasks within the workspace such as TODO, FIXME, or @deprecated. scans the Android project for potential bugs, performance, security, and translation issues.
The is a utility that looks at project dependencies and looks for known, publicly disclosed vulnerabilities. Considering a number of open source projects struggle with outdated, vulnerable libraries, having the dependency check during the build will help developers avoid this common issue. Too often, the dependency checks are spaced too far apart, and if the vulnerability is found in between, it won’t be detected until the next time the developer gets around to checking. Using the dependency check during every build will help detect those changes sooner.
The static code analysis suite relies on utilities provided by to visualize the results, generated trend reports, and display the actual source code where the issue was found, and by the to display the results in a combined trend graph.
Marking the build unstable
There is no hard-or-fast rule about whether security tests should block delivery if something fails. From a security standpoint, if the tests fail, the build should be marked as being broken. Code should get fixed right away and not let the vulnerability linger.
In the case of a security test plugin, Jenkins knows when a test fails. If the tests are run externally, helps aggregate information from the system into Jenkins. The testing platform typically offers a clear message indicating the tests passed, such as “0 issues were detected.” The plugin, executed as another postbuild action after the tests, can parse the output and look for the success message. If the string is not present, then at least one vulnerability was found, and the Finder plugin can be instructed to mark the build as unstable.
Whether or not the tests can block delivery is a decision that each team has to make. This is a cultural question: on how well security is integrated into the dev and ops teams, and not a technology or process question.
Integrating with external scanners
For many development teams, the reality is that Jenkins handles the builds and automated application testing and a dedicated security platform handles security testing. A series of scripts connect the two platforms, which makes the entire process brittle and difficult to maintain.
A number of commercial security scanners have released plugins to integrate with Jenkins, so it’s always a good idea to check if one exists. The plugin will let Jenkins retrieve test results and inform the developer of the issues at the same time it is providing information about other bugs. Don’t make the developers go to a different platform to find out about the issues if they can be presented at the same time.
- IBM Security has a static code analyzer, , and a dynamic scanner, . Instead of using custom batch jobs or scripts to perform automated scanning, set up the job within Jenkins to kick off the tool, and the plugin will work with the provided configuration rules to take care of the rest.
- The automatically triggers Appspider postbuild. The generated report is stored in the plugin’s workspace, so developers don’t have to go to the Appspider Enterprise web interface to see the results.
- VAddy is a cloud-based security scanning service that runs end-to-end black box security tests for SQL injection, cross-site scripting, remote file inclusion, command injection, and directory traversal vulnerabilities on web applications, forms that use CSRF tokens, and REST API servers. It, too, has a Jenkins plugin. Set up the with the host name of the server containing the application, and it will initiate the scan after Jenkins postbuild. (Don’t use VAddy to scan production servers!)
- There’s no reason why Docker images can’t get some security testing, as the can look for vulnerabilities inside Docker. For the plugin to work, Docker must be installed on the same machine as Jenkins because the scanner itself is deployed via a Docker container and the
jenkinsuser added to the
dockergroup. The plugin can scan a local image or a hosted image.
- HPE Security’s cloud-based application security testing service can be called as a postbuild action via the plugin. Once the plugin is installed, the code can be uploaded from Jenkins to the cloud service for static application security testing every time a build completes. The plugin can also be configured to scan open source libraries and third-party components to look for known vulnerabilities, improperly used licenses, and outdated versions.
- Teams that use Contrast Security’s Contrast Enterprise for their vulnerability management can install . The postbuild action compares the number, type, and severity of vulnerabilities against a predefined threshold; if there are too many, indicate that these are showstoppers and need to be fixed.
- Black Duck Software offers a for Jenkins, which helps identify known vulnerabilities in open source components, set up open source security policies, identify license issues, and detect modified open source components. Much like the OWASP Depedency-Check mentioned earlier, Black Duck Hub informs developers of problematic dependencies earlier in the lifecycle.
Expand the tool set
The list of security plugins specific to Jenkins is still fairly short, but there are plenty of commercial platforms that can integrate with Jenkins. For the bulk of open source security testing tools, however, the best option is to set up the tools inside Docker containers and invoke them from Jenkins.
For example, is an open source security tool that runs other security tools, such as nmap, to run attacks such as cross-site scripting and SQL injection against the application, or to find insecure configuration settings. Gauntlt typically runs on its own server; an easy starter gantlt-starter-kit VirtualBox virtual machine provisioned via Chef helps teams get started with the tools, dependencies, and common tests. Gauntlt can be set up within a Docker container, and from there it can be integrated with Jenkins.
Built on Cucumber, Gauntlt provides developers, security, and operations a common natural language framework for understanding the issues found. One build command can kick off thousands of security tests, scans, and attacks specifically written for the application, and when the tests complete, Gauntlt exits with an easy-to-read message and a meaningful exit code. This can be parsed using the above Finder plugin.
is another open source security testing framework that relies on other tools. Essentially a set of features, BDD Security uses Selenium, OWASP ZAP, and . BDD-Security relies on Selenium because it tests web applications and APIs externally, and it doesn’t require access to the code. There’s no need for plugins, since BDD-Security’s JUnit output can operate directly with Jenkins. It works with the Gradle build system, you can opt for the Gradle build task to kick off the tests, then add a postbuild action in Jenkins to publish the JUnit test results.
Bring security health checks to the application
Security testing frequently falls by the wayside because developers feel there’s no time to do them. That’s true—if the plan is to do a top-down penetration test or a full-blown code analysis assessment. But many of the security vulnerabilities that plague modern development can be flagged long before the application is ready for a complete assessment. Static code analysis can be done on each code commit and penetration testing can be completed as part of the deployment phase.
Checking every time the software is built to see whether any of the included open source components is outdated or vulnerable can stop a whole range of potential security vulnerabilities and, even better, be automated easily.
Security is an underappreciated aspect of software development. One of the least obtrusive and most effective ways to ensure security is to integrate security tools into a developer’s existing arsenal. If Jenkins is your CI/CD server of choice, you have an abundance of automated security tools to help your teams detect vulnerabilities earlier and maintain reliable software. In the end, everyone benefits.