Skip to content
ENFRDescribe your project

DevSecOps: what it is, how it differs from DevOps, and where to start

DevSecOps builds security into the daily work of the teams that develop and ship software. How it differs from DevOps, the automatic checks (SAST, DAST, SCA, secrets), the reference frameworks and the first steps.

By Published on 5 October 2026

DevSecOps means building security into the daily work of the teams that develop and run software, rather than checking it just before release. Automatic checks run on every code change, and development, security and operations share responsibility for the outcome.

DevSecOps and DevOps: what is the difference?

DevOps brings development (Dev) and operations (Ops) together to ship more often and more reliably, through automation. DevSecOps adds security (Sec) to the same pipeline: it is neither an extra team nor a tool, it is security handled like testing, automatically and from start to finish.

This is also called “shift left”: moving security to the left, towards the start of the cycle. A flaw spotted while the code is being written is fixed on the spot; the same flaw found in production calls for an investigation, an emergency fix and sometimes crisis communication.

Why security can no longer wait until the end

  • Flaws are the main way in. In Verizon’s 2026 Data Breach Investigations Report (May 2026), exploiting a vulnerability becomes the main way attackers get in, in 31% of the breaches studied against 20% a year earlier. Nearly one breach in two (48%) involves a third party, such as a supplier or partner.
  • Open-source components are targeted. An application relies on many libraries written by others. The vendor Sonatype counted more than 454,600 new malicious packages in 2025 across the main open-source registries, bringing the total to more than 1.23 million.
  • The build chain itself. On 29 March 2024, a backdoor was reported in XZ Utils, a compression library found on many Linux systems: the malicious code, hidden in the published release archives rather than in the visible repository code, could compromise remote access through OpenSSH on some systems.
  • Secrets leak. GitGuardian detected more than 28.6 million new secrets (passwords, access keys) in public commits on GitHub in 2025, 34% more than in 2024; over 64% of the secrets valid in 2022 were still valid in January 2026.

In the 2025 edition of its Cost of a Data Breach report (July 2025), IBM ranks a DevSecOps approach first among the factors that reduce that cost: about 227,000 dollars less on average, for a global average cost of 4.44 million dollars.

The automatic checks in the delivery pipeline

The delivery pipeline (CI/CD, for continuous integration and delivery) builds, tests and deploys software on every change. DevSecOps plugs checks into it, each in its place:

  • SAST (static analysis): it reads the source code without running it and spots common security mistakes, such as a database query built from user input, as soon as the pull request is opened.
  • SCA (software composition analysis): it lists the libraries in use and their versions, and alerts you when a known flaw affects one. It also produces the inventory of components, the SBOM, covered in our article on the SBOM and the Cyber Resilience Act.
  • Secret scanning: it finds passwords and access keys in the code and its history, before they reach a shared repository.
  • Infrastructure-as-code analysis: it checks the files that describe servers, access and storage, and spots, for example, a database open to everyone or storage made public by mistake.
  • Container image scanning: it looks for known flaws in the system and libraries packaged in each image.
  • DAST (dynamic analysis): it tests the running application from the outside, as an attacker would, in a test environment.

ANSSI, the French cybersecurity agency, sums up good practice in its “Les Essentiels DevSecOps” sheet (February 2024): automatic security tests in the pipeline, secrets kept out of the code in a separate manager per environment, multi-factor authentication on repositories, signed commits, separate development and production pipelines, and production actions treated as administration.

Reference frameworks: NIST SSDF, SLSA, OWASP

  • The NIST SSDF (Secure Software Development Framework, SP 800-218, version 1.1 of February 2022), the US secure development framework, groups practices into four families: prepare the organisation, protect the software, produce well-secured software, respond to vulnerabilities. A version 1.2 has been in draft since December 2025.
  • SLSA (Supply-chain Levels for Software Artifacts), backed by the OpenSSF, sets levels of assurance on how software is built: at level 1, a record of how it was built; at level 2, a signed record produced by a hosted build platform; at level 3, a hardened build platform. Version 1.2 since November 2025.
  • OWASP publishes the Top 10 web application security risks; its 2025 edition ranks software supply chain failures third, a category broadened since 2021. It also publishes the ASVS (version 5.0, May 2025), a list of security requirements to verify, and SAMM, a model for measuring and improving your practice.

For a product sold in Europe, the Cyber Resilience Act turns part of these practices into obligations from December 2027: security by design, vulnerability handling, an SBOM.

Not drowning developers in alerts

DevSecOps that blocks everything is soon bypassed. What works:

  • start in alert mode, without blocking, while false positives are sorted out;
  • then block on a few rules, agreed with the security team: a critical flaw that has a fix, a secret in the code;
  • show results in the developers’ tools, at review time, with the explanation and the suggested fix;
  • deal with existing debt separately, by order of risk, rather than demanding that everything be fixed at once.

That debt builds up fast: according to the vendor Veracode (February 2026), 82% of organisations have flaws left unfixed for more than a year, and 60% have critical ones.

AI-written code goes through the same checks

Part of the code is now written by coding assistants and agents. That code goes through the same pipeline as the rest: analysis, verified dependencies (an assistant can suggest a package that does not exist), human review. Our articles on vibe coding and on rolling out coding agents detail these rules.

Where to start

  • Take stock: which applications, which pipeline, which checks already exist.
  • Start with secrets and dependencies: they are quick to plug in and give few false positives.
  • Add code and infrastructure analysis, in alert mode at first.
  • Agree with the security team on the rules that block a release.
  • Track a few indicators: time to fix critical flaws, secrets found, exceptions granted.

This is the approach of our offer Security in every release, often carried out together with One delivery pipeline for all your teams. Platform engineering builds these checks into ready-to-use templates, so the easy way is also the safe way. See also DevOps and CI/CD. To talk it through with an engineer: the free scoping day.

Frequently asked questions

SAST and DAST: what is the difference?

SAST reads the code without running it, as soon as it is written; DAST tests the running application from the outside. The first finds issues early and points to the line at fault, the second sees what an attacker would see. They complement each other.

Does DevSecOps slow releases down?

A little at first, while the checks are tuned. After that, fast automatic checks replace last-minute reviews and reduce emergency fixes, provided there are few blocking rules, clear and explained.

Do you need a dedicated security team?

Not necessarily at first. You need someone who sets the rules and rules on exceptions, and developers trained on common mistakes; the automatic checks take care of the repetitive work.

Which check should come first?

Secrets and dependencies: they are quick to set up, produce few false positives and cover frequent causes of breaches. Code analysis and DAST come next.

Sources

Facts and figures checked on 4 October 2026.