开源安全工具与商业安全工具的对决

开发者不希望使用碎片化的工具，也不希望获得太多警报或仪表盘。相反，他们需要对安全工具的结果质量有极高的信任。

左移的趋势在过去十年中对推进许多工程学科方面做出了巨大贡献，在将行动向左移入生产方面，没有哪个学科取得的进步比安全学科更大。Snyk 是向左移动安全的首批和最大的支持者之一，它通过一种新颖的方法在开发人员的工作流程中打开拉取请求(PR)来缓解在开源包中发现的通用漏洞披露(CVE)，我们已经将这一理念发扬光大，并讨论了天生向左的安全。

自从首次推出了其用于开源的 SCA 扫描器（这是他们的知名产品）以来，Snyk 已经添加了相当多的工具到其套件中，以提供更全面的安全性。在这篇文章中，我们将看看从安全性的角度来看，这个行业如何发展，以及我们仍然需要在开发人员体验方面进行改进和提升的方向。

开发者真正需要什么

通过开放 PR 进行自动修复教会了这个行业很多关于安全体验应该是什么样子，以使开发人员真正采用它 — 我们也写过关于这种安全体验以及开发人员真正想要的内容。在我们期望开发人员接收安全警报并对其做出响应的方式上，作为一个行业，我们已经取得了进步。在了解开发人员需要的工具以便其有用性方面，我们已经走了很长的路。他们不想要分散的工具，太多的警报或仪表板，他们需要对其安全工具结果的质量有极大的信任，并且需要保持在不断的上下文和流程中以应对需要解决的任务。

多年来，开发者也在进化。今天几乎没有一个安全意识的工程师不知道，为了使他们的产品和平台安全，他们不仅需要第三方 OSS 包扫描器。他们现在知道他们需要扫描他们的代码，他们的 IaC 和云环境，他们的容器和 Kubernetes 集群，甚至可以深入到在运行时进行一些动态 Web 应用程序安全测试。所有这些，只是为了在向客户交付代码和产品时实现最基本的安全性。

然而，有趣的是，我们行业最大的问题之一仍然是碎片化。这是因为每一个单独的安全功能本身就是一个公司和领域专业知识。在所有这些领域同时出色非常困难，并且以无缝的开发者体验提供这些也非常困难。

这就是我们开始看到单一供应商安全平台的缺陷所在。来自当今行业最大供应商的安全套件似乎在一家店提供了这种端到端的能力套件，但它们真的堆叠起来了吗？

基准测试安全平台与开源替代方案

从零开始构建 Jit 时，我们明确这种整合方法确实是安全的正确方法，但执行最终决定了我们作为一个行业是否成功。在构建一个真正可行的安全编排平台时，我们有幸进行了大量研究——是的，研发中经常被忽略的那个关键部分——我们想探索商业工具与开源工具的世界，并了解为用户提供什么以提升我们作为一个行业的水平。

结果令人震惊。虽然我们发现具有传统核心产品的公司在与开源工具的基准测试中表现良好，但引人注目的数据显示，为提供更全面的端到端覆盖而添加到套件中的其他工具与最好的开源工具几乎没有堆叠(如果有的话)。

例如，Kubescape 和 KICS 等用于 Kubernetes 清单文件扫描的工具——Kubesape 与 KICS 并列第一，领先于市场上其他商业可用工具。 当添加由 Jit 团队用 AI 策划的专用规则来增强检测时(在封闭源商业产品中不可能实现)，这一点就更加明显了。

对于代码扫描，这也是正确的，即使是被推广为支持良好的语言，如 Python。开源 Semgrep 在广泛的编程语言中表现更好，尤其是在商业工具中支持较少的语言——尽管被广泛采用——如 Scala。

这只是加强了我们的工作假设，即开发者应该有选择堆栈中工具的自由，而不应该由与单一供应商的参与来决定。我们的安全性不能因我们选择购买的供应商而受到影响。

面向开发者的真正向左移动

当我们得出这个结论时，我们理解我们可以为用户(开发者)提供的最佳平台将具有这四项关键能力：

• 广泛的覆盖面；
• 单一平台中的编排、统一和可扩展性；
• 为开发者提供的与上下文相关的自动修复；
• 开发者体验——支持一切开发者体验！

当我们谈论覆盖面的广度时，很明显我们不能妥协或优先考虑堆栈的一部分而忽略另一部分。我们知道代码和开源包一样重要，就像所部署的软件的云配置一样重要。这只能通过启用开发者选择他们想要的任何工具来实现——开源或商业——并在开箱即用的基础上策划和扩展一组非常出色的开源控件。这把我们带到了下一个功能。

仅仅编排一组预定义的工具并就此打住是不够的。要真正提供开发者需要和预期的体验，有几个方面需要考虑。首先，您需要统一输出和模式——每个工具都有不同的报告方式和关于问题的警报方式，通常通过冗长的结果列表(需要过滤、优先级排序和后续分配)。接下来，您必须能够以无缝的方式支持不断添加新工具和覆盖范围，并且可以轻松地引入您自己的内部工具。

即使您提供一个真正简洁的 UI，其中所有数据都以人类可读的格式统一，并按优先级排序，但大多数开发者无论如何都不会以这种方式工作。他们希望关键警报在与上下文相关的情况下到达，以及在其他阻止和迫切的事件发生时——比如在 PR 被创建时。我们的优先修复思维方式是指向确切的问题代码行，并在 PR 内提供代码修复和修复指南，这样你就不必在其他 UI 中后续去寻找结果了。

在此基础上，已经在使警报更人性化(不再警报或仪表板疲劳!)，并使开发者只在需要或想要时使用 UI——当然不必登录到几个碎片化的 UI 来全面了解其安全状况。相反，开发者可以直接在 Slack、Github 或 JIRA 中接收警报，或者甚至发送任务到 JIRA 以后处理——所以安全可以与其现有的工具和工作流程集成，不需要他们离开上下文来解决安全问题。

瑞士军刀式安全

我们在安全行业已经走过了漫长的道路，左移安全是众所周知的，现在可以使用出色的工具来覆盖现代软件堆栈的许多层面。这使我们现在可以将安全能力提升到一个新的水平，并为安全世界解锁急需的开发者体验——安全体验。开发者是新的工具决策者，如果我们不优化系统中的人，我们将使我们的安全计划注定失败。通过提供类似于一段时间以来可用于 DevOps 和工程世界的工具体验和方法，我们将使安全能够以高度可扩展的工程团队的相同速度和速率移动。