It’s hardly a controversial statement to say that DevOps is changing the way that organizations build and deploy applications. There’s plenty of material, stories, whitepapers and whole companies that demonstrate this trend. There are, however, a couple of things that make a discussion about security and DevOps important. First, while there are a lot of organizations that have adopted DevOps tools and processes, there are many, many more that haven’t. That means that there are a lot of organizations that will do so in the future. And where there is adoption, it’s not necessarily comprehensive. It may be that one group has done so, or that teams are using some tools, but not others. In other words, DevOps is still fundamentally an early-stage technological movement. The second reason is that DevOps is set to transform security, and no one is quite sure what that means, though there are a lot of opinions on the topic. Given that context, what should we be doing to secure this brave new world? We should start by looking at the pervasive industry problems. It’s tempting to start any DevSecOps discussion with technology. There’s a lot of it, and there’s always something new. But DevOps is really about solving a business problem, and so we should stay a level above the technology, at least for a bit.
Problem 1: Unacceptable Risk
A typical DevOps lifecycle involves pre-deployment testing, but rarely scanning for risks such as vulnerabilities, misconfigurations and compliance. It’s important to talk about risk broadly because all of these elements are real and can have a real impact on an organization. It’s tempting to focus on vulnerabilities, and it’s tempting to state that they all need to be fixed, but the reality is that ‘risk’ is broad and acceptance is organizationally specific. If risks aren’t caught prior to deployment of images to production, then unacceptable risks are also deployed.
Problem 2: Vulnerable Repositories
If you really think about it, every incident starts with some change. That change may, however, occur outside of your organization. Vulnerabilities are discovered all the time, and when a new vulnerability is published, an asset that you previously counted as acceptably secure might suddenly change state (though nothing on the asset itself has changed). Container repositories suffer from the same issue. If you’ve got a collection of images stored for use, even if you assessed them when they were added to that repository, they might become vulnerable over time.
Problem 3: Production Assessment is Too Late
A totally valid response to the first problem might be to apply the information security tools you have today to DevOps. These are tools that were largely developed to secure servers, workstations, laptops and network devices. Repurposing them for DevOps often results in questions like “can we put <security agent> in the running containers” and “can I scan the running containers for vulnerabilities.” These are patently bad ideas, but they are not sufficient, and perhaps more importantly, inefficient. Introducing security controls at the production end of the process, and then trying to address findings, is one way to create friction between DevOps and Security.
Driving Towards Solutions
It does no good to talk about problems without a discussion of the solutions. There are a number of requirements that apply here and it’s worthwhile to enumerate them.
Pre-Deployment Assessments
This is clearly a core requirement for any solution to the problems discussed above. Assessment must be done prior to pushing containers to production in order to catch risk before it’s exploitable.
Integration with DevOps Tools
In order to be effective in a DevOps environment, the solution must integrate with the tools that developers are already using. That means that it can’t require additional manual steps on a build-by-build basis, or that the developer go to a different tool to get results. DevOps is about velocity, so creating friction needs to be avoided.
Assessment Scope
Recall the difference between ‘vulnerabilities’ and ‘risk’ that was discussed above? It’s vital that the assessment provided actually identifies the risks that matter to your organization. There’s not such thing as a ‘security scan.’ There are scans for more specific risks, like vulnerabilities, misconfigurations, compliance. Leaving risk out of the process means letting it into production.
Accessibility
DevOps doesn’t usually happen in one team or one place (logical or geographical). When I say ‘accessibility,’ I’m intending to describe the requirement that the technology and people who need access to the solution can do so without substantially changing how they do their job. Part of the answer here is likely SaaS, but also elasticity to deal with the requirements of your business.
Policy Driven
Finally, risk is personal. A solution that finds all the bad things and then requires that you fix them in simply insufficient. As a team or organization, you need to define what level of risk you’re willing to tolerate, and then you need to be able to instantiate that as the quality gate in the solution. DevOps really is poised to change the security landscape. While there are bound to be more problems to solve that we haven’t discovered yet, there’s real work to be done here today. It’s not an impossible task, but it does take awareness and effort. Also, you can learn more about Tripwire's latest offering, Tripwire for DevOps. Tripwire for DevOps is a comprehensive security SaaS solution that runs both static and dynamic analysis on container images for vulnerabilities in a sandbox. It equips DevOps teams with a complete security assessment of new application builds as they move through the continuous integration and continuous delivery (CI/CD) toolchain from development to production, providing a quality gate teams can use to fail builds of applications that don’t meet security compliance and configuration standards.
