仅3%的开源软件漏洞真的可攻击

软件供应链安全风险高企的时代，漏洞管理工作量不断攀升，但6月25日发布的一项研究表明，攻击者可以实际利用的漏洞仅占供应链相关漏洞总数的大约3%。数据显示，如果应用安全（appsec）专业人员和开发人员能够专注修复和缓解真正可攻击的漏洞，他们就可以大大减轻其团队所承受的工作压力。

ShiftLeft最近发布的《2022年应用安全进展报告》表明，只要专注“可攻击”漏洞，应用安全和开发团队就能够更有效地筛选漏洞。报告中的数据显示，开发人员检查具有严重漏洞的在用软件包时，一旦考虑到可攻击性，就会发现库升级工单误报减少了97%。

如果真是这样，那对很多人来说，真是可喜可贺的解脱了。漏洞管理本就已经够难了，再加上第三方漏洞引入的复杂性，尤其是这些漏洞动辄波及大量软件的巨大影响，想要应付如此沉重的工作量，只能诉诸于进行有效的优先级划分了。在给定时间内，安全人员和开发人员就是只能处理这么多应用里的这么点漏洞。他们需要确保自己通过补偿控制措施修复或缓解的漏洞是真正重要的那些。

就安全漏洞而言，“可攻击性”到底意味着什么？

ShiftLeft首席执行官Manish Gupta表示，想要确定什么是可攻击的，不能只关注是否存在具有已知漏洞的开源依赖项，还得检查这些依赖项的实际使用方式。

“很多工具都可以轻松找出并报告这些漏洞。但这些漏洞报告里存在大量噪音。”Gupta称，“例如，这些工具不考虑应用程序是怎么使用依赖项的；甚至不考虑应用程序是否使用了依赖项。”

分析可攻击性还涉及评估其他因素，例如应用程序是否加载了包含CVE的包、是否使用了这些包，这些包是否位于攻击者控制的路径下、是否可以通过数据流访问。基本上，这意味着对开源漏洞采取简化的威胁建模方法，好大幅减少“消防演练”。

首席信息安全官（CISO）早已习惯这种演练。像Log4Shell或Spring4Shell这样的重大供应链漏洞，每次在业内传开，然后登上媒体头条，CISO手下的团队就得夜以继日地找出这些漏洞对自身应用程序组合有何影响，然后花费更长时间去应用修复和缓解措施，从而最大程度地减小风险敞口。

现在，新出炉的报告指出，96%的Log4J依赖项都是不可攻击的。

软件依赖项引人关注

现代开发栈中，无论是直接依赖还是通过第三方的依赖，对开源软件依赖的仰仗都在不断加深。

“只要使用了大量依赖项，主流应用程序往往每个月都会新增几个CVE。考虑到企业所用应用程序的数量，可以想见，紧跟所有升级真是一点都不容易。”

虽然更新一个软件包可能还算简单，但围绕这一个更改的相关开发工作往往就累死人了。通常，单个软件库升级会引出一系列新增测试工作，不仅仅是出于安全目的，也为了保证功能和质量，而且，升级还可能需要重构代码。

“重视产品质量的企业不会在未经全面测试之前就发售产品。此外，软件库升级也并不总是安全可靠；不能保证新版本开源库完全向后兼容。因此，团队有时候还需要在升级库之前修改其应用程序的运行机制。”

可攻击性确定是否可行？

在OWASP创始人兼应用安全长期倡导者Mark Curphey看来，早已有人开始寻求这样的优先级排序模型了。但是，他表示，在当今应用程序环境下，选择分析维度以确定有风险或可攻击依赖项，可能比ShiftLeft所提出的要复杂得多。

“可以说，开源软件库中绝大多数脆弱方法根本无法访问，因此无法利用，但我们现在所处的环境里，开源库就像各种精品小店，为开发人员提供各种趁手的好东西。”Curphey向安全媒体透露道，“作为一个行业，通过Log4J事件，我们最近认识到，即使漏洞类似于几乎没人真正在用的JNDI接口，利用途径也仍然存在，所以我们都必须直面这个漏洞。”

目前，Curphey正在为自己的应用安全初创公司Crash Override进行聆听之旅，了解各位CSO当下最大的应用安全问题，而几乎所有受访CSO都认为，漏洞优先级排序是他们的首要问题。Curphey觉得，或许这就是应用安全需要解决的下一个大问题。

“因此，报告的基本前提完全站得住脚。不过，我们也从访谈中了解到，这个问题非常难以回答，而且比回答‘我是否在用特定的代码’更加复杂。”Curphey表示，“这都是些业务关键性一类的事情，要说清楚系统有多少用户、流过多少资金、公共配置文件如何、处理哪类数据、物理位置在哪儿、适用哪些法律等等。同时还是技术上的事情，比如是如何连接其他系统的，设置了哪些控制、监测和警报措施等等。”

Sonatype产品创新副总裁Stephen Magill表示，使用“可攻击性”或“可达性”作为优先级筛选条件还存在另一个问题：了解底层技术数据，从而确定攻击者的可达范围。

“如果底层漏洞数据完善，可攻击性和‘可达性’或许是确定漏洞优先级的有用方法。但将可攻击性或可达性作为一种补偿手段去堵不良漏洞数据的缺，那就没什么帮助了。”Magill说道，“我们太常看到的行业做法是：使用不准确的依赖识别方法，结合有关脆弱依赖版本的噪声数据，然后采用基于可达性的优先级排序来筛选这长长的漏洞列表，最后得到可管理的结果。”

换句话说，可攻击性优先级排序的效果取决于馈送的漏洞数据质量，因此，安全团队需要真正深入了解漏洞数据的来源。

“漏洞数据是只从公开信息源获取的，还是专职安全团队深入研究的结果？另外，调查下依赖项都是怎么追踪的。”Magill表示，“这些依赖项只是清单文件中声明的，还是说所用工具支持对二进制组件、归档、JAR等的分析？这些问题可以帮助你确定排序结果的质量。正如他们所说的，‘垃圾进，垃圾出’。”

最后，Magill表示，安全主管需谨记，除了开源项目中偶然发现的那种常见漏洞，还有很多威胁存在于软件供应链中。

“我们的软件供应链所面临的最大威胁，是针对开源软件的恶意攻击。这是我们应该关注的一个大问题，而且这个问题与可攻击性毫无关联。”

《2022年应用安全进展报告》地址：

https://go.shiftleft.io/appsec-shift-left-progress-report-2022