“I calculated that it will take us more than 100 years to pay down the backlog.”
This was the conversation I had a few years ago with a security engineer at a major bank. His comment represents daily reality in software development. Security generates alerts. Developers ignore them. Security backlogs grow. Real vulnerabilities persist. The cycle continues.
A few years ago, the “shift left” was promised as a solution. By moving security earlier in the development process, we’d catch issues sooner, when they’re cheaper to fix. The concept makes perfect sense in theory. In practice, however, results have been mixed.
The problem isn’t when security happens. Instead, how security is implemented is far more important than when. Simply moving security gates earlier in the process is insufficient. Additionally, throwing tools at the problem inevitably adds noise without much signal. True developer-first security isn’t about gates at all; it’s about guardrails.
The False Promise of Traditional ‘Shift Left’
Shifting left has dominated security conversations for years, but many implementations have failed to deliver. I’ve watched organizations move their security checkpoints without changing their approach. Common mistakes that I’ve seen personally include:
- Moving the same blocking security gates earlier in the process without improving signal.
- Adding security tools without considering developer experience.
- Treating developers as aspiring security engineers.
- Measuring success by number of findings versus ones that actually matter.
- Making security a binary pass/fail rather than a continuous process.
These approaches ignore a crucial reality: Security is often forced on developers rather than built for them. As a result, developer resistance to disruptive security measures is rational, not negligent.
Understanding the Developer Mindset
As a former developer, I can confirm that developers don’t hate security — we hate useless interruptions. And all the incentives in the field are to go from zero to “it works” as fast as possible. Security is a feature, not a necessary part of functionality.
But developer cognitive load is already substantial — managing complex codebases, learning new frameworks and meeting tight deadlines. If security tooling doesn’t fit into that reality, developers won’t use it. Developers are evaluated on shipping features, not preventing breaches.
When we add security responsibilities without considering this context, we’re setting up both developers and security for failure.
Security must adapt to developers, not the other way around. Not because security is less important, but because it’s only effective when it’s adopted, actionable and trusted. The goal isn’t zero vulnerabilities. Rather, it’s surfacing critical issues that actually matter and putting faster fixes in place that are embedded into developer workflows. Don’t try to turn developers into security engineers — try to make security invisible by default.
Like Jason Chan — who coined the terms “guardrails vs. gates” and “paved road” — says: “By adopting gate-based security we are explicitly choosing known anti-patterns to developer productivity.”
Gates vs. Guardrails: Reframing the Approach
Security gates are binary, blocking mechanisms that operate on a pass/fail basis. They create artificial checkpoints that interrupt workflow, often introducing delays and frustration. Gates fundamentally operate through control.
Guardrails, by contrast, provide continuous guidance without blocking progress. They mark safe pathways while allowing freedom of movement within defined boundaries. Guardrails operate through empowerment rather than control. For example, a security gate might block a developer from merging code because of a potential SQL injection flagged in a third-party library, even if it’s unreachable or already mitigated upstream. In contrast, a guardrail might highlight the same issue in the developer’s IDE with context about risk and remediation options, enabling them to address it if it’s relevant — without halting their work.
Guardrails succeed where gates fail because they respect developer agency. They recognize that most developers want to write secure code. They just need tools that help them do so without disrupting their creative flow.
Building Effective Guardrails
Implementing guardrails requires rethinking both tools and organizational structures. I recommend starting by auditing your current security processes: Where do developers experience friction? Which security checks consistently delay releases? These friction points are prime candidates for guardrail transformation.
Once you’ve identified these friction points, consider these key strategies.
3 Ways to Establish Effective Security Guardrails for Developers
- Involve developers in security tooling decisions.
- Create secure defaults and templates.
- Integrate security guidance directly into developer workflows.
Involve Developers in Security Tooling Decisions
The tools that look impressive in security vendor demos often fail in real-world development environments. The best security tools are those developers actively want to use because they make their jobs easier, not harder.
Create Secure Defaults and Templates
Developers shouldn't need to research secure patterns for common operations. Pre-approved libraries, infrastructure templates and code snippets with security built in allow developers to move quickly while remaining secure by default.
Integrate Security Guidance Directly Into Developer Workflows
The IDE is the developer’s natural habitat — security guidance provided there, in real-time, is far more effective than feedback received hours or days later in a CI/CD pipeline or security review.
Technology approaches that enable effective guardrails include:
- IDE integrations that provide real-time security feedback.
- AI-powered code completion that suggests secure patterns.
- Pre-commit hooks that catch issues before they enter the codebase.
- Infrastructure as code templates with security best practices built in.
- Policy frameworks that enforce guardrails without manual intervention. These frameworks define security rules and best practices in code, automatically applying them across projects without requiring security teams to review every commit.
Organizational changes are equally important. Security teams must evolve from gatekeepers to enablers. This means developing new metrics that balance security and velocity, creating shared ownership of security outcomes and building cross-functional alignment.
Measuring Success and Making Guardrails Actionable
The effectiveness of guardrails should be measured by outcomes, not activities. Look for:
- Reduced security-related deployment delays
- Faster remediation times for vulnerabilities
- Increased developer participation in security initiatives
- Fewer security bypasses or exceptions
- Reduction in security issues found in production
- Higher security tool adoption rates across engineering teams; and vulnerability classes that don’t come back
Gates catch bad actors on paper. Guardrails help good teams move faster, safer, better. If you’re still using gates, you're still playing defense. Guardrails let you play offense.
Security doesn’t need to slow you down. It can be the thing that makes you fast if it’s built right.
