Developers don't care about security
A repost on one of the most popular initial posts
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
I’ve been traveling and working on performance reviews, so I didn’t get a chance to write this weekend. This is a repost of one of my more popular initial posts.
I wrote the post below during a time when there was a big push for “shift left” and developer security. Snyk was growing fast, and it was clear that existing security products didn’t work in cloud environments, leading to the rise of Wiz and Lacework. However, security people had to deal with a new buyer: developers. It’s an area in which security has struggled, and they even had to create teams to deal with engineers (application security teams). These tools have always been a source of friction between engineers and security. What’s very clear is that developers will always be a core part of the security story going forward. We can no longer, in a tech-driven world, have security and developers be separate. That’s why it’s important to think about how developers think about security. Another additional nuance is that in engineering organizations, most decisions are bottoms-up, unlike security organizations where decisions tend to go top-down. There’s also the notion of a staff+ IC, which tends to have a director or even VP-level decision-making abilities that rarely exist in traditional security organizations.
Much of my repost below still applies, and security products and companies continue to struggle to understand the developer persona.
In the past few months, I’ve written about how the cloud is fundamentally changing security and how security teams are struggling to adapt to this new world. The main phenomenon is around DevOps and the speed of deployment. The elasticity of the cloud is allowing for more rapid feature and application deployment, which is a security nightmare. Because of this, security has lost control and is actually seen as an impediment. Ever since I embarked on my journey to better understand cloud security, I’ve talked to many CISOs and security practitioners. They’ve said that I’ve identified a problem, but what is the solution?
In my mind, it’s simple. We need a new way of selling and consuming security products that’s amenable to the paradigms that the cloud enables. (I know this is easy to state but hard to execute.)
First, who are the stakeholders in this new world? DevOps and security. But really, it’s DevOps because security needs help from DevOps. So why is security hard? Because developers don’t care about security! A developer expects to work on the product. I doubt that a developer is going to find cool security tools and evangelize them unless, of course, they are a security engineer. They are more likely to find tools that make them more efficient and deliver products faster, which seems reasonable.
So, how does a company do security when the main stakeholder doesn’t care? First, we need a tool that can meet the requirements of security and that DevOps also likes to use. Each party still does their job, but the end user is not just security.
What does this mean practically? Security cannot buy traditional enterprise security tools with long sales and deployment cycles. No developer wants to engage in a 9-12 deployment cycle with a sales engineer, solution architect, and an account executive. (I mean who does?) If we look at popular DevOps companies/tools like Hashicorp, LaunchDarkly, DataDog, etc., they all have easy-to-deploy, “slick” tools. Most traditional security tools are not like that. Most of them are clunky and sometimes require lots of services to be operational. If an organization can get Palo Alto Networks and Cyberark to work within a day, that company should win the Turing Award.
How does this change the way security products are sold? Gone are the days of long sales cycles and steak dinners. I no longer believe in selling to the CISO, but rather there will be CISO-facilitated sales.
What is a CISO-facilitated sale? The CISO has the budget and the responsibility for a cloud security issue. However, they aren’t the sole decision maker. Their job and the job of security is to ensure the tool meets security/compliance requirements. Then, they ask DevOps if they are willing to deploy, use, and maintain it.
The advantage is that, unlike typical DevOps tools, security has a clear budget. The ease of deployment will improve time to value and reduce sales cycles. However, the disadvantage is that more stakeholders lead to more difficult sales, i.e. you have to make both security and DevOps happy. The contract sizes will be smaller because ease of deployment typically correlates to fewer features and a higher possibility of churn.
Right now, companies like Snyk, Capsule8, and Signal Sciences validate my thinking. DevOps companies getting into security, such as Hashicorp and Datadog further my thesis. I believe this is just the beginning of the shift in security, and COVID has accelerated this by forcing a digital transformation, especially in e-commerce and remote work tools.
Some open questions:
What cloud security problems require DevOps assistance?
How will DevOps change security priorities? What security priorities will go away and what will be elevated?
How will enterprise security companies change their GTM motions? Will we see DevOps and security company mergers? or will DevOps companies eat security’s lunch by introducing security features?
Perhaps, I am exaggerating this issue, but what’s clear to me is that companies are moving to the cloud faster than ever, and with security falling behind, there will be serious gaps. And we can’t solve these gaps in the same way that we solved security gaps in the data center.