The idea of building security into applications as they are developed versus bolting it on at the end always made sense but proved difficult to pull off in legacy environments. Monolithic software was too complex and the teams were disparate. But the arrival of containers 1) demands the need to attack the problem earlier because the attack surface changes so rapidly, and 2), thankfully, vastly simplifies the security process when DevSecOps principles are employed.
The DevSecOps movement, which builds on DevOps by stirring in security, has been steadily building momentum as containers shoulder increasingly critical roles in larger organizations. Heck, DevSecOps even has its own manifesto.
Although not all organizations adhere to the approach spelled out in the manifesto by DevSecOps.org (which says it was founded by “security practitioners dedicated to the science of how to incorporate security within agile and DevOps practices”), the core elements are the same: The goal is to shift left, as some people say, meaning start the process of securing applications earlier in the development process, improve communications, and repeatedly test along the way.
Adding the Sec into DevOps
Obviously, DevSecOps builds on DevOps, which is all about development and operations teams working more closely together to focus on the full life cycle of applications rather than one team focusing on the beginning of the cycle and the other on the end. DevOps is about breaking down boundaries of responsibility and modifying processes so the output is more resilient and code can iterate faster.
DevSecOps is all that plus security. “DevSecOps requires changing mindsets, processes and technology,” Gartner says. “Security and risk management leaders must adhere to the collaborative, agile nature of DevOps to be seamless and transparent in the development process, making the Sec in DevSecOps silent.”
The need to embrace the new approach is necessary because containers upend so many conventions.
For example, in the DevOps world security tends to be viewed as a tech thing. “Are we encrypted?” “Yes.” “Great. We have secure connections. That’s all we need to do.”
As containers become used for more mission-critical things, that approach is too limited because there are so many more moving parts.
Before you might have had to worry about securing a few physical servers and a few dozen VMs supporting an application, and now that application requires you to secure 200 to 400 containers, spread across a couple dozen virtual machines in both AWS and Google Cloud. The amount of work has multiplied by 10. The older security methodologies just don’t scale.
What’s more, there are more layers to worry about—your container runtime (Docker, RKT), your orchestrator (Kubernetes, OpenShift) and your build environment (Jenkins).
And with containers we release things faster. It isn’t once per quarter or even every month. With containers and microservices architectures and continuous integration/continuous development, we are pushing new versions of software into production on a daily or weekly basis. Existing security practices can’t keep up.
How Do You Do It?
There are a number of ways to realize DevSecOps, but typically organizations aren’t going to fully integrate security personnel into DevOps groups, or require developers to become security experts or security experts to become developers. That’s what Gartner was getting at with keeping the Sec in DevSecOps silent.
The movement is all about building processes and inter-team communications and workflows, which is also how DevOps started before it become more of a delineated role/persona. Yes, developers will have to learn more about security. Yes, security team members will have to learn some particulars about containers. And, yes, workflows will need to morph.
But the good news is that once experts from the various disciplines agree on what is important, many of the DevSecOps processes can be automated.
When to Test
Job one is figuring out where in the container development process code should be tested for security. The goal is to set up a series of gates developers have to go through to make the resultant code more secure. Typically—and most critically—it starts with scanning source code repositories.
So, before an app is even built, the code the developers are writing is being checked. Are they referencing a package with known vulnerabilities, or pulling in a library that has a vulnerability or is open source and against company policy? This a workflow change that starts the security process much sooner than traditional approaches.
The next check in the cycle typically comes when the container image is being built, say in Jenkins, the popular open source build environment. When the image is being pulled together, packaging the code up into a container and defining dependencies, a scan is done to ensure it is free of vulnerabilities and is configured to meet the best practices and policies defined by the organization.
And finally, when the image is pushed to the registry, the image is scanned yet again before it can be put into production.
All these checks are tied to your CI/CD pipeline and just become part of the developer’s build process. The scans themselves are automated.
“The goal of CI is to provide rapid feedback on disparate code changes, allowing developers to correct errors as soon as possible by identifying functional defects introduced into the larger code base,” according to eSecurity Planet. “In this environment, integrated security testing is needed to provide developers a real-time threat assessment of all changes they’ve made, regardless of their operational success in the larger code base. Without integrated security testing, there’s a risk of re-engineering solutions multiple times to address security threats detected long after functional solutions are accepted. That wastes valuable time, money, energy and effort.”
Gates = Slow?
Developers traditionally have viewed security as a necessary evil. They would build something, get it in staging, test it and then right before it hits production, some security review would identify 10 things that need to be changed.
Testing more often, earlier and using automated scans vastly reduces the chance there will be significant problems with the resulting application. So, while the idea of introducing testing gates into the development process might seem like something that would put off developers, the end result will more than make up for any inconvenience along the way. Instead of huge changes at the end, there are incremental fixes at different phases of development.
Companies are adopting many of the DevSecOps practices today even if they aren’t calling it that. DevSecOps is, after all, more of a process and a way of working rather than a specific role. Those practices enable organizations to move faster and improve the quality of the services they deliver from a risk, security and compliance perspective.
Of course, there is no such thing as 100 percent security, and vulnerabilities will still crop up and be exploited. But even here a DevSecOps culture can be a huge step forward for container environments.
In legacy enterprise environments, when a vulnerability is found in something that is running live, the organization would identify it as critical and have a service level agreement that called for it to be patched in two weeks. The patch needs to be developed and the deployment planned, and probably includes some amount of infrastructure management and updating.
With DevSecOps and container environments, you can make the change in development and push it out within a day.
So, even as containers change the security calculus by introducing more and new things to worry about, with the adoption of DevSecOps best practices organizations should come out being more secure and fleet of foot.
