What Is DevSecOps in 2026? 87% Run Exploitable Code, 4% Pin Actions

The first time someone asked me what DevSecOps meant, I gave a confident answer about "shifting security left" and adding a scanner to CI. Fourteen years later I would give a less tidy one. DevSecOps is the practice of making security checks part of the same automated delivery system that builds, tests and deploys your software, so that security is a property of the pipeline rather than a gate at the end of it. That definition has not changed much. What changed in 2025 and 2026 is the data: we now have large telemetry studies showing which controls teams actually run, how long secrets stay valid after they leak, and how often AI-generated code fails basic security tests. This post explains what DevSecOps is in 2026, what each scanner category catches, where SLSA fits, and what the numbers say you should do first.

What is DevSecOps, and how is it different from DevOps?

DevOps collapsed the wall between the people who write software and the people who run it. DevSecOps tries to collapse the second wall, the one between both of those groups and the security team. In practice that means three things:

1. Security checks run automatically on every change, in the same pipeline as unit tests, with results the developer sees in the pull request.
2. The security team writes policy and tooling, not tickets. Their output is a rule in a scanner, a hardened base image, or a required check on the default branch.
3. Findings are triaged by risk in context, not by raw CVSS score, because nobody can fix everything.

The difference from plain DevOps is not a separate team or a separate tool category. It is who owns the outcome. In a DevSecOps shop, a developer whose pull request introduces a vulnerable dependency gets a failing check, the same way they would for a failing test. If you want the wider organisational picture, my sibling post on platform engineering vs DevOps vs SRE covers who usually builds that paved road.

Shift left vs shift everywhere: what do the terms mean in 2026?

"Shift left" means moving checks earlier in the timeline: into the IDE, the pre-commit hook and the pull request, instead of a penetration test a week before release. It is still right. A secret caught by a pre-commit hook costs a developer ten seconds. The same secret caught after it reaches a public repository costs a rotation, an audit, and possibly a history rewrite.

"Shift everywhere" is the 2026 correction. Some of the most useful security signals only exist at runtime: whether the vulnerable function is actually loaded, whether the service is internet-facing, whether someone is exploiting it right now. Datadog's State of DevSecOps 2026 found that only 18% of dependency vulnerabilities labelled critical stay critical once runtime and exploit context are applied. Scanning left without context gives developers a queue five times longer than it needs to be, and they learn to ignore it.

So the honest answer is both: cheap, deterministic checks as early as possible, and prioritisation driven by what is running in production.

SAST, DAST, SCA, secrets and IaC scanning: what each one catches

Most "DevSecOps tooling" fits into six categories. They overlap less than vendors suggest, and each has a characteristic failure mode.

Category	What it finds	When it runs	Common open-source example	Typical failure mode
SAST (static analysis)	Injection, unsafe deserialisation, bad crypto in your own code	Pull request	CodeQL, Semgrep	False positives on framework-sanitised input
SCA (software composition analysis)	Known CVEs and licences in dependencies	Pull request, nightly	OSV-Scanner, Dependabot	Alert floods with no reachability context
Secret scanning	API keys, tokens, private keys in code and history	Pre-commit, push, CI	Gitleaks, TruffleHog	Test fixtures flagged, real secrets in Slack missed
IaC scanning	Public buckets, open security groups, missing encryption	Pull request on Terraform, Helm, Kubernetes YAML	Checkov, tfsec rules in Trivy	Rules that do not know your org's exceptions
Container scanning	OS package CVEs in images	Build, registry, admission	Trivy, Grype	Patching base images nobody owns
DAST (dynamic testing)	Exploitable behaviour in a running app	Staging, scheduled	OWASP ZAP	Slow, needs auth setup, rarely gates merges

If you only have time for two, I would start with secret scanning and SCA with a dependency cooldown. Secrets are the cheapest to detect with high precision and the most damaging when missed. Dependencies are where most of your code, and most of your exposure, actually lives. I wrote a step-by-step guide to stopping secrets leaking into git with gitleaks and pre-commit as the companion to this post.

What does the 2026 data say about DevSecOps in practice?

Survey data tells you what people believe. Telemetry tells you what they run. Here is what the larger 2025 and 2026 studies found, with the caveat that every one of these comes from a vendor that sells a product in the space.

Finding	Number	Source
Organisations with at least one known exploitable vulnerability in deployed services	87%	Datadog State of DevSecOps 2026
Critical dependency vulns still critical after runtime context	18%	Datadog
Services depending on libraries no longer maintained	42%	Datadog
Orgs adopting new library versions within 24 hours of release	50%	Datadog
Orgs that pin all marketplace GitHub Actions to a commit hash	4% (71% pin none)	Datadog
Median dependency lag behind latest major version	278 days (215 a year earlier)	Datadog
New hardcoded secrets on public GitHub in 2025	28.65 million, up 34%	GitGuardian State of Secrets Sprawl 2026
Secrets confirmed valid in 2022 still valid when retested in January 2026	above 64%	GitGuardian
Secret-leak rate in Claude Code-assisted public commits vs all commits	3.2% vs 1.5%	GitGuardian
New malicious open-source packages identified in 2025	454,648	Sonatype via Infosecurity Magazine
Average security pass rate of AI-generated code across 100+ models	56%	Veracode 2026 GenAI Code Security Report
Respondents who say more compliance issues are found after deployment than during development	76%	GitLab 2025 DevSecOps survey, 3,266 respondents

Two things jump out. First, the cheapest controls have the lowest adoption. Pinning a GitHub Action to a commit SHA is a one-line change, and 4% of organisations do it everywhere. Rotating a leaked key is a documented procedure, and nearly two thirds of keys GitGuardian confirmed valid in 2022 still worked four years later. Second, speed is now a risk factor. Half of organisations pull in a new library version within a day of release, which is exactly the window in which a hijacked package does its damage. Datadog's authors suggest a one-week cooldown would prevent most malicious dependencies from taking hold. My post on npm worms that learned to use AI agents walks through why that window matters.

Is AI-generated code secure?

Not by default, and the trend is flat. Veracode has tested more than 100 models over four years on the same 80 coding tasks. Its 2026 report puts the average security pass rate at 56%, essentially unchanged, with the best model in the Summer 2026 round at 68% and Java trailing at 30%. Code-specialised models averaged 51% against 52% for general-purpose ones. The models got much better at writing code that compiles. They did not get better at writing code that resists injection.

Two caveats keep this honest. Veracode tests raw model output, with no agent loop, linter or human review, so 56% describes what gets generated, not what ships. And GitGuardian's comparison of Claude Code-assisted commits (3.2% leak rate) against the 1.5% baseline is a correlation on public repositories, not a controlled experiment. Still, the direction is consistent with GitLab's survey, where 73% of respondents reported problems with "vibe coded" code and only 37% would trust AI with daily tasks without human review.

The practical consequence is boring: AI-written code goes through the same pipeline as human-written code, and the pipeline has to be stricter because there is more of it. That was the argument of my post on CI/CD when agents open the pull requests. Agents also leak secrets in new places: GitGuardian counted 24,008 unique secrets in MCP-related configuration files, 2,117 of them valid. Put agent config directories in your secret-scanning scope.

Where does SLSA fit in a DevSecOps program?

Scanners look for bad things in what you built. SLSA (Supply-chain Levels for Software Artifacts) asks a different question: can you prove how it was built and where it came from? The Build track, stable since v1.0, is about provenance: a signed statement of which builder produced which artifact from which source revision. Version 1.2, released in November 2025, added a Source track with four levels: version controlled, history and provenance, continuous technical controls, and two-party review.

The Source track matters more in 2026 than it would have in 2022, because "two-party review" is precisely the control that erodes when an agent writes the code and the same person who prompted it approves it. If your branch protection lets one human approve an agent's PR alone, you are at Source level 3 at best. For teams shipping into the EU, SLSA provenance and SBOMs are also becoming the paperwork of compliance; my post on the Cyber Resilience Act, SBOMs, SLSA and Sigstore covers what reporting went live in September.

A minimal DevSecOps pipeline you can copy

Here is roughly the smallest set of controls I would put on a GitHub repository today. It pins every third-party action to a full commit SHA, scans for secrets with a checksum-verified Gitleaks binary, and adds a dependency cooldown so new versions wait a week before Dependabot proposes them.

# .github/workflows/devsecops.yml
name: devsecops
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read            # least privilege for GITHUB_TOKEN
jobs:
  secrets:
    runs-on: ubuntu-24.04
    steps:
      # actions/checkout v7.0.1, pinned to the full commit SHA
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          fetch-depth: 0     # full history so the scan sees every commit in the PR
      - name: Install gitleaks 8.30.1 and verify checksum
        run: |
          V=8.30.1
          curl -sSLO "https://github.com/gitleaks/gitleaks/releases/download/v${V}/gitleaks_${V}_linux_x64.tar.gz"
          curl -sSLO "https://github.com/gitleaks/gitleaks/releases/download/v${V}/gitleaks_${V}_checksums.txt"
          grep "gitleaks_${V}_linux_x64.tar.gz" "gitleaks_${V}_checksums.txt" | sha256sum -c -
          tar -xzf "gitleaks_${V}_linux_x64.tar.gz" gitleaks
      - name: Scan for secrets
        run: ./gitleaks git --redact --verbose --exit-code 1 .
---
# .github/dependabot.yml (separate file)
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7        # new releases wait a week; security updates are not delayed

Add SCA and SAST on top (CodeQL is free for public repositories), but get these two right first. They are cheap, precise, and aimed at the two failure modes the data says are most common.

FAQ

What is DevSecOps in simple terms?

DevSecOps means security checks run automatically inside the same pipeline that builds and deploys software, and developers fix findings as part of normal work. The security team supplies policy, tooling and context rather than manual sign-offs at the end.

What is the difference between SAST, DAST and SCA?

SAST reads your source code for insecure patterns without running it. DAST attacks a running application from the outside. SCA inventories your third-party dependencies and matches them against known vulnerabilities and licences. Most teams need SCA and SAST first, and DAST later.

Is shift-left security dead?

No. Catching secrets and vulnerable dependencies before merge is still the cheapest place to catch them. The 2026 change is adding runtime context for prioritisation, because only about 18% of "critical" findings stay critical once you know what is actually deployed and exposed.

Do small teams need DevSecOps?

Yes, but not a platform. A pre-commit secret scanner, GitHub push protection, pinned actions, Dependabot with a cooldown and branch protection requiring review cover most of what the data says goes wrong, for close to zero cost.

This quarter, if I were starting from nothing, I would turn on push protection and a Gitleaks pre-commit hook in every repository, pin every third-party action to a SHA, add a seven-day dependency cooldown, and write down a rotation runbook before I needed one. Then I would require a second human reviewer on anything an agent wrote. None of that is new. The data just says almost nobody has finished doing it.

Related: CRA Reporting Went Live on 11 September: 24 Hours to ENISA, 3.08 Billion Rekor Entries, 17% of PyPI Attested, 92% SBOM False Positives, The Worms Learned to Use Your AI Agent: A Year of npm Supply-Chain Attacks and DevOps Still Matters in 2026: AI Cut Delivery Stability 7.2%, Then Doubled Merged PRs and Added 91% to Review Time.