Automating DevOps – The technology missing link
© Shutterstock / By Den Rise
One of the hottest topics nowadays, DevSecOps also happens to be brand new so in order to put it into practice, we need to understand it better. First off, we need to take one crucial first step: incorporate automated security scanning. Here, Dr. Rao Papolu looks at the basic stages of this process.
The typical narrative around DevSecOps focuses on people and process, often highlighting the need to change how individuals interact with code development. A shift-left in the introduction of security, to where the issues are most readily identified, is a smart move. But it’s only part of the answer. The technology must be in place to permit the required automation, otherwise, DevSecOps is just a word.
People and process
This is where the ability to automatically assess code against a security baseline comes into play as a valuable first step towards true DevSecOps. By 2019, more than 70% of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open source components and commercial packages, up from less than 10% in 2016, according to Gartner.
The Gartner report details the top strategies for overcoming hurdles to DevOps in regulated situations. Beyond closer collaboration between DevOps and InfoSec, we find automated testing, automated deployment, automated workflows, and automation of manual steps. The move to automate security scanning is a natural first step that will establish a solid foundation for every new code development.
Organizations need to be able to quickly test their security policies and ensure that they’re meeting regulatory requirements and adopting the right security posture. But this shouldn’t be a one-off test, with something like PCI DSS, 100% compliance at the start isn’t enough, it must be maintained. Verizon’s 2017 Payment Security Report found that PCI DSS compliance jumped from 11% in 2012 to 55% in 2016, but almost half of companies fell out of compliance within nine months. To combat this risk, automated security scanning must be baked into the process permanently. Luckily, that’s perfectly achievable.
What does automatic security scanning look like?
The workflow described below can serve as a template for teams who wish to bring automation into any phase of the CI/CD process. The overall environment consists of a CI/CD system, in this case, Jenkins, an API-driven assessment platform with documentation of the different GET, POST, and PUT commands; a shell script that communicates with this platform, thus automating security; and for this example, the Docker Hub.
The workflow is as follows:
1. The developer initiates the build via the CI/CD platform.
2. As part of the build, there is a trigger to call the script. This is no more difficult than adding an additional build step.
3. Now moving over to the actual script, the first step is to pull the required Docker image from the repository, in this case, the Docker Hub (docker.io). The script should be versatile enough to pull an image from any public or private repository. Via an API call, the script pushes the Docker image to the assessment platform.
4. The next step is to select the policy framework. Here, we select Docker Image Scanning since we wish to assess the Docker image, but the script is versatile to handle other types of frameworks. For example, the goal might be to automatically assess the PCI security posture of a new virtual instance. In this case, the assessment platform would compare a PCI framework against the newly created server.
5. Finally, the script triggers the actual assessment. To the left of the workflow diagram is a snippet of the API call for this action.
6. The platform assesses the image against the policy framework and then generates a risk score, in this case, ’80.’
7. The script includes logic to compare this score against the threshold that the developer sets.
8. If the score is >= to ’75,’ this image is considered secure and is automatically promoted to the next step. Conversely, if the image score is below ’75,’ the image is considered insecure, and the developer is notified.
API Call: Docker image scan Jenkins build and script technology
Together, the overall logic flow, the API-driven assessment platform, and the scripting form the score of the security automation. These can be generalized to support additional security tests and invocation at multiple stages within the CI/CD process.
Automating DevOps, and therefore enabling DevSecOps, requires a combination of people, processes, and technology. With automated code assessment to flag security issues, the previously missing component – technology – is no longer a gap in success.