Security is a Pricing Problem

The way we build our teams is causing our exploding vendor costs

In this post, I cover:

• Two types of pricing models products can have

• How these models apply differently to vendors for engineering and security teams

• The negative impact this has for security teams, and what we can do about it

Pricing Models

There are, roughly, two kinds of pricing models. ¹

The first is value-based pricing. Here, the vendor tries to extract as much of the value their product provides as they can. If some tool provides you $100 of value, they would love to charge you $95 for it. This is just enough that you're still getting that $5 of excess value from the transaction and are incentivized to still buy their product, but they get to buy a yacht. People paying significantly more than they want for their vendors may call this value fucking.

Many things can impact the amount of value they can extract:

• Customer knowledge - When your customers have some idea of how much things cost, they get very mad when this is too large of a gap below what they paid.

• Competition - Getting into price wars with your competitors really kills how much value you can extract.

• Availability of alternatives - What else you can spend your money on to solve a similar problem or get a similar amount of value constrains the value extracted. The price of shovels can constrain the cost of snowblowers.

• Urgency - How much time a customer has to shop around can impact how much value can be extracted. HVAC techs can charge more for emergency repairs to your heating in a deep freeze. We mostly frown upon this, so we have price-gouging laws.

The second is commodity pricing, which is tied to the cost of producing the product. This occurs when one or more of the above constraining factors is taken to an extreme. Examples include mature industries, where significant competition over decades has driven down the price to commodity levels.

It also occurs when the customers have strong alternatives. One of the strongest is a way of providing the product themselves. Apple's ability to bring the production of iPhone components in-house keeps their existing third-party suppliers in mortal fear, giving them the lowest possible prices. You can think of this as the value provided by your vendor not being the product they provide you, but saving you the effort of doing it yourself, which is usually much lower.

Pricing in Software Engineering Tools

In software, product segments quickly push toward commoditization. Several reasons:

• The engineering teams you sell to usually understand how your product might be built, and what the marginal costs of operating it for them are.

• Software engineering organizations are often able to build your product. Software engineers want to build the thing instead of buying it. That's why they got into that field, to build software.

• Ample OSS options mean the cost of building instead of buying is always decreasing. The alternative to Oracle SQL databases isn't having to design a whole new database, it's just the cost of paying a database admin (or AWS) to run some Postgres instances.

• Most software traditionally has very low barriers to entry.² If you're able to extract a high margin for yourself, other founders will raise oodles of venture capitalist cash and crash your party.

• There often isn't high urgency. Software engineering tools speed up building, testing, or operating other software systems, not immediately solve all problems.

• Software engineers like to complain on Reddit, Twitter, and Hacker News when people value fuck. DataDog getting $65 mil/yr a year out of Coinbase was a big story.

Notably, Coinbase significantly reduced its observability costs to $10 mil/yr by leveraging all the above points. It's hard to have high-value extraction in the software vendor space. The ease of entry to the industry pushes towards commoditization, and buyers’ ability to build it themselves means the value a product can extract is the cost of building and maintaining it. It doesn't matter if your fancy system provides $10 million in business value; if it costs $500k to run internally, you can get, like, $450k.³

Security is a Pricing Problem

Security does not operate like the software space, which surprises people who move from one to the other. It turns out, it's very easy to value extract in the security vendor space:

• Many security practitioners are not software engineers by training, have little idea of how a product is built or the costs involved, and have limited ability to build it themselves.

• There’s less OSS footprint in the security space, and most of what exists is only usable by a few technical teams.

• Security products tend to have higher barriers to entry. Many products require significant up-front data investment to identify enough issues to be valuable. It’s harder for security teams to build tooling on top of a smaller, core product, so security products need to be more feature-complete to compete. If you’re familiar with crossing the chasm, security sales tend to start somewhere in the early majority; there aren’t many innovators and early adopters to sell to.

• It's hard to trust a random series A startup with a critical security function; they can't afford a dedicated security engineer yet. So, a company has to scale significantly (or sell to Palo Alto) before it can sell to enterprises seriously.

• There can be very high urgency in the purchase. Think of all the threats that you're missing!

• Relationship sales is a bigger deal in security; CISOs tend to like and trust their reps, and rely on them for advice on securing whatever new stuff the kids these days are using.

• Since security teams cannot build their tools themselves or transition easily, and have stronger relationships with their reps, their ability to negotiate is compromised. Vendors take advantage of this. I’ve seen price differences as high as 8x between similar companies buying the same tool with roughly the same usage.

• While security teams often complain about the costs of tools like Splunk, it's more with resigned acceptance than with anger or a strong desire for change.

This means it can be slow for security product segments to commoditize, and the value vendors extract is related to the value of securing the company, not the cost. Many founders who pivot into the security industry from the software space are shocked by how behind the industry is, both in available tech and pricing. Most vendors aren’t innovating, they’re selling basic tooling for large markups.

Slapping the words security on a product can lead to 50-1000% markups over the same product sold to software engineers. Security Information and Event Management (SIEM) systems have historically commanded much higher prices than traditional logging solutions, even though they are basically the same thing. Logging vendors like Splunk and Elastic shifted to being primarily security companies because they offer stability and juicier margins.

This is expressed in how product categories evolve. Vulnerability management systems are standard, commoditized products that scan your exposed IPs, your internal containers, hosts, etc, and report on the vulnerabilities they find. Cloud security posture management (CSPM) solutions are standard, commoditized products that read your cloud state and tell you all of the insecure misconfigurations you have. Each of these products will cost a medium-sized software company ~30-50k.

Cloud-native application protection platforms (CNAPPs) are products that do both of these things and, more importantly, have them talk to each other to guide prioritization. You can focus more on vulnerabilities in systems with horrible misconfigurations that make them more exploitable or care more about cloud misconfigurations when they impact vulnerable code. You can script this together yourself pretty easily using the APIs both types of tools provide. If you can't or don't want to, you can buy a CNAPP. To save you the effort of building that connection yourself, CNAPP vendors will start their pricing around a cool ~$1 million. This will almost certainly negotiate down, but you can still end up paying a 4-8x markup over the price of both a CSPM and vuln mgmt tool. Value extracted.

Pricing Is Holding Back Security

This pricing dynamic is holding our industry back.

It hurts organizations and companies having to pay the prices. It’s hard to fund a security program or spin one up quickly with more than a handful of tools. This limits the effectiveness of teams; every cost tradeoff they make makes their org less secure. This especially hurts smaller companies and startups. If you're a 30-person series A company, even if you care deeply about security, it's hard to find the money for a single dedicated security hire. Let alone the 7 figure tools budget they may want to bring in.

It hurts practitioners. Many security engineers go without newer, state-of-the-art tools; their businesses can't afford them. This hurts skill set development and keeps much of our talent clustered around aging, legacy tools. This also means that teams can have to build a lot of stuff internally. I've built the same 5-7 core systems at every company I've done security for, not because I especially loved writing the same services and scripts in a new language each time, but because the vendor options would have bankrupted me.

It hurts real, living people. Ultimately, the whole point of what we are doing is to protect the data and systems of our users and customers. Every value-extracting vendor places their customers and the systems they safeguard at greater risk by reducing what a security team can afford to protect from.

Some Solutions

We need to hire more software engineers to do security, or at least security engineers who can code and enjoy it. Security engineering becoming more like software engineering is a concept that's gotten some play recently, and I aggressively agree. The value builders can bring in, you know, letting your teams build things to solve their problems rather than buy cannot be overstated.

The value the zeitgeist has missed is what having more software engineers in your security organizations does to vendor pricing: The more of a coding discipline we are, the more we can shift security vendors from behaving like security vendors to behaving like engineering vendors. You don't need to wait for industry upheaval to get this improvement. I exclusively hire security engineers with a coding background. I can build lots of my own tools when that’s the best fit. I also consistently negotiate cheaper prices on the tools I buy because I can and have just built (minimal viable versions of) them, and make sure my sales reps know I can. This price advantage alone has more than made up for the slightly higher salaries.

We need more on-prem offerings. A reason it's hard to use the exciting security tools out there is it is pretty hard to trust a 9-person startup with zero security engineers and half of an ops engineer to provide a security-critical SaaS. I think security startups especially need to turn away from SaaS and ship on-prem solutions, preferably in a source-available and auditable way, to make experimentation easier and trust faster to obtain. This requires we start hiring more software engineers; part of the push to SaaS is that many security teams can’t maintain purchased tools in-house.

We need more open-source software. Software stacks are often built almost entirely with OSS, with vendors as the exception. We need our security stacks to be the same, rather than the massive list of vendors we deal with now. We need to contribute back to the OSS we use to keep them thriving in the form of contributing code, promoting the projects and your uses of it, or (some) money to the maintainers or managing companies. OSS (or very cheap/free editions) have ensured Burp Suite, Metasploit, and more recently Ghidra are in every red teamer’s toolkit. Semgrep is the only code-scanning to get significant mindshare. OSS is a great approach to building future security companies.

I'm not speaking to the vendors here; we can't just plead for them to charge us less. They're doing what the incentives drive. We aren't victims here; we need to shift the resigned way we complain about our vendor spend.

1. As with every model explaining reality you read in a blog, this is my own made-up model. Plenty of people have their own descriptions of pricing models.

2. Ignore AI for now, okay?

3. This is a bit idealized. Even if the theoretical cost of running a piece of software is 500k, maybe your engineering teams suck, and doing it internally would be $3 million. Vendors definitely move to try and extract that excess value. This is how I think Oracle continues to make money, extracting value from companies not competent enough to run (or at least migrate to) Postgres. I may be biased, but this probably also explains DataDog’s pricing model.