The best open-source DevOps security tools, and how to use them

As applications continue to move online, more companies and development teams are adopting a process of continuous software development and deployment, such as DevOps. By the end of 2016, 74% of companies will have adopted DevOps, up from 66% in 2015, according to a survey published by cloud-management firm RightScale

In such an environment, improving code security requires more than just the regular application testing. While there are a number of tools that are built by security vendors that are supporting security professions, developers need a different set of tools when it comes to DevOps and application security, because security must be continuous as well, says Derek Weeks, vice president and DevOps advocate for software-management firm Sonatype. 

"If you are doing continuous delivery, then you are making hundreds of changes to your environment every day," Weeks says. "The old process does not work. If you are trying to check all components at the end of the development lifecycle, you are in for a lot of rework."

While many DevOps security tools cost money, developers have a lot of open-source choices as well. Companies do not have to break the bank on services and software to better secure their development process and the code it produces.

Securing code in a DevOps development environment requires managing the software supply chain and checking the security of common components and frameworks, adopting a framework to automate testing, using fast static analysis tools, and automatically scanning for vulnerabilities. While companies can adopt paid services, many of the open-source offerings are strong contenders or can give developers a good start.

SANS 2016 State of Application Security Report

Secure the 80% first

The first step is to check the open-source libraries and common components—the software "bill of materials"—for vulnerabilities. 

Open-source software management tools can create local repositories of vetted software libraries and code that a company has deemed acceptable. Sonatype's Nexus Repository OSS, JFrog's Artifactory, and the Hakiri Toolbelt are open-source programs that help developers create such repositories and make sure that they are using the latest version. In addition, the OWASP Dependency Check tool will check which components are used by the application and then discover whether those components have known vulnerabilities. 

Focusing on the open-source program component is important because it makes up the largest chunk of code in any application, Sonatype's Weeks says. "When you look at the open-source components, they form 80% to 90% of the application footprint today, and the rest is custom code," he says. "So when you are looking at the open-source components, they are the largest part of the application." 

The average company downloads nearly 230,000 components every year, and 6.1%—about 14,000—of those code objects have known vulnerabilities, according to data from Sonatype.  

Create a test framework to automate checks

Test-driven development is giving way to a more business-focused version of creating application requirements based on user needs. Known as behavioral-driven development, the technique mines user stories for cases that can be implemented as tests. While many of these tests validate the behavior of the program, a variety of open-source security-focused frameworks are available as well. 

Three popular tools are Gauntlt, Mittn, and BDD-Security. Gauntlt focuses on Ruby development, Mittn on Python development, and BDD-Security on Java development. The tools allow a developer to create checks based on use cases. Developers can also code checks to catch mistakes that they have made before, says James Wickett, senior engineer at Signal Sciences and a developer of Gauntlt.

"You focus on something that you have seen before but that you don't want to happen again," Wickett says. "We have taken stuff that you would get flagged from and then created the feedback loop to your operations and your development team."

Those three tools are not the only choices. The Robot Framework is not specifically meant for security, but it is increasingly gaining test libraries that bring security assurance.

Constantly check code

Static source-code analysis has come full circle. The security technique, which analyzes code for known vulnerabilities, was once very simple, but static-analysis tools have become more comprehensive, and slower—they are typically run after major code versions are completed. Yet, for DevOps developers, faster code-checking tools can be easily incorporated into the software development cycle.

The open-source Brakeman, for example, checks Ruby on Rails code for common vulnerabilities. Developers initially adopted the tool because it was fast, running it on every code commit, says Justin Collins, the original creator of Brakeman and co-founder of Brakeman Pro.

"People were surprised that you could run a security tool in a few minutes and have it in-line in your security process," he said. "It was one of the security tools where people knew they could run it every time they committed code and they knew it would not get in the way."

Other static code checkers include Rubocop and a great number of basic syntax checkers known as linters. These tools—called linters after the Unix utility lint—check different types of programming languages and configuration files. SCSS Lint, for example, checks SASS files—a dynamic type of cascading style sheet (CSS)—while ESLint checks JavaScript code. While not security tools per se, these basic static code checkers look for correct syntax, which can help programmers more easily see mistakes.

Getting offensive with attack testing

When code is deployed, whether in a testing or production environment, developers and security operations can use automated attack testing to search for common exploitable flaws. 

Open-source tools such as the Metasploit Framework, OpenVAS, and Arachni all allow attack testing to be automated. The Metasploit Framework can attempt specific exploitation of issues, while OpenVAS makes scanning a network for vulnerabilities easier. Finally, Arachni is a Web application security scanner.

While open-source tools are great for development teams that are tight on cash, running an entire DevOps development process on open-source tools would be difficult. "I'd love to say, 'Yes, it's possible,'" says Signal Science's Wickett. "It depends on [software-development] stack. In many cases, running all your security testing and code checking just through an open-source stack may not be possible for you."

In addition, before a DevOps team adopts any tool, it should make sure that it is actively maintained, such as having commits in the last three to six months. "There are also quite a few that get abandoned and lose their usefulness," Brakeman's Collins says. "People start with good intentions and they kind of die out." 

Is open source alone up to the job?

Many of the tools used for DevOps-style development originated in an open-source project, so developers have good choices to help them test and improve the security of their code. Open-source tools are great as a way to try out DevOps-focused security processes and experiment with different changes to the development process to enhance security.

However, DevOps experts warn that the tools typically are not sufficient and can require a lot of time to set up. Yet they do, in many cases, lead directly into a more user-friendly paid service, allowing developers to upgrade their process, if the tool is working well for them.

SANS 2016 State of Application Security Report
Topics: DevOpsSecurity