Though most tech leaders and executives today are focused on time to market and building high-quality products, security can no longer be compartmentalized. Everyone agrees that things need to happen quickly - in the digital age, success is driven by agile frameworks (as per HBR). However, the soaring innovation that is so desperately sought sometimes ends up disturbing security.

The main issue within teams is that security isn’t thoroughly addressed until the end of the software development cycle when the product has been built. Software vulnerabilities become issues that need to be urgently resolved, and developers are forced to find creative ways to move quickly. Even if they’re successful in stabilizing the issues, there remain huge gaps in the feedback loops that contribute to what could be fully integrated and optimized teams. In the worst of cases, developers end up creating larger and more durable security problems by attempting to fix existing ones. That’s where DevSecOps comes in.

DevSecOps introduces a framework that bridges the gap between fast and secure software development. Sitting on the threshold between collaboration and automation, it focuses on security from the get-go, ultimately bringing faster development, smoother operations, and more efficient processes. In this article, I’ll be discussing the essence of DevSecOps, by going over how it works and talking about some of its different use cases. I’ll be considering the DevSecOps culture, process optimization, and technologies.

What is DevSecOps?

DevSecOps Defined

The easiest way to think of DevSecOps is to imagine it as an extension of DevOps, whereby the responsibility of security is shared across a whole team. Just as DevOps combines software development and IT practices for maximum security, DevSecOps is a cultural, software development, and engineering practice that creates collaboration around security.

Traditionally, vulnerability checks will be investigated at the end of the software development cycle, which involves numerous ball passes within teams, the fixing of expensive bugs, and a waste of resources and precious time. On the contrary, DevSecOps tests applications throughout the development phase, in a cyclical practice, therefore reducing friction, minimizing potential vulnerabilities post-launch, and saving astronomical costs on security and compliance fixes.

71% of CISOs estimate that their code has pretty major vulnerabilities before it’s sent to production. In the past year, it has been evaluated that 1 out of 3 businesses worldwide have experienced a security breach. The figures are alarming - there’s a burning need to change the way we view security from within.

How does DevSecOps work?

Because DevSecOps is more of a mindset than a status, it can take some time to work towards a cultural shift within an organization and/or team. A DevSecOps ecosystem can only be properly built if all elements are onboard: stakeholders, development teams, leaders, and executives alike should all be involved.

However, many companies have succeeded in adopting DevSecOps in the past few years, especially since COVID-19 and its lot of heightened security threats on spectacular levels worldwide. It is estimated that by 2022, 90% of software development projects will be leveraging DevSecOps practices. The usual workflow goes something like this:

Training

DevSecOps comes through providing teams with the right knowledge, and security-focused training. This can exist through virtual or in-person events with DevSecOps professionals and industry leaders, or by leveraging security certifications. I’ve seen it work best by appointing Security Champions into the development teams, who are driving security efforts end to end.

IDE scanning

IDE scanning is the process of giving security feedback to developers as they code in real-time. Developers are able to fix security issues as they go along, offering instant solutions to issues before they even grow into company-wide concerns.

Source code scanning

Source code scanning tests open-source integrations (components, source code, frameworks, plugins, libraries…) early on in the development phase. This helps developers produce thoroughly secure software and apps by going through breeches and bugs fast.

Static code analysis (SAST)

Static code analysis analyzes code while it’s not running

Dynamic code analysis (DAST)

Also known as black-box testing, dynamic code analysis tests running applications for vulnerabilities.

There are many other tools and practices that can be used as a part of a DevSecOps effort, like container security management and secrets management, etc. However, no matter how many technological practices are implemented, DevSecOps requires a top-down approach focused on the human factor, constantly raising awareness across all teams.

“Shift Left” Security - building a product right

Building the security within the product

In June 2020, the Cloud Security Alliance (CSA) published The Six Pillars of DevSecOps: Automation. It states: “Security can be achieved only when it has been designed in. Applying security measures as an afterthought is a recipe for disaster.”

The DevSecOps platform ShiftLeft conducted a survey of over 165 developers, DevOps professionals, and app security teams, of which 89% stated there was a disconnection between developers and cybersecurity teams that resulted in a deep inhibition of productivity. When security is implemented towards the end of the development process, development and security teams clash. Security has therefore been viewed as a halting factor to agile development. It doesn’t have to be!

The Shift Left mindset prompts teams to implement security earlier on in the Supply Chain. It is a methodology in which testing is moved left on the project timeline. Security is viewed as a continuous process, not a final, painful step in the development cycle.

Since Gartner analyst Neil MacDonald coined the term “DevSecOps” 13 years ago, shift left security has seeped its way through mentalities. In fact, the FTC, Federal Trade Commission, recently published a white paper discussing the crucial benefits of adding security from the start: “Companies that consider security from the start assess their options and make reasonable choices based on the nature of their business and the sensitivity of the information involved. Threats to data may transform over time, but the fundamentals of sound security remain constant."

DevSecOps supports time to market

The DevSecOps mindset is gaining momentum, and increasingly more companies are making risk assessment, early security testing, and security-task automation fundamental stages of product development. Why? Because DevSecOps supports time to market.

By embedding automated cyber-security practices into the toolchain, teams can react to sudden changes and get a product ready for market so much quicker. In fact, 45% of organizations with full security integration can treat vulnerabilities within one day, as opposed to only 25% with low security integration. Tech leaders and executives know how catastrophic it feels to find out the existence of breaches, bugs, and issues pre-launch. This can largely be avoided through DevSecOps practices such as:

A thorough culture of security collaboration across all teams, with efficient communication to reduce gaps in the feedback loop
Security checks throughout the software/app development cycle (IDE scanning, source code scanning, static code analysis, dynamic code analysis…)
Meticulous testing and instrumentation of source code, CI server, artifacts, even after deployment with careful monitoring.
Intuitive security criteria and measurement

How the CISO can implement DevSecOps

Many CISOs’ encounters with software development are on the days where security incidents happen. However, security that isn’t automated, on any level, isn’t secure. Cybersecurity is ubiquitous. It can’t be compartmentalized to a team, its implications flow across whole organizations. Companies like Google or Microsoft have understood the drill: take care of security before it takes care of you. If it works for organizations fending off millions of threats a day, why wouldn’t it work for you?

Well, DevSecOps requires education, communication, and a common culture and commitment. To begin implementation, CISO must perform research and have the knowledge to back DevSecOps practices up. Many CISOs don’t understand software development lifecycle and that’s why they struggle to understand how to build secure software. It can seem daunting - there are ever changing solutions, risks, and parameters to consider. CISOs leveraging DevSecOps usually do so through:

Understanding the security risks of all business decisions, including those regarding every step of product development
Getting involved and meeting with the software development teams to fully understand how they operate
Observing how development teams threat model a project (critical!)
Reading up on the DevSecOps methodology to fully grasp its culture
Gaining insight into the common processes, best practices, frameworks, and tools that aid security teams
Approach changes with a partnership mindset

Here are a few resources that could help you leverage DevSecOps as a CISO:

Application security testing - SAST, DAST

It has been estimated that 90% of security incidents are a result of known software bugs. Thankfully, DevOps and DevSecOps have brought about widely adopted technologies capable of identifying security vulnerabilities before they are baked into software/apps. Among these technologies are SAST and DAST.

SAST, Static Application Security Testing, also known as “white-box testing”, has existed for more than 10 years. It aids developers in finding security breaches in source code early on in the software development life cycle, in an effort of “shift left” security. Its added benefit is that it ensures coding guidelines and standards are conform without having to execute the code.

DAST, Dynamic Application Security Testing, also known as “black-box testing”, aims to look for security breaches in running applications, most often web apps. It feeds malicious data to the software to identify vulnerabilities.

SAST and DAST are most often used together because SAST flags coding errors while DAST finds runtime errors. SAST is good at looking for errors in lines of code, like weak random number generations, but not great at finding flaws in data flow. It is a favorite among development teams because it lets them quickly scan a project’s code. This means it becomes much easier to make relevant changes. It also finds flaws very early on in the development process, which inevitably reduce costs and consequences of hurriedly dealing with security issues pre-launch. That’s why it’s a key component of DevSecOps practices.

SAST can be seamlessly integrated and automated into workflows, which contrasts with DAST for which a dedicated infrastructure is created to perform special tests and run different instances of an app with different inputs of data.

The CI/CD pipeline

[DevSecOps Pipeline]

(Image Credit: https://www.catchpoint.com/)

A CI/CD pipeline automates software delivery processes. It builds code, runs tests, and deploys new versions of applications in a safe way. It can remove manual errors, create feedback loops for developers, and send products to market faster.

CI stands for Continuous Integration, and it is a software development practice that prompts developers to combine any changes to code in a centralized archive whenever they occur. CD stands for Continuous Delivery, and it helps automate the software release process as a whole. CI creates an automated build-and-test process for every single change in code within each project. It provides feedback to developers within an average feedback loop of fewer than 10 minutes. CD automates infrastructure provisioning and deployment, logging changes and observations. Both practices can allow entire teams to access the full history of checks and developments, in a fully automated way. One of the biggest security benefits of CI/CD pipeline is the single point of entry of all teams involved in the software project - that approach helps eliminate Shadow IT.

DevSecOps infrastructure

47% of CEOs are extremely concerned about cyber threats and 47% of organizations cite security and privacy as a top technology investment area. DevSecOps addresses these concerns by offering automation through innovation, and more specifically many high-performing tools to leverage for shift-left security. Let’s go through some of the most striking aspects of DevSecOps infrastructure.

Code

Everything as code (EaC) involves the principle of managing all cycles of software development including delivery and management by codifying the infrastructure and pipelines of app/software development.

A successful everything-as-code approach can look like a wide variety of applications: infrastructure-as-code, immutable infrastructure, a secure version control system, configuration-as-code, pipeline-as-code, and policy-as-code. These all work together to generate powerful security controls. Often, everything-as-code starts with infrastructure-as-code (IaC) in teams starting their DevSecOps journey.

Terraform

Terraform is a technology that enables users to build “infrastructure as code”. It has become one of the most popular ways to manage infrastructure as code within the DevSecOps community. Why? Because infrastructure is governed by code, therefore the security of the code within the infrastructure is crucial. Terraform allows developers to:

Manage multiple environments at a time
Protect sensitive code input
Deal with client-side encryption
Perform secret scanning

Ansible

Ansible is an automation platform that allows teams to build and operate security at scale. It helps developers automate:

Infrastructure
Application deployment
Day-to-day management
Networks and IT processes
Security investigations and threat response
Support modules for public and private clouds
Containers

The bottom line

DevSecOps’ mantra would probably be: “Everyone does security”. It is becoming increasingly clear that the traditional approach to security whereby the security team bears the sole responsibility slows down innovation and prevents teams from growing, scaling, and reaching their full potential.

This means that security requires a high degree of collaboration, and as DevSecOps pioneer DJ Schleen wrote, “Business needs require software to be developed and shipped in a timely fashion. Developers want to code the software in the most optimal way possible. The operations team wants the application to be highly available and stable. And the security team wants it to have no vulnerabilities and low risk to the organization. This isn’t a situation where having one team succeeding means another has to falter – rather it’s a perfect ecosystem for collaboration.”

DevSecOps calls for a cultural shift, that of learning how to operate with less friction by leveraging the many tools available. The DevSecOps manifesto mentions that developing security as code allows teams to create “awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment. We will operate like developers to make security and compliance available to be consumed as services. We will unlock and unblock new paths to help others see their ideas become a reality.”

The Essence of DevSecOps

Table of Contents