This post is the latest installment in a series aimed at helping organizations adopt DevOps.

Tools used in DevOps environments such as continuous integration and continuous deployment speed up the process of pushing code to production. Often this means continuous deployment cycles that could result in multiple deployments per day. Traditional security testing, which often requires manually running multiple tests in different tools, does not keep pace with this rapid schedule. This blog post introduces a tool called Gauntlt, which attempts to remedy this issue.

The idea behind Gauntlt is to make writing rugged code easier by allowing developers to turn security testing into code. This approach, in turn, simplifies the integration of security testing into the deployment and testing processes. Gauntlt provides adapters for curl, nmap, sslyze, and garmr and also features a generic command line adapter to run any command line tool.

One of the greatest changes to software engineering that DevOps presents is getting developers and operations together collaborating during the entire systems development lifecycle (SDLC). Adding security testing into the SDLC will help to reduce some problems with security testing. Often security testing is done after the fact and then solutions are bolted on. Security testers, developers, and operations staff often work in silos, which reduces communication. This isolated work environment also means that when security flaws are found in software or infrastructures, disputes will rise. Because security testing is typically done so late in the process, it can become costly to add required security solutions. In addition, flaws might be missed when testing is done on a large code base.

Gauntlt allows development and operations teams to collaborate with security testers and work side-by-side throughout the SDLC by enabling the performance of security testing via test scripts, which can be incorporated into the continuous integration process. This approach helps move security testing left, from the end of the process to the start.

The idea of having a single, readable test script lets developers and operations staff contribute and inspect the tests being performed. This collaboration helps prevent possible miscommunication about what should and shouldn't be allowed. Using this methodology, security testing engineers won't design tests with assumptions that developers aren't aware of, and developers will learn security practices and become better equipped to build in security up front.

In addition, Gauntlt enhances the reproducibility of security testing. Individual security testers can run any of the tools mentioned above and interpret the output and be effective. But, if the security testers are having an off day, or forget to run a particular test, they can easily miss important security issues. Gauntlt turns security testing into code and makes security testing easily repeatable by performing all security testing at the push of a button.

Launching Gauntlt for the first time requires a quick three-step process that's described at gauntlt.org. Once Gauntlt is installed, attacks can be written utilizing the tools provided. "Attack" is the terminology that Gauntlt uses to mean security test. Gauntlt provides some example attacks written for each of the adapters it handles.

The attack files are written using the Gherkin syntax as defined by Cucumber. Here is a sample attack that attempts to detect robots.txt files on a webserver. The @slow tag tells Gauntlt to allow for a 30-second timeout, @veryslow allows for a five-minute timeout. These timeouts prevent tools from holding up testing while allowing for flexibility for tests that might take longer to complete normally.

@slow

Feature: nmap robots attack

Background:
Given "nmap" is installed
And the following profile:
| name | value |
| hostname | www.cert.org |

Scenario: Detects robots.txt files on this host.
When I launch an "nmap" attack with:
"""
nmap --script http-robots.txt <hostname>
"""
Then the output should contain:
"""
| http-robots.txt:
"""

Overall, Gauntlt provides a powerful framework that can be used as a foundation for performing directed tests on a web project. With this tool users can begin to further automate their testing environment and simplify the interpretation of testing results. For more information on the syntax and how to utilize this tool see Hands On Gauntlt by James Wickett. The site includes a free sample that will help users get started.

Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication Aaron Volkmann and Todd Waits please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.