The security team that insists on manual review of every pull request before deployment is not a security team — it’s a queue. And in any organization where development velocity matters, that queue eventually gets routed around. Developers find ways to expedite, exceptions become the norm, and the security review that was supposed to catch everything catches nothing because it’s been marginalized by the teams who found it easier to bypass than to engage.
We’ve seen this pattern play out consistently, and it’s not a developer culture problem — it’s a design problem. Security controls that create friction without delivering value get bypassed. The answer isn’t to hold the line on manual gates; it’s to build security into the development workflow in ways that are fast, accurate, and directly useful to the developers encountering them. That’s the practical definition of DevSecOps: not security’s presence in the development process, but security integrated into it in a way that both functions want to maintain.
The Bottleneck Problem
Most organizations start DevSecOps by adding security tooling to their CI/CD pipeline. A SAST scanner here, a dependency checker there. The tools run, they produce findings, and then — nothing changes, or everything breaks. Either the findings are so numerous and low-quality that teams learn to ignore them, or the pipeline fails so often that builds get unblocked by default exceptions.
Both outcomes share the same root cause: security controls were added without thinking about how the findings would be triaged, acted on, or integrated into the developer’s workflow. A pipeline that dumps 400 findings on a developer with no guidance on which three actually matter is worse than no pipeline at all. It trains developers to view security tooling as noise, and that conditioning is very difficult to reverse.
The bottleneck problem isn’t solved by adding more gates. It’s solved by making each gate precise and fast, routing findings to the right person with enough context to act, and eliminating checks that consistently produce findings too low-severity to remediate. Precision and speed are the design constraints. Every check in your pipeline should clear both bars or be reconsidered.
Choosing the Right Security Controls for Each Stage
Not every security check belongs in every stage of the pipeline. Matching controls to the stage where they’re most effective and least disruptive is one of the most important decisions in a DevSecOps program.
Pre-commit hooks are best suited for fast, deterministic checks: secret detection, basic code formatting rules, and obviously dangerous patterns. These checks run in under a second, give developers immediate feedback before they’ve even committed, and catch issues at the point in time when they’re easiest and cheapest to fix. Secret detection in particular is worth prioritizing here — API keys and credentials that never reach the repository are far better than credentials that get committed and need to be rotated.
CI pipeline checks are the right place for SAST, dependency scanning, and IaC security analysis. These checks run on every build and produce findings that block or flag the pull request. The key discipline is aggressive tuning: suppress findings that are consistently low-severity for your codebase, require developers to acknowledge and document exceptions rather than silently ignoring failures, and review the suppression list quarterly to see whether the suppressions still make sense. A well-tuned SAST configuration that catches 20 real issues per month is worth more than an untuned one that produces 500 findings and gets ignored.
Container and infrastructure scanning belongs in your build and deployment stages, where you can verify that what’s going into production matches your security baselines. This is also where runtime security policy checks — whether the deployment meets your organization’s required configurations for logging, network policy, and secrets management — should live.
For teams starting out, we recommend reading our post on starting your application security program for foundational guidance on building these capabilities incrementally.
Prioritizing Developer Experience
Security tooling that’s difficult to interpret or act on generates ticket volume without improving security outcomes. Developer experience isn’t a nice-to-have in a DevSecOps program — it’s a core design requirement, because developers are the humans who will actually remediate the findings your tools produce.
This means a few concrete things. Findings should be surfaced in the environment where developers work: in pull request comments, in IDE plugins, in the build output — not in a separate security dashboard that requires logging into a different system. Each finding should include not just what was detected, but why it matters and what a remediation looks like. Developers who understand why a finding is flagged remediate faster and make fewer recurrences than developers who are told “fix this” with no context.
Feedback loops matter here too. When a developer fixes a finding correctly, they should see confirmation. When a fix closes the issue cleanly versus just suppressing it, that distinction should be visible. Security teams that spend time reviewing pull request fixes and leaving constructive comments — explaining tradeoffs, acknowledging good remediation, suggesting alternatives — build more trust and produce better security outcomes than teams that only show up to block deployments.
Invest in internal documentation that’s developer-facing. Your policy on secrets management, your approved libraries for cryptographic operations, your configuration standards for the frameworks your teams use — these should be in your developer portal, not in a security wiki that only security reads.
Building the AppSec Feedback Loop
The pipeline is where you catch issues, but it’s not where you fix the underlying causes. The organizations that make sustained progress on application security have a feedback loop that connects individual findings to systemic patterns and addresses the root causes.
When the same type of vulnerability — SQL injection, insecure deserialization, hardcoded credentials in a specific service — appears repeatedly across different pull requests or different teams, that’s a training and tooling problem, not a developer attitude problem. The response should be targeted: a secure coding session for the teams involved, an update to code templates or scaffolding that makes the insecure pattern harder to introduce, or a library change that eliminates the vulnerability class at the dependency level.
Tracking findings by vulnerability class over time tells you which classes are growing, which are declining, and where you should direct your developer education effort. This data also makes the business case for AppSec investment: being able to show that cross-site scripting findings dropped 60% after adding a properly configured frontend framework to your standard stack is a compelling argument for continued investment in secure-by-default tooling.
Handling the Legacy Codebase
DevSecOps programs are usually designed for greenfield development, but most organizations have substantial legacy codebases that are still being maintained and occasionally modified. Applying your full pipeline configuration to legacy code often produces a flood of historical findings that weren’t your focus and are expensive to remediate.
The practical approach is to apply different scanning profiles to legacy code versus active development. For legacy codebases, focus pipeline checks on new changes only — using diff-based scanning rather than full codebase analysis. This ensures that developers working on legacy code don’t introduce new vulnerabilities while also not drowning them in historical findings they weren’t responsible for. Separately, run periodic full scans of legacy codebases to build a picture of the historical debt and develop a prioritized remediation roadmap based on exposure and exploitation likelihood.
This two-track approach — new code held to current standards, legacy code incrementally improved — is realistic about what organizations can actually sustain and keeps the pipeline effective rather than noise-generating.
Measuring DevSecOps Maturity
DevSecOps programs need metrics that reflect developer adoption and security outcomes, not just tool deployment. A SAST scanner that’s installed but routinely bypassed is not a security control.
Useful metrics include: the percentage of builds that run security checks without exception bypasses; mean time from finding detection to remediation by severity; the ratio of findings blocked at pre-commit or CI versus those caught in production or post-deployment; and recurrence rate by vulnerability class. These metrics tell you whether the program is functioning as designed and where the friction points are.
Watch for leading indicators of adoption problems: exception bypass rates that are climbing, the same developers or teams appearing repeatedly in unresolved findings, or entire repositories that have been excluded from scanning without documented rationale. These patterns suggest that the program is being worked around rather than integrated, and addressing them early is far easier than trying to rebuild trust after security has been thoroughly marginalized.
