The Idea Behind Rugged DevOps

Whereas DevOps is IT at ludicrous speed, Rugged DevOps is a shift left to find a way to inject security into DevOps from the beginning, says Joshua Corman, CTO, Sonatype and Rugged DevOps founder.

One way to do that is for Rugged DevOps to establish security parameters and requirements, meet those requirements as the project progresses, and establish and enforce the automated application of new and existing pen tests on software as development teams deliver it to the internal staging environment, in order to confirm software quality.

Automating Pen Tests? Running the Guantlt Is One Way

Guantlt is a project and a platform for doing just that: developing tools to hook into pen tests and run them on internally-staged code. The Gauntlt project works to automate security testing using established tools, to disperse standard errors, and to fail code based on test results and software requirements. “The goal is to provide an automated way to attack your software because, what we need in DevOps is to find ways to automatically enforce security quality,” says Aaron Cois, Researcher, CERT Division, Software Engineering Institute, Carnegie Mellon University.

The industry is developing frameworks such as Gauntlt to support autonomously running pen tests on every newly staged release candidate in order to avoid involving or requiring any manual effort. These frameworks enable an automated system to run unattended tests up to several hundreds of times a day to keep step with as many potential new releases each day. We can’t expect limited human capital to run that many tests in succession. “We want coders to write that automated test once and then go off and do something creative that we haven’t already done,” says Cois.

All this is necessary to meet security quality standards while maintaining the shortest time to deliver each new release candidate with the confidence that development could release it to production at any time. “We want to fire off Rugged tests against that internal environment. Having that parity environment is what enables the development of more comprehensive and more interesting testing from a security perspective,” says Cois.

Teams must run pen tests on running code in an environment that mirrors production. That’s the only way to know whether the software will stand up to attack. Teams must be able to add new tests as new threats appear.

To automate a response to pen test results, coders write conditional ‘if-this-then-that’ rules into Continuous Integration to respond to conditions such that, for example, when any unit test fails, the system fails to build the software. “A lot of organizations start out by saying, well, we’re going to start writing security-focused unit tests and security-focused integration tests, getting our QA department involved and our Integrated Security Department involved early in that process, having them rating those tests and enforcing tests in Continuous Integration,” says Cois.

Impact: Rugged DevOps in Action

“Heartbleed and Shellshock were high-profile vulnerabilities that had been present in BASH and Open SSL for a long time and we didn’t know about them. We had to find ways to make sure we weren’t vulnerable to those,” says Cois. Using Rugged DevOps, the security team member can create tests for such new threats and require the tests using CI. As CD quickly fixes bugs, so Rugged DevOps can quickly defend against new threats.

One hope for Rugged DevOps is that it will bring truly secure coding even to COTS software as DevOps eventually envelopes all software development. DevOps should enable developers to continue to develop COTS software cheaply while adding the inherent security that would prevent a lot of the successful attacks on software that trouble industry today.

“I don’t know that we will reach that stage quickly since it certainly requires an investment,” says Cois. There first has to be that continued uptake of DevOps approaches and those changes in processes, culture, and mindset. Rugged DevOps has to accompany that or the eventuality of cheap and secure COTS software might never materialize.

Concluding Remarks

“People like DevOps because the concrete hasn’t dried yet and people are copying high performers. At the same time, programmers are assembling 90-percent more code from existing open source code,” says Corman. This is good news where those high performers and those who follow in their footsteps fail faster, fix errors sooner, and carefully consider security at every step, as this will magnify secure code. But developers have to build using the higher quality code those high performers are creating, says Corman.