Crypto-Agility? 你认真的吗？
在最新的 Gartner Application Security Hype Cycle中，我很惊讶地看到漏洞的“可达性分析”出现在头部前列。并且，它霸榜的时间比其他很多技术都要久；然而，我看到最新迭代的‘可达性’变得越来越好。
我们正面临着‘可达性’的巅峰时期 。我以前写过关于‘可达性’的文章--一次是关于 Endor（非赞助），还有一次是冷静地探讨过它的潜力以及优缺点。自那以后，运行时和静态的‘可达性’都得到了极大的改进，所以我又重新开始关注这个热点了，但有两个需要注意的地方：
漏洞可达性通常被视为一种减少误报的方法，但我认为它实际上是为了让我们更接近漏洞扫描后的最终目标--阻止潜在攻击。
修复漏洞一直是长期的难点，但漏洞‘可达性’在修复过程中始终是有大作用的。我以前把这看作是一个非此即彼的问题。现在我认为这是一个两者兼有的问题。
在我个人保护云本原生程序安全工作经历中，我从未在我的SaaS应用的上下文中看到过来自容器镜像的可利用CVE的证据。 尽管进行了成千上万次漏洞扫描，发现了数百万个漏洞，并且开发人员花费无数时间来修复这些漏洞。不幸的事实是，大量的误报对安全在组织中的合法性造成了实质性的伤害。从商业角度来看，我在漏洞扫描上花费了数十万美元，但收效甚微 - 与 CVE 检测相比，软件和云的发版可见度更大。
漏洞管理Hype Cycle在哪里？
老实说，很难量化由于漏洞扫描器检测到的天文数字般的误报所导致的时间浪费和开发人员关系破裂的情况。在本文中，我们将讨论存在的两种误报，以及为什么可达性是我们解决漏洞分类这一噩梦的最佳机会。
漏洞扫描的目标
目前，漏洞扫描已成为大多数组织的实际要求。以前，漏洞扫描的目标要简单得多：去修补可能被利用的软件。 例如，某个版本的Microsoft Word中的漏洞可能允许攻击者运行恶意宏。解决方案是什么？给Word版本打补丁。
幸运或不幸的是，现代软件和扫描器已经极大地改变了这些扫描结果的意义，尤其是在应用程序方面。在 "过去的好美好时光"，漏洞扫描通常只是查看Windows更新和常见软件如Adobe。现在，扫描器可以专业地剖析二进制文件和文件系统，寻找你系统中存在的可传递的易受攻击的依赖项。
现在，漏洞扫描器比以前会更深入地检查构成每个软件的所有组件，这对安全工作大有裨益。毫无疑问，这无疑对可见性和责任追究是好事，但反过来却增加了安全团队根本无法跟上修复的原始漏洞数量。
在关于误报的讨论中，我发现服务提供方和用户双方都存在很多困惑。之所以困惑，是因为这些发现既是误报，又不是误报。是因为这些“有漏洞”的组件确实存在于机器上，并且在特定情况下才可能被利用。但是，我将这些无法被利用的漏洞称为误报，因为漏洞扫描的目的是检测可被利用的软件，如果某些软件无法被利用，那么它就根本不存在漏洞。
如果某样东西不存在可利用性，它就不是真正的漏洞。
举个简单的例子，上个月的 regreSSHion 漏洞就是在服务器开放 22 端口的情况下被利用的。如果服务器没有开放 SSH 连接，它就不会受到攻击。如果 OpenSSH 库没有加载并接受网络流量，它也不会受到攻。需要明确的是：打补丁仍然是一个好习惯。因为服务器将来可能会被攻击。但冷酷的商业现实是：当你不会受攻击时，打补丁没有实际价值——在打补丁之前和之后，你的安全性是一样的。
作为一个安全专家，我很难接受这种现实，因为好的安全体系需要做到层层防御。如果有人将其公开联网怎么办？如果攻击者找到了进入内网系统的方法怎么办？但是，从业务的角度来看，如果我有 10 名开发人员去选择开发一项新功能或修复一个不可利用的漏洞，他们每次都会选择开发新功能。
传统上，合规性一直是迫使这些漏洞被打补丁的因素；然而，面对来自开源生态系统的大量漏洞，审计人员们越来越倾向于解释漏洞的可利用性。这在SBOM（软件物料清单）的VEX声明中最为明显，这些声明允许你解释为什么你不会受到某个漏洞发现的影响——这确实是可能挽救SBOM相关性的关键。
可达性如何提供帮助
我通常将解决漏洞问题的方案分为优先级排序和修补解决方案。一方面，修补方案通过提供修复问题的方法并为开发人员提供理解代码变更的工具，使修复变得更容易。另一方面优先级排序的真正目的是将漏洞扫描的目标重新聚焦于发现可利用的软件。我从事漏洞管理已经很长时间了，有时感觉目标只是为了合规，但实际上它在这些框架中存在的目的是为了阻止潜在的利用。
让漏洞扫描回归其目标：
寻找可利用的软件。
研判某个漏洞是否可被利用要比看上去复杂得多，特别是考虑到CVE数据本身的质量问题。许多供应商甚至创建了自己的专有数据库，以提高漏洞数据的质量。这也是为什么每个声称“我们做可达性分析！”的供应商实际上在做的事情略有不同。研判漏洞的可利用性需要大量的漏洞信息的上下文。
因此，‘可达性’的目标是确定某件漏洞实际上是否可被利用，这意味着任何形式的可达性分析都有其潜在的价值。
了解这些信息对我们很有帮助：
加载一个库
一个函数被调用
这个程序或服务互联网可访问
通过EPSS评估的利用可能性
该库处理的数据类型
是否存在可以缓解利用的控制措施
考虑到这些关于漏洞管理的因素，我开始认为可达性的目标不仅仅是减少误报，更在于识别真正的告警。如果漏洞管理的目的是阻止利用，我们需要识别出哪些是可被利用的。
结论和未来
我在另一个文章写到，静态可达性是一种很好的解决方案，因为它能最快地反馈给开发人员。然而，根据我们的定义，这种方法存在一个问题：如果可达性意味着确定你是否可被利用，以及识别真正的非误报，那么这只能在运行时完美实现。第二部分将详细比较运行时和静态可达性方法
静态可达性始终是理论上的，因此无论其多么先进，它都无法涵盖每种类型的漏洞，也无法确定某些代码是否真正执行。一个简单的例子：在我的测试库中有一个永远不会实际执行的勒索软件脚本。这个脚本只是用于观察工具在运行时如何上下文的理解文件。每个静态可达性工具都无法避免将这些结果视为真正的告警。在现实场景中，这些结果会让开发人员感到愤怒，静态可达性可以减少这种挫败感，但永远无法完全解决它。一个更常见的例子是测试文件或数据，或在运行的应用程序上下文中从未实际执行的函数，即“死代码”。
运行时可达性处理的是确定性的问题。在我亲自试用并亲眼看到它能实现的去优先级功能之前，我对它的前景并不那么兴奋。我很高兴能在接下来的两篇文章中深入探讨这一点。第二部分将深入比较静态可达性和运行时可达性——两者都有非常真实的优缺点，这也是为什么在这两个类别中都有很好的解决方案存在。第三部分将是我做过的最技术性的内容，深入剖析运行时可达性的各种类型，并评估它们实际在做什么。对此我非常期待！
原文链接：
https://pulse.latio.tech/p/reachability-matters-13
声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
