Security teams have a problem. Developers hate working with them.

This isn’t because developers don’t care about security. It’s because most security teams operate like they’re still living in 2005.

Contents

The Old Way Doesn’t Work

Here’s what happens at most companies:

Security teams buy tools. Lots of tools. Vulnerability scanners, compliance dashboards, penetration testing services. They think more tools mean more security.

Then they dump alerts on developers. “Fix this CVE 9.8 score vulnerability immediately!” they say. Never mind that the vulnerability is in test code that never sees production. Never mind that the developer has three product deadlines this week.

Developers get flooded with noise. They start ignoring security alerts. Security teams get frustrated and add more process. More approvals. More gates.

The cycle continues.

Meanwhile, developers have real problems:

  • Product managers want new features shipped yesterday
  • Infrastructure keeps changing
  • Technical debt piles up
  • Performance requirements get tighter
  • Users expect zero downtime

Security shows up saying “drop everything and patch this library.” The library works fine. The patch might break things. The developer has no context about why this matters.

So developers start seeing security as the enemy.

The AI Blind Spot

While security teams chase traditional vulnerabilities, they’re missing a bigger problem: AI. Developers are already putting AI into applications. Chat features, code generation, data analysis, automated decisions. While security teams are still arguing about OWASP Top 10 items from 2003.

AI brings new risks:

  • Prompt injection attacks
  • Model poisoning
  • Data leakage through training
  • Biased outputs
  • Supply chain risks in AI models

Security teams don’t understand these risks. They don’t have tools for them. They don’t know how to test for them. Meanwhile, developers are shipping AI features every week.

What Big Tech Companies Do Different

Companies like Netflix, Google, Amazon, and Spotify figured this out years ago. They don’t fight developers. They help them.

Netflix: Make Security Easy

Netflix built what they call “Paved Roads.” These are tools and platforms that make doing the right thing easier than doing the wrong thing.

Example: SSL certificates. Most companies make developers figure out certificate authorities, renewals, and deployment. Netflix built Lemur, a tool that handles all of this automatically. Developers just request what they need. The tool does the rest.

If a developer wants to manage SSL certificates manually, they can. But they take on all the work and risk. Most choose the easy path.

Google: Remove the Network Boundary

Google realized that traditional network security doesn’t work anymore. People work from coffee shops, home offices, and airports. The “trusted internal network” is fiction.

So they built BeyondCorp. Every request gets checked, no matter where it comes from. Developers don’t need VPNs or special network access. They just log in with their identity and device context.

The security is invisible to developers. They work the same way everywhere.

Amazon: Security as Code

AWS teams treat security like any other engineering problem. They automate it. Security policies become code. Compliance checking happens in build pipelines. Threat modeling uses templates.

Security teams provide tools and training. Developers integrate security into their workflows. No separate security review process. No waiting for approvals.

Spotify: Golden Paths

Spotify created “Golden Paths” - step-by-step guides for building things the right way. Want to deploy a new service? Follow the Golden Path. It includes security, monitoring, deployment, and operations.

New developers learn these paths during onboarding. Following the path is easier than figuring things out alone. Most people stay on the path because it works.

The Key Insight

All these companies realized the same thing: Security should enable developers, not block them.

When security makes developers faster and more productive, developers choose security. When security slows them down, they find ways around it.

How to Fix Your Security Team

Security: Old Way vs New Way Old Way: Security Gates Developer Wants to ship features fast Security Review STOP! Compliance Check WAIT! Production (Eventually) Problems: • Developers wait for approvals • Security becomes bottleneck • CVSS alerts without context • Developers avoid security team • More tools = more noise Scanner 1 Scanner 2 Scanner 3 Too many tools! New Way: Security Guardrails Developer Builds on secure platform Paved Road Security built-in Production (Fast & Secure) Benefits: • Security by default • Developers move fast • Automated compliance • Risk-based priorities • Developers choose secure path Who does this: Netflix Google Spotify Amazon Key Difference: Old way: Security blocks developers New way: Security enables developers

Stop Buying More Tools

You don’t need another vulnerability scanner. You need to understand what developers actually do all day.

Sit with developers. Watch them work. See where security creates friction. Fix the friction.

Build Guardrails, Not Gates

Instead of approval processes, create constraints that prevent problems from happening.

Example: Instead of reviewing every cloud deployment, create templates that only allow secure configurations. Developers get faster deployments. You get compliance by design.

Make Security the Easy Path

If following security best practices is harder than ignoring them, people will ignore them.

Build tools that make security automatic. Provide libraries that handle encryption correctly. Create deployment pipelines that include security testing.

Measure Developer Productivity

Track how much time developers spend on security work. If security requirements slow down feature development, figure out why. Fix the tools, not the requirements.

Focus on Business Risk

Stop using CVSS scores as the only priority system. Ask these questions instead:

  • Is this code path reachable in production?
  • What happens if this vulnerability gets exploited?
  • Are there compensating controls?
  • How much effort is the fix?

High CVSS scores in test code matter less than medium scores in payment processing.

Provide Context

When you ask developers to fix something, explain why it matters. What’s the business risk? What’s the attack scenario? How does this relate to their specific service?

Developers are smart. If they understand the problem, they’ll solve it.

Start Small

You don’t need to rebuild everything at once. Pick one pain point. Maybe it’s SSL certificate management. Maybe it’s security scanning in CI/CD. Maybe it’s access reviews.

Build a tool that solves that one problem better than the manual process. Get feedback. Improve it. Then move to the next problem.

The Result

When security teams work this way, developers stop seeing them as blockers. They become enablers.

Developers start asking security teams for help instead of trying to avoid them. Security problems get fixed faster because developers understand why they matter.

Security teams spend less time nagging and more time building systems that prevent problems.

Everyone wins.

The Bottom Line

Security doesn’t have to be the enemy of speed. It just requires thinking like a product team instead of a compliance team.

Your customers are developers. Make their lives easier, and they’ll make your systems more secure.

Stop fighting developers. Start helping them.

Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.

Thank you for reading!

Back to Top⮭