SecDevOps: What It Is, and Do You Need It in Your Organization?

Most teams don't ship DevSecOps because a mandate came down from above. They ship it because security failures stopped being tolerable as a line item, and the fastest way to fix that was to stop treating security as a separate stage bolted onto the end of development. That shift, folding security directly into DevOps rather than running it as a parallel process, is what this piece is actually about.

To ground the conversation in something more current than theory, I'm pulling in real data from 2025 and 2026 industry research, plus insights from Michael Oberlaender, a security executive who has held eight CSO/CISO roles across large global enterprises and wrote "C(I)SO, And Now What" and "Global CISO: Strategy, Tactics, and Leadership."

What SecDevOps actually is

SecDevOps integrates security checks into every stage of the software development and deployment pipeline instead of treating security as a gate at the end. The two components that make this practical are Security as Code (SaC), where security controls are automated and version-controlled the same way application code is, and Infrastructure as Code (IaC), where the provisioning and configuration of servers, networks, and cloud resources is defined in code rather than clicked together manually in a console.

Oberlaender put it plainly when asked about confidentiality in an IaC/SaC environment: "It is of utmost importance to ensure confidentiality, so you CANNOT store credentials in the code, no hard coded credentials in the code. This is oftentimes overlooked and people don't understand or underestimate the potential impact. Storing access tokens or keys to your cloud environment in the code or a repository is literally providing the proverbial keys to the kingdom to the cyber crooks."

That's not an abstract warning. Secrets exposure in CI/CD pipelines remains a persistent, recurring finding in current application security research. According to Datadog's State of DevSecOps research, cited in Cloudaware's 2026 DevSecOps statistics report, 63% of organizations have used long-lived credentials somewhere in their CI/CD pipelines, a pattern that directly enables the kind of key theft Oberlaender is describing.

Where the industry actually stands in 2026

Adoption has grown, but maturity is uneven, and that gap is the real story right now. A few numbers worth sitting with:

• Roughly 97% of organizations are using or planning to use AI somewhere in the software development lifecycle, according to GitLab's 2025 Global DevSecOps Survey of 3,266 professionals, conducted by The Harris Poll.
• Despite that AI adoption, DevSecOps professionals report losing about 7 hours per week to inefficient, fragmented processes, per the same GitLab research.
• 60% of teams use more than five separate tools for software development, and 49% use more than five AI tools, which is exactly the kind of tool sprawl that makes consistent security enforcement difficult across an organization.
• Over 50% of teams now run static application security testing (SAST) in their CI/CD pipelines, with roughly 44% running dynamic testing (DAST), according to Practical DevSecOps' 2026 benchmarking data.
• 74% of codebases contain at least one high-risk open source vulnerability, and 91% of codebases rely on dependencies more than ten versions out of date, per Synopsys's Open Source Security and Risk Analysis (OSSRA) research cited in the same Cloudaware report.

GitLab's chief product and marketing officer, Manav Khurana, described the resulting friction this way in the November 2025 release: "This survey illustrates what we call the 'AI Paradox,' where coding is faster than ever, yet the lack of quality, security, and speed across the software lifecycle is causing friction on the road to innovation. Toolchain fragmentation has created bottlenecks for developers, and AI agents are amplifying the issue."

This is where teams usually trip up: they assume buying more scanning tools equals more security. It doesn't. Having SAST, SCA, and secrets scanning running in a pipeline is table stakes now. The differentiator is whether findings actually get triaged, assigned an owner, fixed, and retested, or whether they pile up in a backlog nobody touches. A tool that flags 800 vulnerabilities with no context, which is a real complaint from engineers surveyed in recent application security research, creates the appearance of security without the substance of it.

Why organizations adopt it: the honest version

It shifts cost earlier, where fixes are cheaper

Oberlaender's framing on cost is worth quoting directly: "It is well understood that a code change in production is the costliest and most complicated, the costs are hundredfold higher than in the early code development stages. By bringing in the security concepts, designs, coding, validation, automated security testing, and security sign-off into the SDLC you shift the problem to the left, where it is better to be solved by design, from the get-go, avoiding bolted on solutions and other crutches."

This tracks with what's happening in the market. The global DevSecOps market is estimated at roughly $8.8 billion for 2024 and is projected to grow to about $20.2 billion by 2030, a compound annual growth rate near 13.2%, according to Precedence Research's market analysis. That's organizations voting with budget for tooling that catches problems before production, not after.

It doesn't automatically make things faster, despite the pitch

Here's the honest limitation: SecDevOps is often sold on the promise of faster releases, and that promise is only partially true. It's true once the pipeline is mature and automated checks replace manual security sign-off gates. It is not true during the transition period, when teams are retrofitting security into an existing pipeline, retraining developers, and working through the inevitable friction of a new process. GitLab's own data shows a "paradox" where individual coding speed has gone up while overall delivery speed has not kept pace, precisely because governance, review, and security checks haven't scaled at the same rate as AI-assisted code generation.

Culture change is genuinely hard, and it costs real money up front

Oberlaender's advice on building security awareness into teams is specific and worth repeating: "You start with awareness about the issue, so that developers understand that code is NOT inherently safe, most of them never got taught in school, college, or university how to write secure code. After initial awareness, make sure you provide them the learning environments and tools to deep dive into the subject and make this mandatory."

That training investment is not free, and it's not instant. Organizations that skip it and just buy scanning tools tend to end up with exactly the alert-fatigue problem described above: lots of findings, little remediation.

Common challenges teams actually run into

1. Tool sprawl without integration. With 60% of teams running more than five development tools, each with its own definition of "pass" or "fail," inconsistent security thresholds across pipelines become almost inevitable unless there's a unifying policy layer.
2. Compliance keeps moving. Regulations like GDPR, HIPAA, and PCI DSS continue to evolve, and a fast-moving DevOps environment has to keep pace with legal requirements that weren't written with continuous deployment in mind.
3. Talent remains scarce. Engineers who are genuinely fluent in both security and modern DevOps practices are still hard to hire, which pushes many organizations toward training existing staff rather than recruiting externally.
4. Third-party dependency risk. With the vast majority of codebases carrying stale or vulnerable open source components, managing what's actually running in production, not just what was audited at build time, is an ongoing task rather than a one-time fix.
5. AI-generated code needs the same scrutiny as human-written code, arguably more. GitLab's research found that 73% of respondents have experienced problems stemming from "vibe coding," meaning code generated from natural language prompts without a clear understanding of what it actually does. Scanning tools built for human-written patterns don't automatically catch every failure mode introduced by AI-assisted generation.

Where this is headed

Asked about the future, Oberlaender was characteristically blunt about the limits of prediction: "Well I can't predict the future, I can just make an educated guess. It's a bit too early to really say this but I think recent improvements in AI and ML will help automate this process chain further and also validate more before code is being put into production." He added a caveat that's aged well: "But so far, I have not seen a machine completely programming a machine. Without security and safety controls, this could get quickly out of hand."

That caveat matters more now than when it was first said. With 97% AI adoption in the SDLC and only 37% of professionals willing to trust AI to handle daily work without human review (per GitLab's data), the industry is collectively acting out exactly the caution Oberlaender described: using AI heavily, while still insisting on a human in the loop.

The non-obvious takeaway, if there is one: SecDevOps maturity in 2026 isn't measured by which scanning tools you've bought. It's measured by whether a finding that shows up in a pipeline actually gets fixed, verified, and closed out, with someone accountable for that outcome. Everything else, the AI hype, the tool sprawl, the market growth numbers, is secondary to that basic operational discipline.

Further reading: Software Development Life Cycle, Vulnerability Management Programs, What Is Vulnerability Scanning