DevOps becomes DevSecOps!

There’s some talk in the blogosphere about DevOps being overrated, but imagine the alternative: a world in which you could only release application updates every month, or every quarter.

Modern consumers expect businesses to deliver quickly on their demands, while maintaining quality. Likewise, businesses need to be able to quickly adapt to customer and market expectations, while staying profitable. These requirements drove the introduction of Agile development methods, which in turn spurred DevOps – the close communication and collaboration between software development teams and IT operations to support shorter development cycles and continuous delivery.

DevOps has delivered numerous benefits for organizations, including increased deployment frequency and improved efficiency. The problem is: where is security? There’s a need to shift from pure DevOps thinking to integrating security into the development lifecycle. This combination has resulted in the natural evolution of DevOps into DevSecOps.

Why DevSecOps is the future of cybersecurity

The concept of “DevOps” itself originated in 2009 through a presentation called "10+ Deploys a Day: Dev and Ops Cooperation at Flickr," but the practices and culture of DevOps evolved from the lean manufacturing approach developed by Toyota. The Toyota Production Systems is based on several key concepts that are recognizable in DevOps: automation with a human touch, continuous improvement, and just-in-time production.

As in the automotive industry, these concepts have allowed rapid scale deployment of code while maintaining quality. But legacy security processes are not able to efficiently secure modern applications developed using DevOps for a few reasons.

• Speed of change: The introduction of DevOps paired with cloud-based infrastructure means that the rate of change for a given environment has significantly increased. Legacy security technology and processes were designed for on-premise infrastructure and the waterfall software release methodology.

• Cloud-native development: On-premise network security operated under the assumption of a well-defined perimeter. The cloud architecture has a broader attack surface with a loosely defined perimeter.

• Containerization and Infrastructure as Code: The proliferation of containerization and Infrastructure as Code (IaC) means that applications typically specify the configurations for the containers and infrastructure on which they will run. This introduces the risk for  misconfiguration, but traditional security processes do not account for container and IaC security. The combination of the fast rate of change, the cloud-native nature of modern applications, and containerization and IaC means developers are increasingly responsible for ensuring the security of any code they release. This means security now plays a central role in DevOps.

How has culture shifted from DevOps to DevSecOps?

Here are several aspects of how the shift from DevOps to DevSecOps has impacted modern development workflows and tools.

DevOps VS DevSecOps responsibility comparison

Agile security

The Waterfall approach moves software efficiently from design and coding to the testing phase, but requires developers to circle back to the design phase if any issues (security or otherwise) are uncovered during testing. This approach can delay projects and also forces developers to use security features that are designed at the start of the process.

Agile security integrates security and other software testing practices as early as possible in the development cycle, allowing security vulnerabilities to be uncovered during coding. It also allows DevOps teams to integrate security and threat modeling into each sprint, which reduces the complexity of security measures.

Automation

Automation is frequently associated with continuous integration and continuous delivery (CI/CD) pipelines, which is a process where code is integrated into a single branch and then deployed into production in a streamlined manner. Since these processes are repetitive, they’re an ideal place to introduce automation. Automated CI/CD pipelines reduce the risk of introducing manual errors, allow developers to integrate testing earlier in the development cycle (resulting in earlier detection of problems), and allow the release of smaller changes which pose less risk to the system. On the other hand, CI/CD pipelines and related innovations such as open source software and containers have multipled the amount of software that needs to be managed.

Manually testing and verifying each software component is neither practical nor reliable, so it’s important to embed some form of security automation within CI/CD pipelines. Security automation can be implemented using SAST and SCA tools that scan code and give feedback to developers. This automated form of testing helps keep security feedback from becoming a roadblock or delaying elements in the pipeline, and provides a foundation for a DevSecOps approach to application delivery.

IaC and container security

Containers and IaC allow developers to configure infrastructure and the containers that applications run in, which gives them more control over deployment environments without needing to ask infrastructure teams to spin up new servers or manual configurations. This helps avoid hard-to-track errors in the configuration and maintenance of infrastructure, but also introduces new potential attack vectors, such as misconfigurations and insecure base images.

From a DevSecOps perspective, IaC and container security require checking code and enforcing policies from within developer workflows. This includes continuous testing of IaC for misconfigurations, scanning container images, automatically upgrading to more secure images wherever possible, and monitoring live environments for configuration drift before delivering feedback directly to developers.

Policy as code

The policies that developers and administrators need to follow were traditionally written and enforced using manual workflows and tools. This included knowledge around where resources should be allocated, which users should be able to access which resources, and so on. Policy as code brings policy into the DevSecOps world by documenting security processes using code. This allows for automated remediation procedures, scanning, access controls, and other security policies throughout the CI/CD pipeline.

Developer-first tools

It’s noteworthy that like DevOps, DevSecOps does not require any specific tools. Instead, it’s a cultural approach to application security. However, tools are a necessity for effectively implementing DevSecOps — particularly those that empower developers to take responsibility for application security, and tools that foster collaboration between developers, security, and operations teams. These tools support a shift left approach to security testing and feedback that implements security processes as early as possible into existing development pipelines.

Shifting security left makes it easier, and less expensive, to fix any issues that are discovered in code. It allows you to define and enforce secure coding standards, enabling you to find and fix vulnerabilities earlier. Furthermore, it removes the friction between developers and security teams that results when security teams discover issues in production and have to circle back to developers to request a fix.

The importance of putting developers first in security

Snyk recognized the increasing role of developers in the evolving DevSecOps approach to security and developed its Cloud Native Application Security solutions to ensure developers have the right tools to carry out their role. The traditional approach where security teams review code at the end of the development process — or in production — introduces bottlenecks and inefficiencies that don’t align with the DevOps model. The application itself has changed and now includes open source components and configurations for containers and IaC. Snyk’s tools allow developers to build security into the development process while improving the security posture of each component of an application in an automated and integrated manner.

To read some real-world examples of organizations who have adopted DevSecOps, check out our share the journey page.

FAQ:

What is DevOps?

DevOps is a modern development culture and methodology that ensures close communication and collaboration between software development and IT operations teams. This allows developers to release software on an Agile model with shorter development cycles, continuous delivery, and fast feedback loops.

What is DevSecOps?

DevSecOps is the natural evolution of DevOps. Legacy security approaches are unable to effectively secure applications built using DevOps methods. DevSecOps integrates security teams into DevOps processes, ensuring that security is built into applications as they are developed.

What is the difference between DevOps and DevSecOps?

DevOps focuses on improving the application development process from the developer’s perspective, while DevSecOps incorporates security into the DevOps process. DevSecOps is a more modern — and sustainable — approach to software development for today’s cloud native applications

What are the benefits of DevSecOps over DevOps?

DevOps methods allow for faster release cycles and help developers keep up with increasing customer demands, but often leave security as an afterthought. DevSecOps addresses this by building security into development workflows and tools.

Devops vs DevSecOps vs SecDevOps

While DevSecOps ensures that security is built into DevOps processes, it still places development first. SecDevOps, on the other hand, ensures that development processes incorporate security from the earliest planning and design phases all the way to deployment. SecDevOps is the natural evolution of DevSecOps in response to the fast-changing nature of modern cybersecurity threats.