Presenters

Source

Security vs. Developer Experience: Finding the Balance 🛡️🚀

In the world of software development, we often treat Security and Developer Experience (DevEx) as natural enemies. One wants to lock everything down, while the other wants the freedom to move fast. But is this friction inevitable, or are we just doing it wrong?

We sat down with Abby Bangser, Adrian Mouat, and Holly Cummins at a recent GoTo conference to unpack this tension, explore the “fear-based” culture of security, and discuss how platform engineering might finally bridge the gap.

🎭 The “Fear” Problem: Why Security Feels Like a Burden

Security is arguably the most thankless job in tech. When security is done perfectly, nothing happens. There are no breaches, no headlines, and no chaos. Consequently, nobody notices the effort, and nobody says, “Great job.”

However, when things go wrong—as seen in high-profile incidents like Log4j, SolarWinds, or the Jaguar Land Rover breach (which reportedly cost a staggering 2 billion pounds in supply chain fallout)—everyone suddenly cares.

  • The Tradeoff: Security is often treated as an afterthought or a “hurdle” to productivity. This leads to Shadow IT, where developers bypass security controls just to get their work done. When you make tools inaccessible, you don’t get more security; you get more insecurity because people find workarounds.

🏗️ Platform Engineering: The Path to Enabler, Not Enforcer

The panel agreed that the traditional “Dev vs. Ops” model has evolved, but we are now facing a similar “Dev vs. Security” divide. The solution? Platform Engineering.

  • The Goal: Centralize access to tools and best practices without centralizing control.
  • The Contract: Instead of forcing every team to become security experts, platforms should provide secure defaults.
  • The Anti-Pattern: A platform team that acts as an “enforcer” who says “no” will always fail. A successful platform acts as an enabler, providing “golden paths” (like secure base images or pre-configured infrastructure) that make the secure way the easiest way.

🔍 Key Takeaways & Practical Wisdom

1. Shift Down, Not Just Left 📉

Instead of just “shifting left” (asking developers to do more security), consider “shifting down.” This means moving security responsibilities into the infrastructure layer. If the infrastructure is secure by default (e.g., S3 buckets that cannot be public), the developer doesn’t have to worry about misconfiguration.

2. The Shared Responsibility Model 🤝

We need a clear shared responsibility model for internal teams, much like the one we have with cloud providers like AWS. If the platform team provides a service, they should own the security of the underlying infrastructure, while the application team owns the data and business logic.

3. Beware of “Security Theater” 🎭

  • Gamification: Red/Green teaming or chaos engineering can be great, but only if teams have “build it, run it” responsibility. If a team doesn’t run their own software in production, they have little incentive to participate in these exercises.
  • The AI Trap: Companies banning AI (like ChatGPT) often create a false sense of security. Employees will use it; if you don’t provide a secure, enterprise-licensed version, they will use personal accounts, potentially leaking sensitive proprietary data.

4. Professionalism in Software 📜

Why don’t we have professional certifications or liability in software like civil engineering?

  • The Hurdle: We struggle to define what “quality” means.
  • The Reality: Until we have a consensus on quality and a way to hold manufacturers liable for insecure products, we rely heavily on insurance and reactive patching.

💬 Audience Q&A Highlights

Q: How do we make security “sexy”?

  • A: It’s difficult because it’s currently sold via fear. The best approach is to find the “wins”—places where security improves the developer experience. For example, password managers aren’t just secure; they save time. When security solves a pain point rather than adding a hurdle, developers will actually want to use it.

Q: Should we use SSL inspection (man-in-the-middle)?

  • A: It’s a contentious topic. While it provides visibility, it effectively functions as a centralized man-in-the-middle attack. Use with extreme caution!

🎯 The Bottom Line

Security shouldn’t be a secondary job for software engineers. By building composable platforms that provide secure, sensible defaults, we can stop treating security as a “No” department and start treating it as the foundation of a healthy, productive engineering culture.

Let’s stop being afraid of the breach and start building the guardrails that allow us to move fast—safely. 🚀✨

Appendix