Frankly Speaking 3/2/21 - Stop forcing security and engineering to collaborate!
A biweekly(-ish) newsletter on random thoughts in tech and research. I am an investor at Dell Technologies Capital and a recovering academic. I am interested in security, AI/ML, and cloud.
If you were forwarded this newsletter, you can subscribe here. For more regular updates,
Palo Alto Networks is taking cloud security seriously, buying up Bridgecrew, which focuses on doing infrastructure as code security. This is an expanding market as more companies use Terraform and Cloud Formation to manage their cloud configurations. New security needs will continue to appear as organizations become more sophisticated cloud users.
At the very least, all my deep dives into cloud security are not in vain!
Also, Solarwinds is blaming an intern for their security problems. Seriously?! That’s the oldest trick in the book… Come on, where is the originality! Again, another reason legacy security players can’t keep up in this day and age.
LET’S BE FRANK
I don’t know how many times a week I hear about a company in the “DevSecOps” space. My first question is almost always “Do you need security and developers to collaborate to deploy?” If the answer is yes, it’s going to be an uphill GTM battle with long sales cycles. But why?
Let’s just say what everyone doesn’t want to say: Security and engineering are not meant to work together, and they don’t want to work together.
So, stop forcing them to work together! Stop developing products that require DevOps and security to work together to use. To board members and the C-suite, stop forcing your DevOps and security leaders to figure out how to work together. It’s a waste of time!
Why can’t security and engineering get along? In some ways, it’s the fault of the organization and C-suite, and in some ways, it’s just how the market is. At a high level, their conflicting goals don’t incentivize them to collaborate. I kind of hinted at some of this tension with my articles about why developers don’t care about security and how security needs to force developers to do security. The relationship is anything but collaborative. In fact, I don’t think cloud providers care about security.
What’s the source of this tension? It’s simple. Developers are part of the core business, and security is a cost center. They have fundamentally different goals.
Developers want to work on product, not security. Products drive revenue growth while security prevents loss of revenue. The risk-reward mechanics don’t line up.
Security wants visibility into DevOps workflows, but DevOps doesn’t want to give them access because they worry that security will mess up the product. This is a valid concern since security doesn’t understand the product priorities because it’s not their job to understand.
Security costs are operational while DevOps costs are related to the gross margin.
DevOps is about velocity and efficiency while security is about risk mitigation, which is inherently inefficient.
The list of goal/agenda differences goes on.
Here lies the tension! DevOps and security have agendas that are not aligned, so what’s the incentive to work together?
Why is this tension happening now? Before the cloud, IT deployed infrastructure rather than developers. IT and security had a good relationship. You might have guessed it. They both understood each other because they are both cost centers.
In some way, this is why I believe traditional security companies are having and will continue to have trouble breaking into cloud security. They assume that security will have the same relationship with DevOps as it did with IT, but nothing could be further from the truth. It’s no surprise that traditional security companies have to acquire to develop their cloud security strategy rather than develop it organically. The product and GTM suppose a strong connection between security and infrastructure, which doesn’t exist in cloud security.
I can go on forever talking about how the cloud has changed technology and IT in general. If you’re interested in learning about these changes, I would encourage you to read the developer-led landscape by my partner, Tyler Jewell.
Changes in infrastructure drive changes in security needs. However, the cloud has created an interesting change. It has deeply tied infrastructure with product, turning infrastructure from a cost center to a line of business. For example, companies are spending a lot of time and money modernizing their data infrastructure as they see it as critical to their product. Just in security, we see companies like SentinelOne buying Scalyr and Crowdstrike buying Humio to modernize their backends. No surprise that Snowflake is valued at over 70B and has such high net retention rates. Data infrastructure is just one example of infrastructure being core to the product. This focus on infrastructure is driven by the movement to SaaS. Companies are now in control of the infrastructure their products run on, and that the performance of that infrastructure is an important point of differentiation.
In a world where infrastructure is viewed as a core component of the product, what are the consequences for security products?
I think the most successful cloud security projects in the near term will provide security with visibility into DevOps workflows like CI/CD and the cloud without requiring any collaboration from DevOps. For example, companies like Orca and Wiz can do vulnerability management, cloud posture management, and cloud workload protection without an agent, thus requiring no collaboration.
Of course, I don’t think this dynamic will last forever. The market will eventually shift so that infrastructure and security will both be important components of the product, thus no longer cost centers but parts of lines of business. In fact, we are seeing some shift already in certain products like video conferencing where encryption is a key feature. As a result, new security products and GTM will emerge.
However, for now, we can’t change markets but meet them where they are. So, really, stop forcing security and engineering to work together!
TWEET OF THE WEEK
We really need to change this terminology!
