What Is DevSecOps? How the Practice Changes When Agents Fix Code

An AI agent just opened a pull request to patch a vulnerable library. Should you merge it? DevSecOps is the practice of building software that puts automated security checks into every stage of development and delivery. It replaces the old habit of adding security at the end.

The reality is that this helps developers first. Automated checks catch issues during coding, so teams fix small problems fast instead of stopping for a late review.

The name joins three words: development, security, and operations. It means security lives inside the daily work of building software, not in a final review before launch.

Here is a concrete example. A DevSecOps pipeline can scan every pull request for known-vulnerable dependencies and leaked secrets, then flag problems before the code merges.

That change turns security from a one-time gate into a continuous, shared practice. Everyone who touches the code helps keep it safe, and no one waits until the end to find out what broke.

How is DevSecOps different from DevOps?

DevOps brought development and operations teams together to ship software faster and more often. It uses automation and shared ownership to remove slow handoffs between teams.

DevSecOps adds security to that same model. Instead of a separate team checking code at the end, security controls run inside the pipeline as a shared responsibility.

The table below shows what changes when you move from DevOps to DevSecOps.

Security and speed are not opposites here. When checks are automated and accurate, teams fix issues early and keep shipping.

DevSecOps vs. Traditional Application Security (AppSec)

Traditional application security (AppSec) often ran as a late-stage gate. A separate team reviewed code near release and could block a launch until issues were fixed.

DevSecOps embeds those same checks throughout the pipeline and shares ownership across teams. Both still matter, because DevSecOps is how teams deliver modern AppSec.

• Timing: Traditional AppSec checks late; DevSecOps checks as code is written.
• Ownership: Traditional AppSec sits with a separate team; DevSecOps shares it across development, security, and operations.

For a deeper walkthrough, see our guide to building a modern AppSec program.

What is shift left, and why isn't it enough?

"Shift left" means moving security checks earlier in the process, so problems are caught while code is being written rather than after release. Picture the timeline of a project moving left toward its start.

The benefit is real. Bugs and vulnerabilities cost less to fix when you catch them early, before they spread through the codebase.

But shifting left has a catch. When early tools are noisy, they flood developers with findings, and most of those findings turn out to be false alarms.

That noise creates alert fatigue. According to the hidden cost of DevSecOps, developers spend 3.5 hours on average manually reviewing security scanning findings. That review burden recurs every week, per an IDC InfoBrief sponsored by JFrog (2024).

So the goal is not just earlier checks. It is accurate checks. Our view on making security work for developers is to shift down into the platform, not only left in time.

Why does DevSecOps matter?

Most modern software ships fast and is assembled from open source parts. End-of-cycle security reviews cannot keep up with that pace.

Datadog's State of DevSecOps found that 87% of organizations have at least one known, exploitable vulnerability in deployed services (Datadog State of DevSecOps 2026).

Fixing issues also takes longer than many teams expect. A CISA KEV is a Known Exploited Vulnerability, a U.S. government list of flaws confirmed to be exploited. Per Verizon's 2026 DBIR, the median time to fully remediate one rose to 43 days, from 32 days last year.

DevSecOps is how teams close that gap. Continuous, automated checks catch issues sooner and shorten the time to fix them.

The payoff is practical, not theoretical. Teams that build security into the pipeline spend less time on late-stage rework and more time shipping features.

How does DevSecOps work across the pipeline?

DevSecOps spreads security across the whole software lifecycle, from planning to production. Each stage gets its own automated checks, so nothing waits for a final review.

Here is how it maps to a typical pipeline:

• Plan and design: Threat modeling spots risky decisions before anyone writes code.
• Code: Integrated development environment (IDE) plugins and pre-commit checks catch problems as developers type.
• Build: Software composition analysis (SCA), secrets scanning, and static application security testing (SAST) inspect dependencies and code.
• Test: Dynamic application security testing (DAST) probes the running application for weaknesses.
• Deploy: Configuration and infrastructure-as-code checks catch unsafe settings before release.
• Operate: Monitoring watches production for new issues and drift over time.

Automation is what makes this work. Guardrails run these checks without manual gates, so security keeps pace with delivery.

One more point. DevSecOps also means securing the pipeline itself, including your continuous integration and delivery (CI/CD) systems. We cover that below.

What tools does DevSecOps use?

DevSecOps relies on a handful of tool categories, each covering a different layer. Here is what they do in plain terms.

• SAST: Static application security testing scans your own source code for flaws without running it.
• DAST: Dynamic application security testing probes your running app the way an outside user would.
• SCA: Software composition analysis finds known vulnerabilities in your open source dependencies.
• IAST: Interactive application security testing watches the app from the inside while tests run.
• Secrets scanning: Catches passwords, API keys, and tokens accidentally committed to code.
• IaC scanning: Checks infrastructure-as-code files for unsafe cloud and container settings.

Tools only help if you can trust their findings. Many legacy scanners over-report, and that problem is common in SCA.

Manifest-only scanners guess your dependencies from a list, so they miss some and flag others you never use. Our breakdown of how SCA tools go wrong explains why source-code analysis is more accurate.

How do you cut DevSecOps alert noise?

Most security findings never turn into real risk. Reachability analysis asks a simple question: does your code call the vulnerable function?

If nothing in your application reaches the flawed code path, that vulnerability can't be exploited. Think of it as worrying about the unlocked doors, not every door in the building.

JPMorgan reports only a fraction (1.5–2.0%) get exploited each year.

The noise is not small either. At Endor Labs, we see traditional SAST false-positive rates routinely exceed 70%, which buries the findings that matter under false alarms.

Prioritizing by reachability is how teams cut that noise. At Endor Labs, our full stack reachability analysis can cut false positives by up to 90%, so developers fix what is exploitable.

Evidence-based remediation is the next step. It shows why a finding matters, then offers a safe upgrade path that fixes the issue without breaking the build. When an upgrade is not an option, a backported patch lets you fix the flaw on your own timeline.

How does AI-generated code change DevSecOps?

When agents fix code, the developer's job moves from writing the patch to approving it. Agents can open fix pull requests faster than any team can review them, so the pipeline has to verify agent-written fixes the same way it verifies human ones.

Three things change in practice:

• Evidence comes before the fix. The agent needs reachability data to know which findings matter, or it spends its effort patching code your application never calls.
• Every fix needs an upgrade impact check. A version bump that closes a CVE and breaks the build is not a fix.
• One policy covers humans and agents. The same dependency rules, secrets checks, and approval gates apply no matter who or what wrote the change.

The human role doesn't disappear. Security teams set the policy, agents handle repetitive remediation work, and developers review a short queue of verified fixes instead of a long list of raw findings.

Open Source, Transitive Dependencies, and the Software Supply Chain

Most modern applications are built from open source. At Endor Labs, we see that around 80% of a modern app's code comes from open source components.

Those components arrive as dependencies. A direct dependency is one you choose and install yourself. A transitive dependency is one your dependencies pull in.

Software supply chain security protects everything feeding your build: open source packages, secrets, and CI/CD systems - against tampering and malicious packages.

An SBOM, or software bill of materials, helps here. It is a nested inventory of every component in your software, and it increasingly supports compliance. Our software supply chain security guide covers SBOMs and more.

DevSecOps in the Age of AI-Generated Code

AI coding assistants write code faster, and they pull in more dependencies along the way. That speed creates a new kind of risk.

AI often suggests packages that are outdated, wrong, or do not exist at all. In our State of Dependency Management research, we found that 80% of AI-suggested dependencies contain risks.

DevSecOps practices have to adapt to this. Automated dependency checks, reachability analysis, and human review all need to cover code that a machine wrote.

The volume matters too. AI assistants add dependencies quickly, so a small error rate can still introduce many risky packages over time.

The fix is the same discipline DevSecOps already uses. Verify each dependency before it merges, and check whether your code reaches any flaw it carries.

DevSecOps Best Practices and Common Challenges

Good DevSecOps is less about buying tools and more about how you run them. These practices help teams get signal instead of noise.

• Automate in the pipeline: Run checks on every commit so security keeps pace with delivery.
• Prioritize by reachability: Fix what is exploitable first, not every finding a scanner reports.
• Make findings developer-friendly: Deliver clear, actionable results in the tools developers already use.
• Share ownership: Treat security as a shared responsibility across development, security, and operations.
• Measure what matters: Track mean time to remediate (MTTR), the average time from finding a flaw to fixing it.

The common challenges are just as predictable. Cultural resistance, tool sprawl, and alert fatigue slow many teams down.

You can address all three with accurate, low-noise tooling. See how the Endor Labs platform ties these practices to evidence-based remediation.

Frequently Asked Questions

What is DevSecOps, and what does it stand for?

DevSecOps stands for development, security, and operations. It means building automated security into every stage of software delivery instead of adding it at the end.

How is DevSecOps different from DevOps?

DevOps unites development and operations to ship software fast. DevSecOps adds security as a shared, automated part of that same pipeline.

What is "shift left" security?

"Shift left" means moving security checks earlier in development, so issues are caught while code is written instead of after release.

What tools are used in DevSecOps?

Common categories include SAST, DAST, SCA, IAST, secrets scanning, and infrastructure-as-code scanning. Each covers a different layer of the application and pipeline.

How do you cut false-positive noise from DevSecOps scans?

Prioritize findings by reachability, which checks whether your code calls a vulnerable function. At Endor Labs, this approach can cut false positives by up to 90%.

How To Start With DevSecOps

You do not need to adopt everything at once. Start with a few practical moves and build from there.

1. Map where security already runs in your pipeline today.
2. Add automated checks for code, dependencies, secrets, and container images.
3. Prioritize findings by reachability so developers fix what is exploitable.
4. Measure your remediation time and watch it improve.

Done well, DevSecOps makes security a quiet, built-in part of shipping  high signal, low friction software.

Want to see reachability-based prioritization on your own code? Book a demo.