DevSecOps is a model in which security requirements, controls, testing, feedback and remediation run continuously across every phase of software development and operations, instead of as a review stage at the end. NIST's National Cybersecurity Center of Excellence describes it as integrating security as a fundamental component of the DevOps model, across seven phases: plan, develop, build, test, release, deploy and operate. Security does not sit between those phases. It runs inside all of them.
The difference shows up in remediation data. In Fluid Attacks' State of Attacks 2026, based on 1,119,396 vulnerabilities reported in client systems between January 1 and December 31, 2025, clients whose pipelines ran a security gate remediated 72% of their vulnerabilities, against 58% for clients without one, and closed them at a median of 22 days instead of 30.
This page covers what DevSecOps is and what it is not, how it differs from DevOps, which security work belongs to each lifecycle phase, what it means to break the build in practice, where automation stops being enough, and how to assess maturity instead of treating adoption as a yes-or-no switch.
What is DevSecOps?
DevSecOps is the practice of making security a shared, continuous property of software delivery rather than a gate at the end of it. Development, operations and security teams work from the same backlog, the same pipeline and the same evidence. The goal is not to slow delivery down but to remove the step that used to stop it: the security review that arrives after the code is already written.
Three misreadings of DevSecOps are worth clearing up, because they shape how teams budget for it.
It is not a tool category. Buying a scanner does not make a team DevSecOps any more than buying a CI server makes it DevOps. The NIST NCCoE DevSecOps project puts security requirements, secure design, threat modeling and role definition in the plan phase, before a single line of code exists. Tools come later and serve those decisions.
It is not only shift-left. Moving testing earlier is one half. The other half is what NIST calls continuous feedback: a cycle that aggregates success, failure and anomaly signals from across the software development lifecycle (SDLC) and delivers them back to teams at the earliest point of detection. Without the return path, shifting left just moves a bottleneck.
It is not a phase you finish. The same reference model treats improvements, security and monitoring as components that are present in every phase, not as a stage of their own. A team that runs static analysis on commits and nothing else has automated one phase of DevSecOps out of seven.
DevOps and DevSecOps are not the same thing
DevOps joined development and operations to ship faster. DevSecOps keeps that speed and adds security as a third party to the same agreement, with the authority to stop a release. The practical difference is not the number of teams involved. It is what happens when a check fails.
Dimension | DevOps | DevSecOps |
Primary objective | Faster, more frequent, more reliable releases | The same releases, with known risk accounted for before they ship |
Where security sits | A review before release, often external to the team | Inside every phase, from requirements to runtime |
Who owns it | A security team, consulted | Developers, operations and security, jointly accountable |
What a failing check does | Raises a ticket | Breaks the build and blocks the merge until the policy is met |
Evidence produced | Test and deployment logs | Those, plus findings, severity, exploitability and remediation history per change |
Standards it maps to | Delivery metrics | A secure software development framework such as NIST SSDF, with controls traced to requirements |
If you want the delivery half on its own first, the practice DevSecOps builds on, we have a separate page on DevOps.
DevSecOps at Fluid Attacks
We run DevSecOps on our own software and we run it inside our clients' pipelines. That dual position is where the numbers in this page come from: our clients' vulnerability remediation data, and a controlled benchmark in which our scanner and one of our pentesters tested the same application as 36 third-party tools.
What we assess, and under what rules
We test the systems a client enrolls, for as long as they are enrolled, under a defined scope agreed before testing starts. Assessment covers source code, running applications, mobile apps, infrastructure as code, cloud configuration and third-party dependencies. Findings are reported with their severity and the evidence behind them, and a fix is not treated as closed until a reattack reassesses the code, because a fix can introduce new vulnerabilities or fail to resolve the original one.
Nothing in our DevSecOps model depends on the client pausing delivery. Testing runs while the application changes, which is the only way results stay current in a codebase that ships several times a day.
What DevSecOps looks like in a pipeline
In a DevSecOps pipeline, each phase gets a control, and each control produces evidence that the next phase can act on. This is what the mapping looks like when it is implemented rather than described.
Phase | What runs | Evidence it produces |
Plan | Security requirements selected by industry and regulation; threat modeling | A requirement set the system is later measured against |
Develop | Static Application Security Testing (SAST), AI SAST and Secret Scanning, in the IDE and on commit | Findings at the line of code, before the pull request |
Build | Software Composition Analysis (SCA), SBOM generation, container and IaC checks | A dependency inventory with known vulnerabilities and reachability |
Test | Dynamic Application Security Testing (DAST), MAST, manual Secure Code Review and Pentesting as a Service (PTaaS) | Exploited findings with proof, not just signatures |
Release | CI Gate evaluated against the client's severity policy | A pass or a broken build, with the reason attached |
Deploy | CSPM and configuration review | Misconfigurations tied to the deployed environment |
Operate | Reattacks on request, continuous rescanning as the system changes | Verified closure, or a finding reopened with evidence |
DevSecOps lifecycle. Phase names follow the NIST NCCoE reference model; the controls and evidence shown are the ones Fluid Attacks runs in each phase.
Any of our scanners can be integrated into a CI/CD pipeline through Docker containers, GitHub Actions or distributed binaries, and the platform connects to the tools teams already use, from IDEs and AI assistants to bug trackers.
What breaking the build actually changes
"Break the build" is the one DevSecOps practice with a measurable outcome in our own client data, so it is worth separating the slogan from the result. The CI Gate blocks a deployment while vulnerabilities that violate the client's policy remain open and unaccepted.
CI Gate run with a 7.0 severity threshold: the build fails when a high-severity vulnerability is present.
Vulnerability remediation measure (Jan 1 – Dec 31, 2025) | Clients running the CI Gate | Clients without it |
Share of reported vulnerabilities remediated | 72% | 58% |
Median time to remediate | 22 days | 30 days |
That is a 26.7% improvement at the median, on a base of 1,119,396 vulnerabilities reported across client systems in 2025. The gate does not find anything the scanners did not already find. What it changes is who has to deal with the finding, and when.
Where automation stops
Here is the number that complicates the usual vendor pitch. In the same 2025 data, automated tools found 88.4% of all reported vulnerabilities and manual testing found 11.6%. Read in isolation, that looks like an argument for automating and moving on.
The risk-weighted view inverts it. Those same tools accounted for 55.8% of total risk exposure, measured in CVSSF, against 44.2% for manual testing. The average vulnerability a tool found carried 15.5 CVSSF units of exposure; the average one a pentester found carried 93.2, roughly six times as much. Of the critical-severity vulnerabilities reported that year, 87% came from manual testing.
Tools rose from 29.5% to 55.8% of the risk exposure detected; pentesters still found 87% of critical-severity vulnerabilities. Source: Fluid Attacks, State of Attacks 2026.
Detection source (Jan 1 – Dec 31, 2025) | Share of vulnerabilities found | Share of risk exposure found | Mean exposure per finding (CVSSF) |
Automated tools | 88.4% | 55.8% | 15.5 |
Manual testing | 11.6% | 44.2% | 93.2 |
A controlled test points the same way. In Fluid Attacks' benchmark of 36 third-party AppSec tools against an application seeded with 1,201 vulnerabilities, 743 of them — 61.9% — were detected exclusively by the pentester in manual testing. Over the scope that pentester reviewed, which excluded the sections our own scanner had already covered, they reached 89.6% recall at 100% precision.
The best automated result was 22.7% recall, and it came from our own scanner; the strongest third-party tools landed between 21.0% and 21.6%, and the average of the other 34 tools was 1.7%. Automation is what makes continuous DevSecOps testing affordable at commit frequency. It is not what finds the vulnerability that ends up in an incident report.
The practice that decides the rest
If you adopt one DevSecOps practice from this page, make it the policy behind the gate, not the gate itself. A gate configured on vulnerability counts punishes teams for low-severity noise and trains them to request exceptions. A gate configured on severity and exploitability blocks the handful of findings that carry most of the risk and lets everything else through to the backlog.
The 2025 data supports the asymmetry: high- and critical-severity vulnerabilities were 4.5% of all findings but 79.9% of total risk exposure. Set the threshold where that concentration is, and the gate stops being an obstacle teams route around.
Go deeper: our guide on how to implement DevSecOps walks through requirement selection, and our DevSecOps best practices post covers the operating habits in detail.
How the DevSecOps lifecycle works
It works by assigning a security activity and a control gate to each phase, and by routing what each phase learns back to the ones before it. NIST describes control gates as technical or organizational controls applied before a software change is allowed to proceed to the next stage. The pipeline enforces them; the feedback loop makes them worth enforcing.
Plan
The plan phase sets the security requirements the software will be measured against, defines an architecture that follows secure design principles, and runs threat modeling to decide what is worth defending. Requirements usually come from the regulation a company already answers to, such as PCI DSS, HIPAA or GDPR, plus a secure development framework. NIST SP 800-218, the Secure Software Development Framework, is the common baseline; we map its practices to testable requirements in our public vulnerability database.
Skipping this phase is what produces the most expensive category of finding, the weakness created by design, which no scanner recognizes because the code does exactly what it was specified to do.
Develop, build and test
These three phases carry most of the automated DevSecOps work. Static analysis and secret scanning run as the developer types and again on commit; composition analysis and SBOM generation run at build time against the dependency tree; dynamic and mobile testing run against the deployed artifact. Manual review and penetration testing run in parallel, on a cadence set by how fast the application changes.
The point of placing them here is cost. A finding caught in the IDE is a correction. The same finding caught after release is an incident, a patch, a release cycle and a conversation with a customer.
Release, deploy and operate
At release, the gate decides. At deploy, cloud and configuration checks catch the misconfigurations that never appear in source code. At operate, the system is rescanned as it changes and fixes are verified rather than assumed, which is the step teams most often skip: a closed ticket is not a closed vulnerability until something retests it.
Continuous feedback
NIST defines this cycle as one that aggregates decision criteria — success, failure and anomaly signals — from across the SDLC and delivers them to teams at the earliest point of detection, so they can be fed back into earlier phases. In practice this means a recurring weakness in production should change the requirement set, the threat model and the gate policy, not just the line of code that caused it.
Teams that treat findings as tickets fix instances. Teams that treat findings as feedback stop producing the class.
Why do we need DevSecOps?
DevSecOps exists because the alternative stopped working. Software ships continuously, depends on code nobody on the team wrote, and runs in infrastructure defined by more code. A security review scheduled quarterly cannot describe a system that changed four hundred times since the last one.
Exposure is growing, not shrinking
In 2025, 70% of the systems we assessed carried at least one high- or critical-severity vulnerability, up from 53.3% in 2024. Median risk exposure per system rose 33.5% year over year. These are systems under continuous testing, which means the finding rate reflects what is there, not what happened to be looked at.
Your dependencies are part of your attack surface
Most of the code in a modern application was written by someone else, and attackers know it. In March 2024, CISA and the open source community reported malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094, in a compression library that may be present in Linux distributions. Nothing was wrong with the applications that depended on it. The compromise entered through the build.
This is why software supply chain security belongs inside the pipeline rather than in an annual vendor questionnaire. Our own requirement on the matter is blunt: systems must use stable, tested and up-to-date versions of third-party components. Our analysis of the 2025 OWASP Top 10 covers how the category rose to prominence, and we go further into the subject in our page on software supply chain security.
Security is everybody's business
A security team of ten cannot review the output of three hundred developers, and it was never supposed to. DevSecOps distributes the work: developers own the findings in their code, operations owns the configuration, and the security team owns the requirements, the threat model and the judgment calls. The role that stitches those together has a name and a job description, which we cover in our post on what a DevSecOps engineer does.
Shift-left security, and what it leaves out
Shift-left security means moving testing toward the start of the SDLC, where defects are cheapest to correct. It is the most quoted half of DevSecOps, and it is the right default. On its own, it is also an incomplete description of what the model asks for.
What it leaves out is the right-hand side. Vulnerabilities reach production anyway: through dependencies updated after release, through configuration drift, through classes of flaw no pre-release test catches. Shifting left narrows that window; monitoring, rescanning and reattacks close it for what slips through. The useful framing is not left versus right but DevSecOps coverage across the whole line, with feedback from the right redefining what gets tested on the left.
DevSecOps automation along with manual techniques
Automation and manual testing solve different halves of the DevSecOps problem: automation gives you coverage at the speed code changes, manual testing gives you the findings that carry the severity. Relying on automation alone means accepting both false positives, which cost reviewer time, and false negatives, which cost more.
In practice, scanners run on every commit and pentesters work continuously against the same systems, with both sets of results in the same platform and the same backlog. Scanners narrow the surface; pentesters chain what remains into something an attacker could use, including business logic flaws no signature describes. Our cloud DevSecOps post applies the same split to cloud-native pipelines, where IaC files and container images need continuous testing of their own.
How to evolve DevOps to DevSecOps
DevSecOps maturity is a path, not a switch. A team is not "doing DevSecOps" or not; it has a level per practice, and the useful question is which practice to move up next. Models such as OWASP SAMM exist precisely to make that assessable, with scored practices across governance, design, implementation, verification and operations.
A workable order, when there is no assessment to start from:
Define requirements first: pick the framework and the regulations that apply, so later findings have something to be measured against.
Instrument the phases you already automate: static analysis and composition analysis go where your CI already runs.
Add the gate, on severity: a policy on high and critical severity, not on counts.
Add penetration testing where severity concentrates: the critical findings are the ones automation misses.
Close the loop: reattack to verify fixes, and let recurring weaknesses change the requirements rather than just the code.
Reassess: score the practices again, and move the lowest one.
DevSecOps best practices
The practices that separate a working DevSecOps program from a tooled-up one are mostly organizational. Collaboration comes first: development and security teams that review the product together find issues neither would alone, because understanding why the code does something is the fastest route to knowing how it breaks.
Beyond that: test continuously rather than on an audit cycle; prioritize by exploitability and severity rather than by finding count; verify every fix with a reattack instead of trusting a closed ticket; and keep the developer's feedback loop inside their own environment, because a finding that requires a separate portal gets handled late.
How does DevSecOps relate to red teams?
Red teaming complements DevSecOps by testing the organization rather than the codebase. A red team emulates real adversaries — their resources, tactics and procedures — across technology and people, including social engineering, to measure how well prevention, detection and response actually work. DevSecOps secures what you build; red teaming checks what happens when someone comes after it.
The two meet at the feedback loop. What a red team exercise uncovers belongs in the requirement set and the threat model, which is where the next release's gate policy comes from.
SecDevOps?
SecDevOps, DevSecOps and DevOpsSec name the same thing. The reordering is sometimes used to argue that security should come first rather than sit in the middle, but no standards body distinguishes them, and NIST uses DevSecOps. The term you pick matters far less than whether a failing security check can stop a release.
Conclusions
DevSecOps is not the automation of security testing, and it is not the practice of moving security left. It is a lifecycle model in which requirements, controls, testing, feedback, monitoring and remediation operate continuously across planning, development, build, test, release, deployment and operations, with control gates deciding what moves forward.
The evidence for DevSecOps is specific rather than philosophical. Teams that broke the build on policy violations in 2025 reached a vulnerability remediation rate of 72% against 58% without that control, and did it eight days faster at the median. Automated tools found 88.4% of vulnerabilities but only 55.8% of risk exposure, and 87% of critical-severity findings came from manual testing. Shift-left security and continuous feedback are both load-bearing, and a program that funds only one of them will show it in the severity of what it misses.
Frequently asked questions
Is DevSecOps just adding security tools to the CI/CD pipeline?
No. Tools in the pipeline are one phase of seven. The NIST NCCoE reference model places security work in plan, develop, build, test, release, deploy and operate, with continuous improvements, security and monitoring running across all of them, plus a feedback cycle that returns findings to earlier phases. A team scanning on commit and doing nothing else has automated a fraction of the model.
Does DevSecOps replace penetration testing?
No, and the data says why. Across 1,119,396 vulnerabilities reported in client systems between January and December 2025, automated tools found 88.4% of vulnerabilities but 55.8% of risk exposure, while 87% of critical-severity vulnerabilities came from manual testing. Automation delivers coverage at the speed code changes; pentesting delivers the findings that carry severity. A DevSecOps program needs both.
What is a security gate, and what does breaking the build mean?
A security gate is a control applied before a change is allowed to move to the next lifecycle stage. Breaking the build means that gate stops the deployment while vulnerabilities violating the defined policy remain open and unaccepted, which forces a fix instead of a ticket. In 2025, clients using one remediated 72% of their vulnerabilities against 58% without one.
How do you measure DevSecOps maturity?
With a scored model rather than a yes-or-no answer. Frameworks such as OWASP SAMM assess practices across governance, design, implementation, verification and operations, so a team can see which practice is weakest and move that one. Treating adoption as binary hides the gap between a team that scans on commit and a team that also sets requirements, gates on severity and verifies fixes.
Does Fluid Attacks support DevSecOps in CI/CD pipelines?
Yes. Our scanners integrate into CI/CD through Docker containers, GitHub Actions or distributed binaries, and our CI Gate evaluates each build against your severity policy and blocks merges when policy-breaking vulnerabilities are present. The platform connects to the IDEs, AI assistants and bug trackers your team already uses, and our pentesters test the same systems continuously under the Advanced plan.
Ship fast without vulnerabilities
Our scanners, AI and pentesters bring DevSecOps testing to your applications as they change, and our CI Gate stops the builds that would carry a critical vulnerability into production. Start free trial · Contact us
Get started with Fluid Attacks' ASPM solution right now
