The 4 Stages of DevSecOps Maturity

Over the last couple of years, we’ve had deep conversations with more than 100 organizations regarding current AppSec practices and plans for adding security into their DevOps pipelines. Based on our learnings from these conversations, enterprises can be grouped into 4 buckets based on their maturity level in their DevSecOps journey.

Before we explore these 4 stages of DevSecOps maturity, let’s understand the players and personas that are relevant for AppSec. These personas include the Business Unit/Leadership, Developer, QA, AppSec, and DevOps. Below is a chart detaling by persona their ideal goal vs. their reality today.

Based on customer conversations involving all five of the above personas, here are the 4 Stages of DevSecOps Maturity that we have identified:

Stage 1: Have zero/minimal security checks during development

• Devs write code → Builds are sent to QA → QA tests functionality → Release ships to prod
• Security checks are either rare or do not happen. Most likely using a pen testing firm hired once every 3-6 months.
• Outcomes:
  • High risk of vulnerabilities
  • Breaches in production

Stage 2: Have ‘gated’ or out-of-band security checks

• Devs write code → Builds are sent to QA → QA tests functionality → AppSec team verifies security → Release ships → Occasional out-of-band security tests via penetration testing firms
• Outcomes:
  • Releases delayed causing time-to-value issues for business and impacting revenue
  • Insufficient coverage of all security risks
  • AppSec team is viewed as the ‘enemy’ that slows down releases

Stage 3: Have basic DevSecOps

• Devs write code → SAST/SCA provide feedback to devs → Builds are sent to QA → QA tests functionality → Release ships to
  prod → Complemented with out of band pentesting and AppSec team testing
• Outcomes:
  • Only conduct static checks with no runtime security checks or visibility into 3rd parties and open source at runtime
  • Dev team suffers from alert fatigue due to high volume of meaningless, “what could happen” alerts

Stage 4: DevSecOps with Continuous Observability

• Devs write code → SAST/SCA provides feedback into the ‘static’ app → Continuous Observability is turned ON during test/stage/prod → QA tests functionality and tests security automatically → Release ships to prod with great quality & security → Penetration testing is used to focus on more complex things requiring humans
• Outcomes:
  • Secure apps released on schedule
  • Fastest time-to-value
  • Lowest risk of breaches in prod
  • Seamless collaboration between the Eng and AppSec teams

Continuous Observability → The missing piece

The fundamental problems with stages 1, 2, and 3 are due to the fact that there is no feedback on the security risks in the app during test, staging, or production on a continuous basis. QA teams test only for functionality, leaving a huge gap in the security posture of the app. AppSec teams go to an ad-hoc end of the release test. Pen testers conduct testing once every 3-6 months, which is simply inadequate given the speed with which releases are shipping today. We need a better solution.

We need a way to automatically observe every thread/process/container of a running application—including your code and 3^rd party components—and identify security risks at various layers of application behavior – system call, library call, web, API, network, file, and other behaviors. And we need this during test, stage, and all the way into production. This, in a nutshell, is what observability techniques can provide us. Therefore, we need observability applied to application security. This can be achieved using do-it-yourself approaches by leveraging various interception techniques such as eBPF or other solutions, coupled with the creation of several alert rules in the context of AppSec. OR, you could use a turnkey solution like Deepfactor that does it all for you.

Everyone’s a Winner with Runtime AppSec Observability

Business wins → ships releases fast and securely

Devs win → less volume with more accurate/relevant alerts

QA wins → App is no longer a black box and they are equipped to challenge dev teams on security issues

AppSec wins → Comprehensive visibility into application security behavior at all layers of the stack, for all components

DevSecOps wins → Not only are code scans & dep scans turned ON, but Continuous Observability is turned on automatically during all stages of dev

Conclusions

When you think about adding security into DevOps, think about it in two parts – static and runtime. For static – use SAST/SCA. For runtime – use Continuous Observability<. Ship fast. Ship securely. Your app is no longer a black box for your QA teams or your AppSec teams.

Regardless of your current stage in DevSecOps maturity, you can easily start running your app with Deepfactor since the technology supports most applications out-of-the-box with just a simple dfctl command—no need to change any code in the application or bother with language-specific instructions. It works with any workload (container/Kubernetes/Docker or even traditional apps) and any cloud. You can contact us for a demo here.

About Deepfactor

Deepfactor is the industry’s first Continuous Observability platform enabling Engineering and AppSec teams to find and triage RUNTIME security, privacy, and compliance risks in your applications—including 3rd party components—within the DevOps pipeline. With zero code changes, Deepfactor automatically observes billions of live telemetry events in every thread/process/container to detect anomalies during test, staging, and production. Deep Insights cover system call risks, data risks, behavior risks, DAST scans, a software bill of materials (SBOM), and vulnerable dependencies to create high-fidelity alerts with actionable evidence. Reduce MTTR, accelerate release velocity, and ‘start left’ to create and maintain secure and compliant apps. Request a demo of Deepfactor today!