“We can’t just stop at Dev and Ops. We have got to have security.” -Ernest Mueller, the agile admin
In 2010, Ernest Mueller and James Wickett began applying “rugged” principles to the rapidly evolving DevOps paradigm. At the time, their core concern was, as stated above: “We can’t just stop at Dev and Ops. We have got to have security.”
Rugged DevOps as a technique was borne out of the views expressed in Josh Corman’s RuggedSoftware. The rugged DevOps vision is an approach to software engineering that ensures that code is secure at all stages of the engineering lifecycle.
The popular tagline of Gauntlt, one of the first open source Rugged DevOps tools, is “Be mean to your code and like it.” The essence of this is that software engineers should seek to be as mean to their code as an adversary would, and instead of just breaking things, focus on cultivating a learning culture that emphasizes building more resilient systems.
Whether you’re just getting started or seeking to improve your continuous delivery practices, here are 7 open source rugged DevOps tools to consider.
Gauntlt: The ruggedization framework for DevOps
Gauntlt provides hooks to a variety of security tools and puts them within reach of security, dev, and ops teams to collaborate on building rugged software. It was the collaboration between these groups that drove the initial development of Gauntlt. This may sound like an odd thing for a tool to do, but Gauntlt used a style of development testing called behavior-driven development (BDD), which uses easy-to-read, plaintext tests that have become popular among developers and testers alike.
Gauntlt achieves collaboration between groups by using attack files that are plaintext and easy to read. Attack files are unique to Gauntlt, but they are written in Gherkin, a language and style that is very familiar to BDD testers.
Here is a simple attack file in Gauntlt:
Feature: Look for cross site scripting (xss) using arachni against our site
Background:
Given "arachni" is installed
And the following profile:
| name | value |
| url | http://localhost:8008/login |
Scenario: Do a full xss check and verify no issues are found on the login page
When I launch an "arachni" attack with:
"""
arachni --checks=xss* --scope-page-limit=1 <url>
"""
Then the output should contain "0 issues were detected."As you read through the above attack, you'll notice a logical sequence of progression that hinges on Given, When, and Then. For this example, you do not need to be a security expert to understand what is being tested and the expected output. Even if you have no familiarity with the attack tool Arachni, you know that the test should exit with “0 issues were detected” and that any other output would fail.
For more in-depth coverage of Gauntlt, James Wickett wrote a course called “DevSecOps: Automated Security Testing,” available on LinkedIn Learning and Lynda.com.
Vault: Secrets management
Vault, an open source tool by HashiCorp, was conceived with the specific intention of improving how software teams store important keys, tokens, passwords, and other secrets in their projects. Vault is an environment- and infrastructure-agnostic open source toolset dedicated to secrets management.
Surprisingly, Vault is still the go-to tool for most software developers to solve this problem. Due to Vault’s highly extensible and software engineer-targeted nature, it has developed a strong open source community, detailed public-facing documentation, and a plethora of examples. Vault’s dynamic secrets functionality significantly reduces the administrative overhead of secrets management by provisioning, rotating, and destroying secrets on the fly via its API.
If you haven’t checked out Vault, we highly recommend doing so. It takes only a few minutes to get it up and running from source or from the official container image.
OWASP Dependency Check: Software dependency security
How many lines of code does your application have—100? 1,000? 1 million?
The answer depends on how you count your application code. Do you count only the lines of code that you have written or do you include the libraries you inherit? The reality is that our apps are more than just our code; they also include libraries and dependencies that we don’t control or even have a hand in writing. Enter OWASP’s Dependency Check.
OWASP Dependency Check checks if there are any known, publicly disclosed vulnerabilities in your source code. It currently supports Java and .NET, with some experimental support of languages like Ruby, Node.js, and others. Setting it up is easy and it plugs into the CI/CD build system of your choice.
Retire.js: Insecure JavaScript libraries
Security doesn’t stop at your application server; it extends all the way to your customer’s browser, with all the JavaScript that you kindly loaded. As OWASP Dependency Check can tell you, JavaScript often suffers from bad hygiene and libraries and frameworks that have known vulnerabilities.
That's where Retire.js comes in. This tool evaluates your JavaScript libraries and dependencies and flags any known bad ones. This is a simple check you can add to your development test suite or put in your CI/CD build system (e.g., Jenkins) to break the build whenever it discovers a bad version of jQuery or any other dependency.
ChaoSlingr: Chaos engineering
ChaoSlingr leverages the power of chaos engineering to proactively uncover systemic weaknesses in cyber security tools, technologies, and response procedures through the process of failure injection. With ChaoSlingr, you can create your own security chaos experiments based on unique observations that you or your team encounter.
Chaos engineering helps teams address security weaknesses proactively by intentionally causing failure modes to determine how attack-ready our systems, teams, and technologies are. ChaoSlingr runs completely serverless, utilizing AWS Lambda, and comes out of the box with example security chaos experiments, a standard framework for creating your own experiments, and a Slack ChatOps integration. It is deployable through configuration-as-code.
InSpec: Secure configuration & compliance validation
InSpec, an open sourced toolset by Chef, provides a testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security, and policy requirements. Furthermore, it can be utilized for testing and auditing applications, infrastructure, and many other technologies in your environment to ensure consistent configuration standards throughout your builds.
InSpec compares the actual state of your system with the desired state that you express in easy-to-read and easy-to-write InSpec code. InSpec detects violations and displays findings in the form of a report that lets you control remediation. It provides some great ways to drive velocity, quality, and security by creating automated configuration validation tests that verify your builds consistently meet the baseline you set. Furthermore, InSpec reports can be used as compliance artifacts for audit and assessment teams to reduce friction in release cycles.
OpenControl and Compliance Masonry: Compliance as code
“How do I make this great piece of open source software secure and compliant?” -Greg Elin, GovReady
The fact is, today’s cyber compliance process isn’t scaling. Maintaining written documentation is too slow for the continuous development and delivery nature of modern systems engineering. Our compliance needs to keep pace with the velocity of open source, cloud, agile, and DevOps.
OpenControl is an open source platform for highly automated, user-friendly self-service compliance assessments and documentation. With OpenControl and Compliance Masonry, software engineers can focus on software engineering rather than becoming compliance experts.
Within the OpenControl framework, software engineers can painlessly represent individual parts of an application or organizational policy that deal with specific security requirements documentation in the form of simple YAML-based descriptions.
Example OpenControl YAML definition
documentation_complete: false
name: AWS Implementation
schema_version: 3.0.0
references:
- name: SC Policy
path: https://github.com/opencontrol/freedonia-aws-compliance/wiki/Security-Controls
type: URL
satisfies:
- control_key: AU-2
standard_key: NIST-800-53
covered_by: []
implementation_status: none
narrative:
- text: |
AU-2 - Audit Events
All AWS events are sent to AWS CloudWatch.
This is implemented with our Terraform build using the
`aws_cloudtrail` resource (https://www.terraform.io/docs/providers/aws/r/cloudtrail.html)
Compliance Masonry documentation is built using the OpenControl Schema, a machine-readable format for storing compliance documentation. It simplifies the process of certification documentation by providing:
-
A data store for certifications (e.g., FISMA), standards (e.g., NIST-800-53), and individual system components (e.g., AWS-EC2)
-
A way for security teams to edit existing files and add new control files for their applications and organizations
-
A pipeline for generating clean and standardized certification documentation
For years, compliance has constrained engineering teams' ability to drive velocity into their software delivery practices. It’s time to change this practice. OpenControl allows software engineers to write good software without the hassle of compliance documentation while providing auditors with up-to-date, relevant, and easy-to-use compliance artifacts.
There are opportunities to add security testing across the entire CI/CD pipeline. This approach embodies the wisdom of Shift left—moving security testing closer to development. It might be daunting to adopt all of these tools, so we recommend that you start small with a successful, repeatable security test rather than trying to do it all.
If you’re ready to make a change, experiment with these tools. Even if you implement only one or two, we guarantee it will make a big difference and perhaps change the way your organization thinks about security. A good place to start is with Gauntlt. The authors of this article are core contributors to the project and would love for you to join us in its Slack community.
1 Comment