Tensions and opportunities for cybersecurity founders: considerations when building a security company

These aren't black-and-white decisions with clear-cut answers; the value comes from thoughtfully considering each factor.

There is no lack of advice on how to build a startup. In fact, every founder will confirm that the moment one decides to start a company, everyone is eager to tell them what they should be doing. From VCs and angel investors, to industry insiders, market analysts, security leaders, security practitioners, and anyone active on social media, - there is no shortage of opinions, perspectives, and things founders “must keep in mind”. In all this multitude of signals, it’s important to retain the ability to think clearly, and for that it can be helpful to think in systems. Systemic thinking is greatly underrated: we are so caught up in trying to chase the next big thing and identify the next growth hack that too often we steer too far away from the fundamentals despite the fact that these fundamentals generally remain relevant no matter what.

To write this piece, I partnered up with Jason Chan who spent nearly 25 years in cybersecurity most recently as a CISO at Netflix. Although Jason is now retired, he continues to be active in the security community as a startup advisor, mentor, angel investor, and advisor for Bessemer Venture Partners. Jason’s perspective is in great alignment with a lot of the work that I’ve been doing at Venture in Security, so it only makes sense that we finally work on an article together. In this article, Jason and I discuss some key opportunities and tensions for security founders in the current market.

---

---

We are still in the stone age of cybersecurity

There are over 5,000 cybersecurity startups across what looks like a hundred different categories and sub-categories. Without any doubt, that’s a lot of products to navigate but whether 5,000 is “too many” or “not enough” will depend on the way you think. Generally speaking, there are two ways to look at the state of the market: by looking at the evolution of security as a single industry, and by looking at security in the context of the larger tech ecosystem.

Cybersecurity has been through a lot of evolution over the past three decades. Before looking at what’s left to do, it’s critical that we acknowledge a long list of achievements we should be proud of. From the establishment and the subsequent rise of the CISO role, to growing international collaboration, permanent elimination of many classes of vulnerabilities, and retrofitting the internet infrastructure with security upgrades - these milestones are worth celebrating. At the same time, it’s equally important to acknowledge that while there are thousands of products out there, we are not as far along as many in the community would hope we’d be by now.

If we were to pose the question “How early is cyber security? Are we in the stone age? Middle Ages? Modern ages?”, we would likely not get a consistent answer. Both of us believe that cybersecurity is still in the stone age. In other words, we are early, we are still in the early days of security. We are making progress but it’s not in a vacuum. The world and tech ecosystem continue to evolve, so it’s to some degree a moving target.

Image Source: YouTube

Because we are so early, the adversary still has a huge advantage. Companies continue to get breached because of the same problems that were around five, ten and sometimes even 20 years ago - poor security hygiene, misconfigurations and software bugs, unpatched vulnerabilities - some things never change. Both of us are optimistic that in the years to come, things are going to change a lot, and defenders will be able to gain the upper hand. For that to happen, we need founders willing to tackle hard problems, and think in systems.

Hard problems are hard to solve

A lot of the easy problems in security like detecting known viruses have been adequately addressed. This doesn’t mean that there is no opportunity to innovate - on the contrary, there’s plenty of it. That said, problems that remain by and large aren’t there because nobody has tried tackling them. They continue to persist because they are hard to solve. To solve hard problems, founders need to think from first principles. That, in turn, means having a holistic understanding of tensions and opportunities in the cybersecurity market.

Tensions and opportunities for cybersecurity founders

We use the framing of tensions to highlight the many influences that founders must navigate as they are embarking on their founder’s journey. These aren't black-and-white decisions with clear-cut answers. Instead, the value comes from thoughtfully considering each factor and forming a perspective shaped by that reflection.

Time to value vs. moat

There was the time when security teams were open to deploying agents across their fleet, or spending months rolling out and configuring firewalls. These times are long behind us. Today, success is about time to value. It’s nearly impossible to convince people to deploy agents or in-line security tools. Products must be easy to roll out and validate.

Nearly every security tool today either asks for cloud/SaaS credentials (if they are focused on posture), or for cloud/SaaS logs (if they are focused on detection and response) to pull in a bunch of data and do something with it. The good news is that this makes it very easy to get started with new tools and understand the value these products are trying to offer. The bad news is that it’s hard to develop any moat when every tool relies on the same mechanism of data collection, and hence every tool has the same opportunity to solve problems. Take tools such as cloud security posture management (CSPM). It is straightforward to swap one CSPM for another, and they all have the same operational workflow: you plug the product into your environment, connect it to a few other products you are using such as ticketing systems, and see the newly implemented CSPM identify findings and start driving the remediation. So - this replacability is both a feature AND a bug - your perspective is key.

In the old days, companies selling appliances had a much longer time to value but they were also much stickier. Today, the model that required a significant upfront investment is dead. Even in network security, we see companies like Elisity and Zero Networks offering a different approach to segmentation, one that most definitely comes with trade-offs but offers quick time to value. Similarly, in past times platforms such as Archer, ArcSight, and Sailpoint could afford having a go-to-market that required complex multi-year implementations with professional services where the customer would have to spend on third parties more than on the tool itself. Today, it’s either near instant time to value or there is no deal.

In the world where many tools have similar architectures and implementations, the moat is no longer about technology. It is about user experience, brand perception, and continuous delivery of value. Companies such as Wiz realize that - and this realization drives them to keep building innovative products and keep dominating the marketing space. This new reality creates a perfect opportunity to build lovable products. When you think about other industries, it’s easy to find products with a cult following: Clay in sales, Canva in design, Superhuman in email, and so on. In security, some products such as Duo and Thinkst Canary have indeed been loved by CISOs and security practitioners alike. The challenge is these solutions solve 1% of all problems. There are no lovable products that tackle large swaths of a security teams problems. Building a large lovable platform is by definition very hard: by the time the surface area of the product grows too large, the company building it becomes a complex, bureaucratic behemoth. That said, just because it is hard does not mean it can not be done.

Differentiation vs. speed to market

A different facet of the same problem is what we would call a differentiation vs. speed to market conundrum.

Public cloud has democratized the ability to launch and scale software, making it possible to ship new products in a matter of days and weeks as opposed to years. Over time, as one after another startups contributed to the shared library of technology knowledge, we have largely demystified what it takes to build different types of products. In security, for instance, most detection-centric products look the same:

• There is some kind of data ingestion mechanism (agent/sensor, public cloud API or third-party SaaS integrations, etc.). A company would seek to build it as generically as possible so that it can over time expand the types of sources it supports.

• There is some kind of policy/detection and intelligence engine which analyzes the telemetry collected from different sources. When any of the rules match, an alert is generated which is frequently enriched with AI.

• There is some kind of automation/orchestration capability which allows taking the alert and triggering some form of step-by-step triage or remediation.

Every type of product (proxy, scanner, prevention, or remediation tool) will follow a different pattern. While each tool will undeniably have some nuances and unique facets, at the fundamental level the overall architecture and what it takes to implement these approaches is well understood and templatized.

Artificial intelligence shortens the time to market even further. Today, one can generate a list of requirements in one tool, turn these into a functional and well-designed user interface in another tool, and finally convert the user interface into a full-fledged product with an AI-generated back end in a third tool. It has already become possible to launch new applications in days, hours, and when it comes to early prototypes - even minutes, with little or no need to be fluent in any of the programming languages.

Given that most systems work by inputting some data and analyzing it, it becomes very hard to differentiate one product from another, both within and even outside of the product category. Cloud security posture management (CSPM), data security posture management (DSPM), or even cloud cost management all work more or less the same. The pattern where a product has to call an API, get some data, analyze it and output some recommendations means that over time, everyone ends up expanding into adjacent areas and thus lines between product categories start to blur. In other words, when everyone has access to the same data, everyone is building the same product. AI is only going to amplify this reality: we could assume that in the coming years, every company will have access to the same LLMs and the same publicly available data.

Cloud and AI enable a much faster path to market, but companies have to match that with their own execution to maintain leadership. There is no technical limitation that prevents someone else from building Wiz or, say, Vanta (Jason is an investor), and examples of Upwind and Drata illustrate precisely that. Differentiation is no longer about unique technology or insight, it is about end user experience and outcomes they are able to get. Consequently, the only high-confidence recipe to success is execution.

Platform vs. best of breed

Another parameter founders need to keep in mind is platform vs. best of breed solutions. A lot has been said on this topic (Venture in security alone has several articles dedicated to it, including “Every successful security platform started as a point solution”, “There are four ways to compete as a security platform”, and “Platforms vs. best of breed is a wrong way of looking at the industry” ). Instead of repeating a lot of what has been said at every panel event and every podcast (a variation of “consolidation is coming…”), let’s briefly look at the topic from first principles.

On the market side, consolidation is a continuous process. Large companies struggle to innovate so new approaches and ideas originate as startups. Over time, those that gain traction turn into features of larger products, generally through acquisitions. Back in the day, McAfee and Symantec were the ones consolidating the security market; today, it’s Cisco, Palo Alto, CrowdStrike, Okta, and private equity firms. Market consolidation isn’t “coming” - it has always been here. Market consolidation is a continuous process that is as natural in security as it is in every other industry.

On the customer side, what people refer to as consolidation looks quite different. Security leaders are always going to deal with this tension - is the bundle offered by some big vendor good enough, or do they care about some problem so much that they would be willing to buy a best of breed solution? Is having another vendor to manage going to drive enough additional value to offer compelling return on investment (ROI)?

The market side of consolidation is something founders understand pretty well. They know that most successful companies in security will get acquired, and that large enterprises have no other way to innovate and expand their offerings but to engage in M&A. When it comes to the customer side, social media makes us believe that “the time of point solutions is over and every CISO now is only going to buy platforms”. It makes sense that people would arrive at such a conclusion; the problem is it is not reflective of reality. It is true that the bar for customers to consider adding something new to their technology stack is at an all time high and continues to increase. After all, when everyone is trying to scare CISOs about every new threat, and when every startup is tackling the problem that supposedly causes 99.9% of all breaches (though every time it happens to be a different problem), it’s no wonder that CISOs have developed an immune response to FUD. However, whenever a CISO believes that a specific problem is one of the the most important for their organization , they will generally look for the best of breed solution in that area.

In order for point solutions to gain traction, they must be painkillers, not vitamins: they must address a pressing issue that security leaders are losing sleep over. For different CISOs these are going to be different issues (that’s where customer discovery and market sizing come in), but fundamentally someone has to care about the problem deeply to buy a best of breed point solution. For any problem where a “good enough” solution is deemed sufficient, startups simply have no chance against platform-focused incumbents.

Category creation vs. building in an existing market

Another decision point for founders is category creation vs. building in an existing market. Both are viable options and both come with a different set of challenges and opportunities.

Building in an existing market comes with pros and cons. The pros are that there is demand, established budgets, and that security buyers don’t need to be educated about the problem. The cons are that established markets are highly competitive, dominated by legacy players, and most companies aren’t interested in changing their tools unless there is a strong driver for them to do so. Just because something is 50% better is rarely a good enough driver for them to switch to a new vendor.

Startups creating a new category don’t face as much pressure from the incumbents. There are no expectations of how their products should work, and what features they should offer. On the flip side, there are no established budgets and CISOs my not be aware of the problem, let alone why they should be spending money on solving it. Startups pursuing the category creation path have to be first and foremost focused on market education - evangelizing about the problem they are solving, why it matters, and why people should care.

Category creators have to burn a lot of VC money on educating the market, and they are very unlikely to grow into big companies because of the “first to market” disadvantage. When category creators are successful, success generally means an acquisition. Later on, after the market gets established, a new player often emerges to capitalize on all the work and awareness early entrants have invested in building. A good example would be the CSPM market: early players - Dome9, RedLock and Evident.io got acquired by large companies (Check Point and Palo Alto). Companies like Sysdig and Lacework spent hundreds of millions of dollars on evangelizing the problem. Then, Wiz came in 2020 and executed - taking advantage of all the ground work done by the early cloud security players.

Today, the dynamics around category creation has changed. Because there is so much venture capital available, when a new category emerges, there is no longer just one market creator but a dozen co-creators. This was the case a few years ago for data security posture management (DSPM) and we are seeing it today with non-human identity (NHI). When there are many companies co-creating the market, it gives the new approach much more legitimacy but it also makes it much harder to compete since many companies are fighting for a smaller pie.

Outsourcing vs. insourcing

Another factor which influences what kinds of products can be built in security is whether we believe that security teams will be doing more outsourcing or insourcing.

While investors like to proclaim that security budgets are growing, we believe that we are at the peak when it comes to security hiring. In our view, in the coming years we will see companies shrink their security staffing budgets and seek to outsource whatever they can - from pentesting to managed detection and response and bug bounty platforms.

Outsourcing security makes perfect sense from the business perspective, and it aligns with the broader trend of delegating any non-core functions to third parties that can do them better and more cost-effectively. In the coming decade, we will see the rise of hyper-specialization where areas like recruiting, marketing, IT, and of course security will shift towards services even more than before.

This shift to services coincides with changes that make it easier for companies to scale service delivery. The most obvious factor that enables scale is AI. With LLMs, technology-first service providers can achieve levels of efficiency that weren’t previously possible. Another factor that makes scaling security services easier than before is growing monoculture in tools their customers rely on. We are at the point where one can capture most of the market by assuming that

• Everyone’s cloud provider is either AWS, GCP, or Azure

• Everyone’s EDR tool is CrowdStrike or SentinelOne

• Everyone’s cloud security solution is default CSP CSPM, Wiz, or Prisma Cloud

• Everyone’s directory is Microsoft or Okta

• Everyone’e code lives in GitHub, GitLab, or Bitbucket

• Everyone’s collaboration platform is Slack or Teams

• Everyone’s video calling platform is Zoom or Teams

• And so on….

Monoculture makes it much easier to scale service delivery and build solutions that can capture a broader chunk of the market.

The focus on outsourcing goes beyond just service providers. We are starting to see customers being willing to outsource the kinds of problems that some five years ago would have been inconceivable. A good example is the adoption of Chainguard for container images. Several years ago, nobody would have thought of delegating this problem to a third party but today, it’s a no brainer.

Cloud native vs. hybrid/on-prem (speed vs. comprehensive)

Nearly every new startup today has no choice but to first focus on the cloud-native technologies: it is what early adopters care about, and it is what is easiest to build (everything is an API). Only later, if and when the startup becomes somewhat successful with its initial use case, will it start thinking how to address customers with on-prem needs.

For most companies, prioritizing the needs of on-prem customers before cloud-native wouldn’t be a good idea: opportunities to address on-prem gaps aren’t expanding (certainly not as rapidly as opportunities in the cloud). And yet, it’s important to keep in mind that most companies out there aren’t cloud-only, and that there is real money to be made by securing hybrid environments. In addition, the longer this cloud-first thinking perpetuates, the more likely it will create an opportunity for contrarian bets that some startup will eventually be able to capitalize on.

Sometimes startups have no choice but to go cloud-only because alternatives are too complicated and founders have no experience in solving the complexities of on-prem. Data security is a good example of this in practice. Cloud-based data security posture management (DSPM) is an addressable problem, but if you think about enterprise -level hybrid DSPM, it becomes gnarly very quickly. Solving these gnarly problems is where real opportunities for value creation lie.

Generating findings (alerting) vs. helping fix permanently (preventing issues)

One of the decisions founders need to make early on in their journey is whether they are building a security product that is going to generate findings (alerts), or fix problems.

Every security leader will say that they don’t need yet another tool that tells them where they have problems. As Yaron Levi points out in his fantastic article on this topic, “visibility without action is just noise”. CISOs don’t want more tools that tell them what’s wrong. Instead, they crave solutions that help them implement foundational controls which are going to lead to better security outcomes.

The irony is that security buyers do need to know that there is a problem before they implement a solution. This means that any company pursuing new category creation has little choice but to start with the visibility layer. Those playing in an existing market can focus more on solving the problem, but those creating a new market have to first define what the problem is.

If a problem is well understood, the startup can take a different approach and build solutions that attempt to solve it at its core. Resourcely (Jason is an investor) is a great example of this in action: it helps companies prevent misconfigurations in the cloud by providing secure defaults.

There is value and need for controls across the traditional control spectrum of prevention, detection, and response. But,there are several reasons why few teams choose proactive tooling over reactive.

• It’s easier to show value and calculate ROI in detection and remediation, and many people like to start with a nice dashboard. Security teams can tie findings to the mean time to resolve (MTTR) and other well-understood and widely accepted metrics, and there is an established pattern of thinking.

• Security teams can most easily adopt new tools that don’t impact the experience of any other team. Think of any detection and response tool: they are evaluated, purchased, and used by the security team itself, with no impact on the rest of the company. Preventative approaches by their definition are designed to prevent something from happening, and this prevention can get in the way of other people in the company. Security leaders need to carefully weigh where and when to implement preventive controls.

Philosophically, preventative controls are the way to solve problems at their core. In reality though, it doesn’t appear that the market oftenrewards being proactive. We in security are used to old patterns and we have grown accustomed to applying them to every problem, new or old. It doesn’t appear that the market is ready to change its thinking en masse. But, this assumption is ready to be challenged, and some of these challengers will be successful.

Time to value vs. contract length

Another important dimension is how companies manage procurement and contracts and the impact contract length has on expectations surrounding time to value.

Many high-performing security teams have multi-year contracts with a core set of vendors they have close partnerships with. On top of that, they may have a variety of one-year deals in areas they are testing out. Security leaders know they are likely going to replace a lot of the point solutions and low-confidence additions, as well as tools they bought to temporarily close gaps in the offerings from their large partners.

When a CISO is signing a deal with a small startup, there is rarely any initial intent of a long-term relationship. The vendor understands that they probably won’t be able to keep the customer unless they continue to innovate and improve the offering. The buyerunderstands the risks associated with dealing with a startup (the company may pivot, get acquired, or go out of business), so it’s hard to justify investing a lot of resources into this partnership. It’s not that they are not open to establishing a long-term partnership, it’s that there are so many tools and vendors that they simply can’t do it with everyone.

Shorter contract length is directly tied to the expectations customers have about time to value. Today, people think about it differently than before: if they are only signing a year-long deal, they better have the tool up and running quickly. When contracts are three or more years, buyers may be comfortable waiting longer. This is the case with large scale implementations such as Sailpoint or Zscaler. However, in case with one-year contracts, time to value has to be instant.

Two other challenges startup founders have to be aware of are declining average contract value (ACV) and expectations of quick trials. As Venture in Security explained before, “Frequently the desire of startups to get new customers at any cost and the need of CISOs to spend the least money possible on new tools meet. When it happens, founders get to claim new logos, and security leaders get small sets of capabilities with great support. The reality is that a lot of these contracts have incredibly low average contract value (ACV). Many new security vendors aren’t fighting for hundreds of thousands and multi-million-dollar deals; they are lucky if they can get $20,000-$50,000 per year for a small feature they are selling. In most cases, that’s also the most they can charge as no buyer is going to pay hundreds of thousands of dollars for a small feature that is added as a net new tool on top of the existing security stack.”

When it comes to procurement, people are looking for easier ways to try products. This isn’t specific to security - the same is true in enterprise software overall. Easier trials aren’t about self-serve or product-led growth: it’s about enabling buyers to make quick high-confidence decisions. In 2025, any startup that has a 6-month long rollout is almost inevitably going to fail. As products are becoming less differentiated, this means they are becoming easier to replace. And, as SaaS becomes easier to try out, that lowers the bar to try, but the bar for the actual procurement and operationalization remains high.

Regulatory compliance-driven vs. security-driven

There are many philosophical questions one could ask about the relationship between compliance and security. Does security lead to compliance? Does compliance lead to security? All these are good to ponder on but they are not relevant in this context. What matters is that 1) compliance is what drives many buying decisions in security, and 2) compliance is an argument security leaders often use to make a business case for buying security.

Around 15 years ago, many organizations had to adhere to PCI DSS (Payment Card Industry Data Security Standard), and when web application firewalls (WAFs) were incorporated as a requirement, vendors saw a significant boost in sales. Companies facing strict regulatory requirements had little choice but to invest in solutions that helped them get and stay compliant. In contrast, security ideas or products that aren't directly linked to a compliance mandate often struggle to gain similar traction. Without an external regulatory push, these products must compete on other factors such as technical superiority, cost-effectiveness, or demonstrated return on investment, and even then the majority of the companies may not care. A great example of this phenomenon are deception technology platforms. Designed to deploy decoys and traps to lure and identify attackers, these solutions offer a different approach to security. Tools like Thinkst Canary can substantially shorten mean time to detect (MTTD). However, because no major regulatory standard mandates deception, most organizations hesitate to invest in them, especially when budgets are tied to compliance-driven spending.

As Venture in Security explained before,

• For companies in regulated industries, compliance is an enabler for their peaceful existence.

• For technology vendors, compliance is a critical sales enablement instrument.

• For everyone else, security is simply a tool to reduce potential losses.

Sadly, people are bad at estimating risks and probabilities so compliance which establishes the bar companies need to meet is indeed a powerful argument for justifying security investment.

Security founders should be cautious going after problems that don’t have direct connection to compliance requirements. At the same time, successful products don’t have to themselves check a compliance box. Another way of achieving a similar outcome is having compliance relevance. Chainguard, for example, is a better way to secure containers, and it ties into compliance, but it in itself isn’t what the security team would think of to check the compliance box. A good security solution that solves a real security problem buyers care about should be possible to tie into compliance requirements.

Selling to security vs. multiple teams

As far as the buying journey is concerned, there are two broad types of security products: those that are sold directly to security teams (often IT-focused and with security as the primary or sole decision maker), and those that are sold to several teams (often cloud-focused and requiring input and approval from multiple teams).

Security for IT is always easier: the budgets are larger, and the implementation is much simpler. Since the head of IT and head of security are either the same person, or report into the same person (usually CIO), there are few conflicts and priority misalignments that could impact product adoption. CIOs and CISOs tend to be on the same page about what matters, which makes IT security a great area to build a startup. As a rule, a tool where security is a buyer and a sole user is the easiest to get adopted. An exception would be solutions like SASE which impact the experience of everyone at the company - the bar for getting these adopted is very high (that is always the case with proxies, VPNs, and other solutions that are “in line”).

This story is very different when it comes to the cloud. Cloud is often owned by engineers, and security for engineering requires a strong ability to influence engineering leaders who have different priorities, different key performance indicators (KPIs) and who report into different leaders (usually CTOs). Time to value works against the cloud overlap functions. The moment you have multiple departments involved, time to value becomes longer, buying cycles double or triple, and most initiatives never get enough buy-in. To make matters worse, unlike IT which is typically seen as a cost center (to a lesser degree than security but still a cost center), engineering is the value center and as such it has the power to say no. Anything that negatively impacts the experience of engineers or their productivity, can and generally will get blocked. Security leaders are generally hesitant to do anything that can annoy developers (and the bar for what constitutes an annoyance is at all times low). As a rule, any time security founders try selling into the security team where the security team isn’t the end user it always fails. And, any time a security tool gets in a way of software developers and their experience, the startup will struggle to overcome adoption hurdles.

When selling cloud and application security tools, founders have to be mindful of everyone’s needs and masterfully navigate organizational complexity while recognizing who is giving approval, who is an operator, who will rebel when something goes wrong.

Closing

There are different ways to look at security. As security practitioners, we need to ask ourselves a question - “What are the most effective ways to secure our organizations?”. Answers to this question often give us a good starting point for defining what new ideas need to exist in the market. As security founders, we need to ask ourselves a different question - “What does the market reward?”. The answer to this question will inform the decisions founders will need to make to succeed with their ventures.

Reconciling the answers to these two questions is hard. It’s much easier to sell more alerting but what the practice of security really needs is more prevention. It’s much easier to sell to a single team, but a lot of the complex problems can only be solved when multiple stakeholders are brought together around the same table. It’s much more intuitive to build a product a customer can get started with in three minutes, but a lot of the depth will get missed unless they spend time and go through the pain of deploying an agent or customizing security policies. Examples are plenty, and it’s hard not to see that the patterns that make startups successful often perpetuate the same issues the industry has been struggling with for decades.

This isn’t good or bad, this is just how it is. It’s too easy to get carried away with our ideas of how security should be done. But, as some smart people say, “In theory there is no difference between theory and practice but in practice there is”. It’s important that once in a while, founders get enough bravery to challenge the way things have always been done. This is how we innovate, this is how we build the future of security, and this is how we will be able to solve a lot of the gnarly problems we weren’t able to solve before.

---

If you like my blog, please subscribe & share it with your friends. I do this in my free time, so seeing the readership grow helps me to stay motivated and write more. I don’t send anything except my writing and don’t sell your data to anyone as I have better stuff to do.

If you are a builder - current or aspiring startup founder, security practitioner, marketing or sales leader, product manager, investor, software developer, industry analyst, or someone else who is building the future of cybersecurity, check out my best selling book, Cyber for Builders.

If your company is interested in sponsoring Venture in Security, check out Sponsorships. Thank you!