DevSecOps vs DevOps: What is the Difference? – Source:www.hackerone.com

DevSecOps can dramatically reduce cyber risk for organizations—particularly those that rely on internal development for a competitive advantage.

However, for a term that has been around for years, DevSecOps is poorly understood.

In this article, we’ll explain what DevSecOps is, how it differs from DevOps, and what security controls it should ideally incorporate.

The simplest way to explain the difference between DevOps and DecSecOps is to look at their definitions side-by-side.

DevOps is a combination of development and operations intended to enable engineering teams to develop software more quickly and efficiently. The ultimate objective is to create a more agile development lifecycle that allows organizations to quickly build and update software applications and assets, providing a better customer experience and a significant competitive advantage.

A simple DevOps pipeline looks like this:

DevSecOps is a combination of development, operations, and security. It aims to fully integrate security components into DevOps pipelines—maintaining speed and agility while ensuring software is resilient to cyber threats. The security team typically supports the “Sec” in DevSecOps—but engineering teams take ultimate responsibility for ensuring the code they produce is secure.

Both DevOps and DevSecOps pipelines typically include a high degree of automation to enable fast, accurate development that supports business objectives without sacrificing software quality.

There is an argument that DevOps and DevSecOps are the same things. Renowned DevSecOps speaker Larry Maccherone has often described security as a component of software quality. In other words, if a software asset is insecure, that should be considered equally important compared to an asset not performing as intended.

While this argument has some clear logic, in practice, most people consider DevSecOps to be the proper term for a DevOps pipeline that includes built-in security.

Why is DevSecOps Important?

Today, organizations rely on a complex array of on-premise, cloud, and hybrid infrastructure to enable their operations. This complexity is compounded by continuously creating new and updated software applications, microservices, and cloud containers for organizations that develop software in-house. 

Every time an internet-facing asset or component is created or changed, there is a risk that a vulnerability or misconfiguration could leave it vulnerable to attack.

Speeding up development, automating components of application delivery, and other complexities like breaking software into microservices only compound this risk. It’s easy to make minor errors during the development process, leaving an asset wide open to basic cyberattacks.

Similarly, modern engineering teams use various tools to automate related tasks such as setting up and maintaining servers, containers, code repositories, and image registries—all of which can also be left vulnerable.

Ultimately, DevOps pipelines provide clear business value but are also a substantial source of risk. This is why the “Sec” in DevSecOps is so important. With so much on the line, securing software and development architecture can’t be an afterthought—it must be designed into the development process.

What is DevOps Security?

It’s easy to say, “build security into the DevOps pipeline.” But what exactly does that mean?

 It means fully integrating various security practices into the development process to detect security defects before code is shipped into production. Defects such as:

• Vulnerabilities (e.g., weakness to OWASP Top 10 threats)
• Insecurely implemented secrets and credentials
• Incorrectly configured access controls

Not all security practices can be successfully built into a development pipeline without significantly slowing things down. However, as the diagram below shows, a DevSecOps pipeline can incorporate many security processes, tools, and services:

The diagram above raises an obvious question: how do you build slower processes like pentesting into a development pipeline without impacting time-to-market? 

The answer: by separating security practices into “in-band” and “out-of-band.”

In-band practices can be easily built into the pipeline without causing significant delays. This includes controls such as:

• Secure coding practices. These are crucial to minimize the presence of vulnerabilities in written code. While vulnerabilities can be found later, the team’s ability to push code quickly relies on being able to write code that is mostly free from issues from the outset.
• Automated code scanners. SAST, DAST, and IAST scanners uncover vulnerabilities in source code and compiled applications.
• Peer code review. This is labor-intensive but important for finding vulnerabilities that may not be apparent to a machine, e.g., those caused by logic issues. Typically a peer code review may be completed before product launches and major updates, but not necessarily for every code push.
• Software Composition Analysis (SCA). These scanning tools search for vulnerabilities in dependencies such as software libraries and open source projects.

Out-of-band practices are slower and happen alongside the development pipeline without holding up code pushes. When results from out-of-band practices are available, they are fed back into the pipeline to remove security vulnerabilities from future releases. Out-of-band practices include:

• Pentests and security assessments. These can take days or weeks to complete but are crucial to ensure the security of a software application or asset.
• Bug bounty and Vulnerability Disclosure Programs (VDPs). These are continuous security information sources that can easily feed into new code pushes.

Combined, in-band and out-of-band security practices substantially reduce the risk of shipping vulnerable code—which in turn can significantly reduce an organization’s cyber risk. 

Find More High-Risk Vulnerabilities with HackerOne

The majority of in-band security controls in DevSecOps pipelines are automated. Usually, human intervention is too slow to be a required component of every code push.

However, most out-of-band practices are human-led. While slower, these practices are essential to uncover more complex (but still high-risk)  vulnerabilities, misconfigurations, and business logic issues that a malicious actor could exploit.

HackerOne provides access to the world’s largest community of ethical hackers, who possess the broad range of skills and expertise needed to uncover high-risk vulnerabilities in software assets. A combination of continuous testing via a bug bounty or VDP plus time-bound security assessments can help any organization find and close security issues—both before and after new code is pushed to production.  Development-led organizations like Shopify and PayPal rely on HackerOne to help keep software assets secure without delaying their development pipelines. 

HackerOne’s Attack Resistance Management Platform closes the attack resistance gap—the difference between assets you know and can defend and the unknown and unprotected—by continuously improving visibility and remediation across your evolving attack surface. We help you achieve attack resistance. Contact us to learn more.