Everything you need to know about DevSecOps

What is DevSecOps?

DevSecOps is a culture that emphasizes shared responsibility for product security across development, security, and Ops teams. By integrating continuous and automated security scanning for software and cloud infrastructure into the Software Development Lifecycle (SDLC), DevSecOps aims to empower engineers to consistently deliver secure code.

The goals of DevSecOps

Reduce security and business risk

By consistently detecting software and cloud infrastructure vulnerabilities before they’re pushed to production, development teams can mitigate the business risk of application security issues that provide malicious actors with sensitive information.

Accelerate developer velocity

DevSecOps aims to empower engineers to deliver secure code from the start, rather than finding vulnerabilities in production and triaging them back to developers. This accelerates developer velocity by avoiding time consuming feedback cycles between development and security teams.

Achieve compliance requirements faster

Many modern compliance requirements demand continuous code scanning and vulnerability remediation to reduce security risks. By implementing DevSecOps practices, businesses deliver secure code faster, which reduces the time needed to fulfill compliance requirements so they can sell into new markets faster.

Build a culture of shared responsibility for security

Secure software delivery requires collaboration across development, security, and Ops teams. DevSecOps makes security testing a core pillar of the SDLC, which builds a culture of security across the organization.

Improve secure software development skills

By providing continuous and immediate feedback on the code security, DevSecOps can help developers understand the security implications of their coding decisions. Over time, developers can better understand common security issues and how to resolve them.

The core components of a DevSecOps pipeline

A DevSecOps pipeline integrates automated security testing into each stage of software development.



Planning

The planning phase requires designing applications that adhere to secure design principles, such as implementing separation of duties, ensuring least privilege, and requiring thorough authentication and authorization for every access request.

Code scanning in the IDE

By scanning code as it's being written in the IDE, developers can catch vulnerabilities early in the SDLC and resolve them before production. There are many solutions like Jit that enable code scanning in the IDE.

Pre-commit hooks

Pre-commit hooks enable developers to test their code without committing it in the codebase. This can be helpful for security scanning like secrets detection, where you don’t want any record of hardcoded secrets in your Source Code Manager (SCM).

CI/CD integration

By automatically initiating security scanning as pull requests (PRs) are created, developers can ensure the security of every code change they merge with the codebase. Look for solutions that provide extensive remediation guidance for vulnerabilities within the PR, so that developers can quickly resolve issues.

The build

Some coding languages like Java Gradle can only be scanned as they’re being built, which is why many DevSecOps pipelines are focused on the build phase.

Deployment-based scanning

Configure automated application and cloud infrastructure scanning after each deployment to ensure no new vulnerabilities are being pushed to production. This final stage of the DevSecOps pipeline verifies the security of applications in production.

DevSecOps best practices

Consider implementing these DevSecOps best practices to reduce security risk and accelerate developer velocity.

Integrate continuous security testing into the developer environment

Code and cloud security tools may be met with resistance if developers are required to leave their environment to analyze results in separate UIs for security tools. Consider integrating continuous scanning and remediation guidance directly into the IDE or PR, so that developers don’t need to leave their environment to secure their code.

Focus analysis on the code change

Oftentimes, security scanning will analyze the entire repository for issues, which presents developers with long vulnerability backlogs every time they make a code change. Instead, focus security feedback on the code change, so developers can quickly understand how their current PR impacts the security of their product.

Gamify security for developers

By implementing a scoring system for teams and tracking progress on leaderboards, developers can better understand how they’re doing and how they stack up against other teams. By gamifying security for developers, you can motivate your team to proactively resolve vulnerabilities.

Implement auto remediation

After finding a vulnerability in their code, developers often need to conduct research on the root cause and potential fix for the issue, which can require considerable time. Auto remediation provides developers with suggested code fixes so they can quickly resolve issues and spend more time coding.

Prioritize vulnerabilities based on runtime context

Product security is often associated with long backlogs of vulnerabilities that are difficult to prioritize, leaving developers unsure of where to start or how to mitigate the top risks. Security tools should automatically analyze the runtime context of each issue to determine whether it is exposed to the internet and exploitable in production, so developers can quickly understand which vulnerabilities to prioritize.

Understanding the categories of DevSecOps tools

There are many different kinds of application and cloud security vulnerabilities – each of which require different scanning methods for detection. Learn about the different categories of DevSecOps tools below, as well as they’re potential pros and cons.

Static Application Security Testing (SAST)

• Pros: SAST tools are great for detecting coding issues like injection attacks and buffer overflows early in the SDLC. Consider integrating SAST in your IDE or CI system to automatically trigger analyses after each commit.
• Cons: SAST tools are known for high false positive rates. Consider Semgrep for a free and highly accurate static analysis tool.

Secrets detection

• Pros: secrets detection tools like GitLeaks and Trufflehog are critical components of the DevSecOps toolchain. They scan your source code to detect hard coded secrets (such as API keys and passwords) that could provide sensitive information (like credit card information or health records) to malicious actors.
• Cons: these tools focus solely on secrets detection. To cover the rest of the product security landscape, you’ll need to implement other technologies which can lead to tool sprawl.

Software Composition Analysis (SCA)

• Pros: SCA is required to identify vulnerabilities in open source software components and their dependencies. Considering how often open source is used in modern applications, it is critical to ensure software supply chain security with SCA.
• Cons: many SCA tools rely on the National Vulnerability Database, which documents which vulnerabilities exist within specific open source components. Many of these vulnerabilities don't contain much remediation guidance, which can leave developers unsure of how to fix the issue.

IaC scanning

• Pros: without careful inspection, IaC can easily contain vulnerabilities like open S3 buckets that expose sensitive information to attackers. Consider implementing IaC security scanning to catch these issues before production.
• Cons: the nature of IaC scanning is to surface vulnerabilities in static IaC files, which will miss vulnerabilities caused by configuration drift, or other issues caused by infrastructure changes made in the CLI or the cloud console. For this, CSPM (below) is needed.

Cloud Security Posture Management (CSPM)

• Pros: CSPM scans your live cloud environment to surface infrastructure misconfigurations that can result in vulnerabilities. Unlike IaC scanning, it can catch issues caused by configuration drift and changes made directly in the cloud console.
• Cons: CSPM examines your live cloud infrastructure, so it cannot surface potential vulnerabilities early in the SDLC. Consider combining CSPM with IaC scanning.

Dynamic Application Security Testing (DAST)

• Pros: DAST tools analyze apps from the outside-in by simulating attacks on the application. This “black box” testing method interacts with the running application without accessing its source code, mimicking how an attacker would interact with the app in a real-life scenario. When DAST tools find vulnerabilities, there is a good chance they’re true positives.
• Cons: DAST only analyzes live applications, so it can’t be used to shift security left in the SDLC to surface issues before production.

Source Code Manager (SCM) misconfigurations

• Pros: without security controls in place, SCMs can be misconfigured to expose sensitive information to the public. Implement code repository configuration controls to ensure your code isn’t accessible by malicious actors.
• Cons: SCM security tools are point solutions, so you’ll need to separate security tooling to cover the other categories described above, which can create a sense of tool sprawl.

Key DevSecOps Skills and Techniques

The unique challenges of DevSecOps requires specific skills and techniques to overcome.

Familiarity with the developer environment, languages, and infrastructure services

You can’t secure what you don’t know, which is why an intimate understanding of the developer environment is critical for implementing the tools and processes described in previous sections. 

Every tech stack has unique risks and security challenges. DevSecOps engineers will need to:

1. Map the systems they want to secure

2. Research the best security controls for their stack

3. Implement these controls in ways that don’t obstruct developers

4. Monitor for issues and generate reports that demonstrate compliance and progress

DevSecOps engineers will also need to pay close attention to the latest security events, so they can quickly respond to new threats and recently disclosed vulnerabilities as they emerge.

Communication and teamwork

Rather than assuming the entire burden of product security, DevSecOps engineers should aim to empower developers to independently identify and resolve vulnerabilities. However, security processes can make significant impacts on developer workflows, which is why DevSecOps engineers should work closely with developers to build out a practice that works for them. 

Additionally, DevSecOps should align with larger security objectives like gaining compliance with specific standards, which requires teaming up with information security teams to ensure product security goals are aligned.  

Risk Assessments and Threat Modeling Techniques

Related to the first point, every tech stack will have its own security risks that DevSecOps engineers should study and mitigate. By continuously conducting security assessments and threat modeling, DevSecOps engineers can maintain an up-to-date view of the critical risks of their system.

Does the system adhere to principles of least privilege? Is each request thoroughly authorized and authenticated? Do any users have more permissions than they require for their job? These are the kinds of questions related to secure design principles that DevSecOps engineers can answer to assess the security risks of their system.

DevSecOps Challenges

False positives

DevSecOps requires trust in the results of security scanning, which is why false positives are perhaps the fastest way to erode developer faith in the results. Spending time to research problems that don’t end up posing real risks wastes development time and creates a negative associated with security practices.

Long backlogs of unprioritized security findings

Many code and cloud security tools generate long lists of security findings that can be difficult to prioritize. Many of these issues don’t pose serious risks – perhaps they exist in the staging environment and/or they aren’t accessible via the internet. 

Naturally, developers want to focus their time remediating issues that introduce the most security and business risk, which would be exploitable vulnerabilities in production. With tools like Jit, developers can immediately prioritize these vulnerabilities to focus time on the highest risks.

Context switching

Most security processes and technologies require developers to leave their environment – like their IDE or the SCM – to find, research, and resolve vulnerabilities. This takes them out of their flowstate when they’d rather be working on the next feature.

Instead, aim to incorporate security scanning and remediation feedback entirely within their environment, so that they don’t need to context switch every time they need to resolve an issue. This is far faster than requiring them to scroll through vulnerabilities in separate UIs.

Developer buy-in

As discussed earlier, DevSecOps requires developer buy-in and a culture of shared responsibility to deliver and maintain secure applications. Piling the product security burden on a security team isn’t scalable – there are too many vulnerabilities and developers are better positioned to make the necessary fixes.

All of the challenges discussed above can erode developer confidence in security technologies and processes. To ensure an effective DevSecOps program, equip developers with the resources they need to independently and consistently resolve vulnerabilities before production.