Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Jenkins users can shore up software security with plugins

Fahmida Y. Rashid | April 3, 2017
Safeguard the software you develop from the start with these Jenkins plug-ins and integrations, which automate security testing


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.


Previous Page  1  2  3  4  Next Page 

Sign up for Computerworld eNewsletters.