This week, Venture in Security is excited to feature a guest article from Kane Narraway. Kane is a Head of Enterprise Security at Canva, and an author of a great personal blog about IT Security.
Building a cybersecurity product is hard. Many companies would love to try before they buy, but trusting a small startup with sensitive company data is not a risk many are willing to take. Add to this, cybersecurity sales are often reversed, with enterprises being the biggest buyers, and so it's harder to sell directly to practitioners for the traditional land and expand model that is so common in the SaaS world today.
This means many enterprises are unwilling to take risks on startups because they don't meet the expected security bar, and it is tremendously difficult for startups to reach that bar without significant backing.
That leaves cybersecurity builders with three options:
Try to get massive amounts of VC funding to grow fast, which for an early-stage company without product market fit is a risky endeavor.
Try to sell a server-hosted product; this often can work, but many companies don't like managing software themselves. Most would rather have an outsourced SaaS version.
Build an open source product, let practitioners try it out, and try to transition that into a paid version.
In this blog, we'll dive into the final option, showing typical examples of how people make the transition, dig into some real-life case studies, and finally talk about if it's something we'll see more of.
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
If you are interested in building, growing, or investing in a security startup, check out “Cyber for Builders: The Essential Guide to Building a Cybersecurity Startup”. This book, recently recognized by SANS Cybersecurity Difference Makers Awards as “Book of the Year”, is the most comprehensive guide for security entrepreneurs and anyone looking for ways to help their cybersecurity startup, product, line of business, open source or side project, or a portfolio company succeed.
Building Open Source
Building open source isn't as cut and dry as doing a side project, grinding hours in your personal time. Yes, of course, this is still an option many take, but there's an alternative that is less talked about.
There are plenty of examples where people have built open source tooling in their day job and then spun it off into a separate company. Especially in the security world, big enterprises (especially in the FAANG domain) tend to have the people and resources to build custom tools on the cutting edge. Now, for these companies, their primary market is not selling security tooling, so often, they are happy to allow these tools to be open sourced.
Of course, you might ask, doesn't this cause litigation issues if you are taking what could amount to company intellectual property and building a company of it? Historically, the answer has been no. Most of these large companies don't want to get bogged down building smaller security point solutions. This means if a couple of engineers quit and make a SaaS version of the open source tool, the company might become an early adopter, paying 100k a year for the software rather than spending millions on engineer salaries. It often becomes a win-win situation, with the origin company locking in lower prices for years to come.
This means you can hold down a day job and potentially build a future company while you're doing it, but admittedly, you need to be in the right place, doing the right things at the right company for this to work out. So, it does remain a niche scenario. The most common path, of course, is the side gig approach, building something in your own time, grinding hours at home, and working what usually amounts to a second job.
Selling Open Source
Building an open source product is tough, but monetizing it is even more challenging. Ross has talked at length about getting VC investment into OSS, but lots has changed since he wrote that article, and there are even more varied examples today. Yes, you can do the stereotypical thing, which is selling support and consultancy fees for deployment, but that's really just the tip of the iceberg.
Selling Centralisation
One of the more common examples today is the idea of selling security. Build an open source tool that lacks centralization, then sell an enterprise version that adds it. Workbrew, in our case study below, is a perfect example of this. Homebrew is extremely useful to millions of MacOS users around the world but Homebrew is really not ideal for a modern enterprise environment. Making it easy to install any package leads to vulnerabilities, unsupported packages, potential malware and issues like xz utils backdoor becoming more distributed. Monetizing the fact you can add centralization to this, vetting packages in advance means you can essentially add security to a relatively insecure design. This can include all the typical things you'd expect in modern-day software, like roles, groups, admin controls, and more.
Selling SaaS
Open source software is great, but sometimes this means doing your own deployment and managing the infrastructure. As a self-admitted lazy engineer, I don't want to manage a Tier 0 service that I don't need to, I'd rather spend my time doing interesting work than updating packages in some self-hosted infrastructure. A solid example of monetization is selling a SaaS version of whatever open source software you built. This way, you don't need to deploy it, manage it, or deal with annoying package updates. This tends to be most common in infrastructure and security tooling due to the interconnected nature of it.
Consultancy and/or support fees
This is the most common path open source monetization has taken in the past. You can build a consultancy company and charge support fees to help manage and maintain the software. You might host it on a customer's behalf, especially if they don't have the technical ability to do so themselves. Alternatively, you might have experts who understand the tool so well that companies are willing to pay for customer features or faster support from experts. When people are ideologically set to build open source forever tooling, this tends to be the path that suits their preferences. Again this is super common in the open source world outside of security, with Canonical/Ubuntu being an example that most people would know.
Why Build Open Source?
The question is, why build open source in the first place? Why not build a pitch deck and take as much VC money as possible early on to scale quickly?
There's no single reason, and much of it depends on the founding team and why they are building the product. Open source tends to attract practitioners who want to build a product they want to use. Something that's harder to do with the pressure of inventors and advisors. We'll dive into some pros and cons of taking this path below:
Pros
Product Market Fit - The single and absolute biggest reason you might go open source first is to identify if the market has a need for a product like yours. It allows you the freedom to build a product, have people test it out, and obtain feedback without any pressure about purchases, procurement, or signing deals. The benefits of that cycle cannot be understated.
Product Led Growth - Open source is much loved by practitioners, and selling to engineers, rather than CISOs, can be more advantageous, especially if you are trying to target more practitioner led companies.
Delayed VC Funding - You can still take VC funding and build a great product, but you can do it after you've found product market fit, customers, and all the normal things they expect. With this, you can likely get funded with less dilution, as you're reducing perceived risk to the VC, especially if you already have customers.
Part Timers - You can still build an open source product while working a full-time job. Plus, as mentioned earlier, you might be lucky enough to be building open source tooling as your day job.
Community Building - Building open source both builds a community around your product and can speed up development. If you can convince people to start contributing to your repo, you can potentially have free developers working for you.
Cons
Domain Limitations - If you plan to make a living out of what you are building, you are limited in your options. There are tons of amazing security tools built for practitioners, which would be hard to monetize. This is great for the community, but may not be suitable for the creators or long-term product improvements. For example, any kind of analyst helper tools are likely more challenging to monetize than infrastructure tools as they run locally on your desktop.
Competition - With open source, there's nothing stopping a VC-funded startup from coming in with significantly more resources and beating you to the market, especially if you plan to make a SaaS version in the future. You want to become popular, but not too popular, so this may limit you to nicher domains.
Case Studies
Homebrew > Workbrew
Workbrew is a perfect example of open source gone enterprise. The thing they sell is additional centralization and control. The original Homebrew is great but often has issues when it comes to enterprise settings. In terms of management, it's difficult to deploy it to everyone and ensure all the tooling is there on their first day. It also misses the mark on a lot of security controls, such as ensuring people are using legitimate packages, that those packages are updated, and potentially rolling your own allowlist.
Additionally, homebrew itself has been targeted by malvertising campaigns multiple times in the past, so having the ability to deploy this to your staff rather than have them accidentally down a malicious version is an icing on the cake.
Osquery > Fleet + Kolide
Osquery was an open source endpoint telemetry tool started by the security team at Facebook. This expanded out to include a bunch more contributors over time, but many of the founding team at Meta went on to create their own startups, which extended or used osquery in some way. The biggest two are probably Fleet and Kolide. Both of these startups showed there are different ways you can leverage the same open source base, and these are just the most significant two, with additional consulting firms and startups also leveraging osquery as a baseline for creating their own tools.
Fleet
Initially, Fleet started out helping deploy on-prem Osquery but eventually spun out to extend it, making a IaC MDM. A lot of this work has transitioned into a SaaS product that is essentially osquery++ with additional features and functionality gained by centralization. The benefit here is you don't have to self-manage, and osquery was known for being quite a heavy lift if you wanted to do your own deployment.
Kolide
Kolide took a slightly different twist, leveraging osquery to do device compliance and zero trust telemetry checks. This way, you could get information such as device encryption status, OS version, and more, gating access to corporate apps unless your employees met specific criteria. Kolide was acquired by 1Password in early 2024, so it is one of the few examples we can point to that already had an exit, although most of the details around the exit are not publicised.
Bloodhound > SpecterOps (Bloodhound Enterprise)
This is the most traditional of the lot. Bloodhound is an open source scanner that looks for misconfigurations in tools like Active Directory. While the tool was open source at the time of its creation, it diverged into a free community edition and an enterprise offering by SpecterOps. The enterprise team still contributes back to the open source version but also builds additional features into the SaaS enterprise version that they can sell separately. Plus, they can have their consultants use it in engagements with customers, providing additional value. This is only a part of SpecterOps business, with the core of what they do still being training and consulting but still helping with the initial creation of the company.
Up and Comers
There's a whole wave of new startups in this realm and while I would love to talk about them more, this blog would end up being entirely too long. Here's a few I think might have potential for the future. Most of these tools evolved from open source tools and now offer enterprise versions, fitting much of the models above.
Is building products as open source worth it?
There's been some mild success from companies starting out their journey from open source contributions, but they mostly remain small, niche players. There are no real modern examples today in the security space of open source turning into huge platform players like Crowdstrike, ZScaler, or Wiz. There's a few from the past, with Tenable being born from Nessus and SourceFire leveraging Snort. In these examples however the founders didn’t start building OSS to sell, they leveraged OSS and built on top of it.
OSS born companies focus on building point solutions really well, which makes sense. Often there is a specific type of person who spends their time contributing to open source software, even if they are getting paid to do it at a larger company. This tends to be the kind of people who care about contributing to the ecosystem and building products people love. Perhaps it's no surprise the companies that spin out of these open source tools tend to continue living that ethos.
Whether we'll see more of these types of companies remains to be seen. On the plus side, building software has never been easier with AI co-pilot’s help, and many big SaaS companies have teams who build internal security tooling whether it's Substation at Brex, or Santa at Google. On the downside, tech companies are cutting costs, and open source contributions are often the first to go. We’ve also had some examples of companies going closed source such as Panther sunsetting its community edition.
I believe open source software is a path we'll see more and more. Whether you want to go the bootstrap route or try to get venture capital, there's no better way to get actual validation of an idea than to build something open source that gets real usage in the wild.
This is a guest article from Kane Narraway. Kane is a Head of Enterprise Security at Canva, and an author of a great personal blog about IT Security. Follow Kane for more insights about IT Security.
This was a great read. OSS is definitely here to stay
Great read. Thanks