Jenkins users can shore up software security with plugins

Jenkins users can shore up software security with plugins


Developers keep finding new ways to deliver higher-quality software faster—and automation is playing a big part in that transformation. 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, Jenkins has become the open source engine of CI/CD (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.

[ 18 surprising tips for security pros. | Discover how to secure your systems with InfoWorld’s Security Report newsletter. ]

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

By adding these security plugins to Jenkins, security intertwines with development, so it’s far more likely that developers will write better, safer code.

ZAP web app flaws

The open source Zed Attack Proxy (ZAP) tool from the Open Web Application Security Project (OWASP) helps developers test for common vulnerabilities found in web applications, such as SQL injection and cross-site scripting. There are multiple plugins that claim to implement ZAP for Jenkins, but most of them are woefully out of date. Stick with the Official OWASP ZAP Jenkins Plugin 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. 

Brakeman for Rails

Brakeman is a widely used static code analyzer for Ruby on Rails applications; there’s a Brakeman Plugin 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 Warnings plugin 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 Task Scanner isn’t security-specific, but it’s useful because it looks for open tasks within the workspace such as TODO, FIXME, or @deprecated. Android Lint scans the Android project for potential bugs, performance, security, and translation issues.

The OWASP Dependency-Check 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 Static Code Analysis to visualize the results, generated trend reports, and display the actual source code where the issue was found, and by the Analysis Collector plugin 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, the Jenkins Text Finder Plugin 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. 

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, Gauntlt 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.

BDD-Security is another open source security testing framework that relies on other tools. Essentially a set of Cucumber-JVM features, BDD Security uses Selenium, OWASP ZAP, and SSLyze. 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.