Developers' Stake in Security Tooling

It used to be security tooling was sold to security folks (compliance, audit, CISO offices, etc.); actually it still is largely. But more and more we see developers driving security tooling conversations. These days we even see development orgs actively pursuing security tooling ahead of their security counterparts.

Before appsec, my background was infrastructure security (15 years), and I still follow a lot of that technology. I’m not sure I see the same paradigm shift for network security, infrastructure security, database security, etc., and security functions around those technologies still seem largely reactive (i.e., primarily used after production deployments in the form of audits/pen tests).

Are developers just trying to ease their own pain by helping drive the appsec tooling conversations and pushing for tooling they like or has something else changed?

This is somehow complementary to the topic I recently raised:

I think that most developers are happy to test their code for security issues as early as possible, learn from their mistakes, and proudly deliver safer code. Having said that, the developers I know, would not go far beyond their IDEs and CLIs.
@Chris, I think that what you see is not necessarily a shift in the developers’ state of mind, but in the security vendors’ one. When security companies are shifting products from dashboard-first to developers-first, the developers are happy to join the ride.


I think that’s the point @Erez – devs don’t want to leave their friendly ecosystem of IDEs and CLIs. Security tooling that allows them to stay there will be more attractive to them. I think their voice in the conversation is getting louder for that reason, and let’s be honest, what application security org inside any company wouldn’t want to cater to the asks of the community they are trying to help evolve toward a more security-focused mindset.

The vendors are obviously catching on as well – Let’s build what developers want

I agree with you; I think devs generally want to write secure code, but if writing secure code turns their workflows upside down, their appetite to ‘join the ride’ diminishes greatly.


Couldn’t agree more on the ecosystem of tools, platforms, and techniques that most devs don’t want to bail on. Myself included!

If I have to learn a handful of new tools and such then there’s a way larger barrier to entry for me to even consider uptake, let alone long term adoption. It has to go from “good enough”, to “incredibly impressive” for me to be willing to invest the time and energy from myself or my team(s) of devs to sink their teeth into something that requires significant new learning.

Agreed - give us what we want so we can work how we work, and get the goodness of