Shifting Left for Application Security

Chapter 1. DevOps and DevSecOps

The traditional software development process separated designing, building, testing, and shipping into separate phases that focused on creating monolithic applications. It seems obvious in hindsight that this approach was neither nimble nor efficient. As a response to ever-increasing pressure to move faster, Agile methodology made the pipeline more flexible by breaking large tasks into smaller units. As the workforce became globally distributed, it was no longer practical to tie everyone to a single codebase. Application architecture moved from a monolithic model to microservices, which allowed dispersed teams to work on different parts without blocking each other. The challenge of managing the development process for increasingly complex collections of microservices has given rise to continuous everything in the software development pipeline. This is where DevOps comes in.

DevOps

DevOps is a philosophy and a set of practices that encompass several goals. As the name suggests, DevOps brings development and operational support together, blurring the lines of responsibility between the phases of developing, building, deploying, and maintaining applications. This breaks down boundaries between the teams responsible for these phases, enabling them to establish continuous integration and deployment of applications and features. Figure 1-1 shows the phases in a CI/CD approach to software development and deployment.

Figure 1-1. Software development phases in the DevOps CI/CD pipeline

Continuous integration means merging code changes to a shared main codebase as quickly as they’re developed, keeping the codebase up-to-date with the latest of everyone’s work so it can be tested and released as soon as possible. Continuous deployment automates the release process, including tests that ensure the final product is ready to deploy. By merging and testing changes constantly, the DevOps pipeline reduces the risk of integration conflicts from distributed teams working independently.

At its heart, DevOps is about breaking down barriers wherever they prevent continuous motion in the direction of quality. Testing and feedback loops become faster, partly through a shifting left of these steps to earlier phases in the development pipeline, meaning that developers begin to take on more responsibility for testing their own code. DevOps relies heavily on automation to reduce risk at every step while improving the workflow of coding, testing, and deploying changes.

DevOps brings faster development and deployment with higher quality, fewer failures, and shorter recovery times. One concern that DevOps doesn’t explicitly address is security. The pressure to move ever faster has made it challenging for organizations to prioritize security, which is seen as a drag on the development process.

In the traditional waterfall development model, security was typically tacked on at the end. Figure 1-2 shows the waterfall approach, in which security often happens during the verification and maintenance steps.

Figure 1-2. The traditional waterfall development model for software development

This approach to security wasn’t effective in traditional monolithic software development, and it’s even worse for modern microservices-based applications. A new way of thinking emerged, to integrate security throughout the development process: the evolution of DevOps into DevSecOps.

DevSecOps

When development and security are separate, friction is a natural consequence. Developers might see themselves as the drivers of change, and security as a constant impediment. Security teams are known to bring development to a halt to perform audits or investigate incidents. At the same time, security teams see developers creating or ignoring the same problems time and time again, unable or unwilling to adopt clear solutions.

DevSecOps integrates security as a priority within DevOps, placing it at the center of application development and building a security-first culture among everyone in the software pipeline. In the DevSecOps model, security is everyone’s job. This is a first step in reducing friction between developers and security engineers.

Like DevOps, DevSecOps focuses on breaking down barriers between teams, making transparent communication easier. The goal is to build security into every product from the beginning, sacrificing as little speed and agility as possible during the development process. Just as DevOps gave developers more responsibility for testing their own code, DevSecOps makes building secure and compliant code every developer’s top priority.

DevSecOps builds security practices into every phase of the application development lifecycle, providing feedback at each step. Security often starts even before the design phase, in the form of training to help developers learn secure coding practices. Security teams work together with developers, helping educate them, documenting security policies and best practices, and coaching everyone to adopt a security mindset. As an organization’s DevSecOps practices mature, different teams begin to view themselves as part of a single culture with security as a central goal.

How DevOps and DevSecOps Are Changing the Organization

Whereas security was once an add-on feature at the end of development, DevSecOps has brought awareness that every component in an application can be vulnerable and must be secure by design. By bringing flexibility and transparency to the software development pipeline, DevSecOps has aided the move to cloud-first software, deployable in any environment. As more and more companies recognize the need to bring security into the core of development, DevSecOps is becoming mainstream. DevSecOps has proven to be a natural evolution of DevOps, just as DevOps naturally grew from Agile.

The cultural shift that DevSecOps represents is significant. Security and DevOps teams work with a common purpose: to bring high-quality products to market quickly and securely. Developers no longer feel stymied at every turn by security procedures that stop their workflow. Security teams no longer find themselves fixing the same problems repeatedly. This makes it possible for the organization to maintain a strong security posture, catching and preventing vulnerabilities, misconfigurations, and violations of compliance or policy as they occur. Developers, operations, and security teams work together on threat modeling, sharing knowledge to anticipate and close potential weaknesses in both the product and the processes involved in its development.

Beyond a change in attitude, DevSecOps provides tangible benefits. By catching problems earlier, organizations deliver better, more secure products and services to their customers. The end-user experience is better when there are fewer urgent patches or unexpected breaches. DevSecOps finds vulnerabilities earlier and fixes them before deployment. This results in less downtime for customers, making it a more cost-effective for the enterprise.

The Challenges of Adopting DevSecOps

Adopting DevSecOps practices has clear advantages, but that doesn’t mean it’s easy at every step. From the day-to-day mechanics of securing distributed applications to the heavy lift of cultural change, bringing DevSecOps into an organization presents challenges.

Traditionally, security focused on a well-understood application perimeter, usually surrounding a single data center. As the enterprise adopts DevOps and cloud native, microservices-based architecture, applications—and security challenges—decentralize. These applications are composed of microservices running in multiple environments, communicating across many networks, working with data from devices and users all over the globe. This makes the attack surface both difficult to define and very large. It’s nearly impossible to inventory all the interactions among services, or all the data transmitted across public and private networks.

At the same time, when application ownership shifts from teams to wider departments, it’s easy for security to fall by the wayside. Individual engineering teams don’t invest in security if they see it as a problem for a dedicated security team. This tends to push security rightward, toward the later stages of the software development pipeline, where security becomes more difficult and less effective.

Shifting left only works when developers understand security well. Not only do the developers need a good working knowledge of secure development practices, but they also need enough education to understand the issues they are tasked with fixing. This means training, which takes time and money.

The key to solving these problems is to create a culture of collaboration that supports rapid, continuous iteration with a security focus. That means many teams, once siloed, learning to work together: development, IT operations, and security. Rather than a continual interruption, security must become a practice incorporated in all aspects of work throughout the software development pipeline. Security teams must provide guidance rather than interruptions, becoming continuous just like the development and operations parts of the pipeline.

The good news is that the benefits outweigh the costs. When security becomes everyone’s job, problems can be resolved earlier, with less expense, providing a better experience for everyone involved in the development pipeline—and for the customers.