开发网络安全产品很难。
很多公司都想先试后买，但把公司的敏感数据交给一家小型初创公司，很多人都不愿意冒这个险。此外，网络安全产品的销售通常是倒过来的（即先大到小），企业才是最大的买家，因此，对于在当今 SaaS 领域非常普遍的传统“圈地扩张”模式而言，直接向从业人员销售就变得更加困难。
这意味着许多企业不愿意为初创企业承担风险，因为它们达不到预期的安全标准，而初创企业在没有大量资金支持的情况下也很难达到这一标准。
这就给网络安全建设者留下了三个选择：
试图通过获得大量风险投资资金来实现快速发展，这对于一家没有产品市场契合度的初创公司来说是一种冒险的尝试。
尝试销售服务器托管产品；这通常可以奏效，但许多公司不喜欢自己管理软件。大多数公司宁愿使用外包的 SaaS 版本。
建立一个开源产品，让从业者试用，并尝试将其过渡升级为付费版本。
在这篇博客中，我们将深入探讨最后一种选择，展示人们如何实现过渡的典型案例，挖掘一些现实生活中的案例研究，最后谈谈我们是否会看到更多这样的选择。
构建开放源代码
构建开放源代码并不像做一个副业项目，利用个人时间打磨几个小时那么简单。当然，这仍然是许多人的选择，但还有一种选择却鲜有人问津。
人们在日常工作中构建开源工具，然后将其剥离出来成立独立公司的例子比比皆是。特别是在安全领域，大企业（尤其是在 FAANG 领域）往往拥有足够的人员和资源来构建最前沿的定制工具。现在，对于这些公司来说，他们的主要市场并不是销售安全工具，因此他们通常很乐意允许这些工具开源。
当然，你可能会问，如果你把可能相当于公司知识产权的东西拿去建立公司，这不会引起诉讼问题吗？从历史上看，答案是否定的。大多数这些大公司都不希望在建立较小的安全点解决方案时陷入困境。这就意味着，如果有几个工程师辞职，并制作了开源工具的 SaaS 版本，该公司就可能成为早期采用者，每年为软件支付 10 万，而不是花费数百万来支付工程师的薪水。这往往会成为一个双赢的局面，原公司会在未来几年锁定较低的价格。
这意味着，你可以一边做着日常工作，一边建立未来的公司，但诚然，你需要在正确的地方，在正确的公司做正确的事情，这样才能成功。因此，这仍然是一个小众的方案。当然，最常见的途径是兼职工作法，即利用自己的时间创建一些东西，在家里加班加点，通常相当于第二份工作。
销售开放源代码
开发开放源码产品很难，但将其货币化更具挑战性。罗斯曾详细谈及如何让风险投资进入开放源码软件，但自他撰写那篇文章以来，情况发生了很大变化，如今的例子更是五花八门。是的，你可以做千篇一律的事情，即出售部署支持和咨询费，但这实际上只是冰山一角。
销售集中化
如今，一个更常见的例子是销售安全的想法。构建一个缺乏集中化功能的开源工具，然后再销售增加了集中化功能的企业版本。下面案例中的 Workbrew 就是一个很好的例子。对于全球数百万 MacOS 用户来说，Homebrew 非常有用，但对于现代企业环境来说，Homebrew 并不理想。让安装任何软件包都变得简单，会导致漏洞、不支持的软件包、潜在的恶意软件以及 xz utils 后门等问题变得更加普遍。在此基础上，你可以增加集中化功能，提前审核软件包，这意味着你可以为相对不安全的设计增加安全性。这可以包括现代软件中的所有典型功能，如角色、群组、管理员控制等。
销售 SaaS
开源软件固然好，但有时也意味着需要自己部署和管理基础架构。作为一个自认懒惰的工程师，我不想管理一个我不需要的 0 级服务，我宁愿把时间花在有趣的工作上，而不是更新一些自托管基础设施中的软件包。货币化的一个可靠例子就是销售你构建的开源软件的 SaaS 版本。这样，你就不需要部署它、管理它，或者处理恼人的软件包更新。由于基础架构和安全工具的相互关联性，这种情况在基础架构和安全工具中最为常见。
咨询费和/或支助费
这是开源货币化在过去最常见的途径。你可以成立一家咨询公司，收取支持费用，帮助管理和维护软件。你可以代表客户托管软件，尤其是在客户本身不具备技术能力的情况下。或者，你也可以请一些对工具非常了解的专家，让公司愿意为客户的功能或专家更快的支持付费。当人们在意识形态上倾向于构建永远开源的工具时，这往往是符合他们偏好的途径。在安全领域之外的开源世界中，这种情况也非常普遍，Canonical/Ubuntu 就是一个大多数人都知道的例子。
为什么要构建开源？
问题是，为什么首先要建立开放源代码？为什么不在早期就制作一个Pitch deck，并尽可能多地获得风险投资的资金，以迅速扩大规模？
原因并不单一，很大程度上取决于创始团队及其构建产品的原因。开放源码往往会吸引那些想打造自己想要使用的产品的从业者。而在发明者和顾问的压力下，这一点就很难做到。下面我们将深入探讨走这条路的一些利弊：
优点
产品与市场的契合度--你可能首先选择开源的唯一也是最大的原因就是要确定市场是否需要你这样的产品。它允许你自由地构建产品，让人们对其进行测试，并在没有任何购买、采购或签订协议压力的情况下获得反馈。这种循环的好处是无法低估的。
以产品为主导的增长--开放源码深受从业人员的喜爱，向工程师而不是 CISO 销售会更有优势，尤其是当你试图将目标锁定在更多以从业人员为主导的公司时。
延迟风险投资融资--你仍然可以接受风险投资融资，并打造出优秀的产品，但你可以在找到产品市场契合点、客户和他们所期望的所有正常情况后再进行融资。这样，你就有可能在较少稀释的情况下获得资金，因为你降低了风险投资公司认为的风险，尤其是在你已经拥有客户的情况下。
兼职人员 - 您仍然可以在从事全职工作的同时构建开源产品。另外，如前所述，你可能会很幸运地将构建开源工具作为日常工作。
社区建设--建设开放源代码既能围绕你的产品建立一个社区，又能加快开发速度。如果你能说服人们开始为你的 repo 做出贡献，你就有可能拥有免费的开发人员为你工作。
缺点
领域限制--如果你打算靠自己构建的工具谋生，那么你的选择就会受到限制。有大量为从业人员打造的令人惊叹的安全工具，但很难实现货币化。这对社区来说是件好事，但可能不适合创建者或长期产品改进。例如，任何类型的分析师辅助工具都可能比基础架构工具更具货币化挑战性，因为它们是在您的桌面上本地运行的。
竞争--对于开放源代码来说，没有什么能阻止风险投资的初创公司以更多的资源进入市场并击败你，尤其是如果你计划在未来推出 SaaS 版本的话。你想变得流行，但又不想太流行，因此这可能会限制你进入更小众的领域。
案例研究
Homebrew > Workbrew
Workbrew 是开源企业化的完美范例。他们出售的是额外的集中化和控制。最初的 Homebrew 很不错，但在企业设置方面往往会出现问题。在管理方面，很难将其部署到每个人，并确保所有工具都能在第一天使用。它还忽略了许多安全控制，例如确保人们使用合法的软件包、更新这些软件包，以及可能滚动你自己的允许列表。
此外，自制软件本身在过去也曾多次成为恶意广告活动的目标，因此能够将其部署给员工而不是让他们意外下载恶意版本，无疑是锦上添花。
Osquery > Fleet + Kolide
Osquery 是一款开源端点遥测工具，由 Facebook 的安全团队发起。随着时间的推移，该工具的贡献者越来越多，但 Meta 的许多创始团队后来都创建了自己的初创公司，以某种方式扩展或使用 Osquery。最大的两家公司可能是 Fleet 和 Kolide。这两家初创公司都表明，你可以通过不同的方式利用相同的开源基础，而这只是其中最重要的两家，还有其他咨询公司和初创公司也利用 osquery 作为创建自己工具的基础。
Fleet
最初，Fleet 协助部署内部部署的 Osquery，但最终将其扩展为 IaC MDM。这项工作的许多内容已过渡到 SaaS 产品，该产品本质上是 osquery++，通过集中化获得了更多特性和功能。这样做的好处是，你不必进行自我管理，如果你想自己进行部署，osquery 是众所周知的相当繁重的工作。
Kolide
Kolide 的做法略有不同，它利用 osquery 进行设备合规性和零信任遥测检查。这样，你就可以获得设备加密状态、操作系统版本等信息，除非员工符合特定条件，否则就可以访问企业应用程序。Kolide 于 2024 年初被 1Password 收购，因此它是我们可以指出的为数不多的已经退出的例子之一，尽管有关退出的大部分细节并未公开。
Bloodhound > SpecterOps (Bloodhound Enterprise)
这是最传统的扫描器。Bloodhound 是一款开源扫描仪，用于查找 Active Directory 等工具中的错误配置。虽然该工具在创建之初是开源的，但后来发展成免费的社区版和 SpecterOps 的企业版。企业团队仍在为开源版本做贡献，但也在 SaaS 企业版中加入了额外的功能，可以单独销售。此外，他们还可以让自己的顾问在与客户的合作中使用它，从而提供额外的价值。这只是 SpecterOps 业务的一部分，他们的核心业务仍是培训和咨询，但仍有助于公司的初步创建。
后起之秀
在这一领域有一大波新的初创公司，虽然我很想多谈谈它们，但这篇博客最终会变得太长。以下是我认为未来可能有潜力的几家公司。这些工具大多从开源工具发展而来，现在提供企业版本，与上述模式基本吻合。
Google Santa > NorthPoleSec
Step-CA > SmallStep
Ngrok OSS > Ngrok Enterprise
以开源方式构建产品值得吗？
从开源贡献起步的公司取得了一些轻微的成功，但它们大多仍是小规模的利基企业。如今，在安全领域，还没有真正的现代开源公司变成像 Crowdstrike、ZScaler 或 Wiz 这样的大型平台公司的例子。过去倒是有几个例子，Tenable 诞生于 Nessus，SourceFire 则利用了 Snort。但在这些例子中，创始人并不是为了销售而开始构建开放源码软件，而是利用开放源码软件并在其基础上进行构建。
诞生于开放源码软件的公司专注于构建非常好的单点解决方案，这是有道理的。通常情况下，有一种特殊类型的人会把时间花在为开源软件做贡献上，即使他们是在一家大公司拿工资做这件事。这类人往往关心如何为生态系统做出贡献，如何打造人们喜爱的产品。从这些开源工具中衍生出来的公司往往会继续秉承这种精神，这也许并不奇怪。
我们是否会看到更多此类公司，还有待观察。从好的方面看，在AI Copilot的帮助下，软件的构建从未如此简单，许多大型 SaaS 公司都有构建内部安全工具的团队，无论是 Brex 的 Substation 还是谷歌的 Santa。不利的一面是，科技公司正在削减成本，开源贡献往往最先消失。我们也有一些公司关闭源代码的例子，如 Panther 社区版的日落。
我相信，开源软件会越来越多。无论你是想走 "引导 "路线，还是想获得风险投资，没有比创建开源软件并在实际应用中得到真正验证的更好方法了。
原文链接：
https://ventureinsecurity.net/p/will-the-next-wave-of-cybersecurity
声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
