2021年底发生的Log4Shell重大系列漏洞风波，对于推动软件物料清单-SBOM的应用的紧迫性发挥了无可替代的警醒作用。对于软件供应链中的漏洞管理来说，通过SBOM并快速地获取其信息无疑成为重要的基础性工作。尽管SBOM无法解决所有的软件安全问题，但将形成基础的数据，奠定后续安全工具、实践和保证的构建基础。一种新的有助于软件漏洞管理的概念或工具正在浮现，VEX-漏洞利用交流，在美国NTIA及相关企业的努力下有望年内付诸实践应用。
SBOM提供了一种安全、被动的方式来了解哪些设备和系统存在风险。漏洞管理则是SBOM的最大驱动因素之一，正如Log4j 漏洞所显示的那样，软件透明度目前是一个巨大的盲点。许多资产所有者仍在为网络分段和其他基础控制而苦苦挣扎，而SBOM并未真正进入大多数运营商的管理计划。难怪美国总统在2021年5月份发布第14028号行政令，要求美国商务部在60天内协同美国国家通信和信息管理局 (NTIA) 发布软件物料清单 (SBOM) 的“最小元素”。
软件透明度是最终目标，SBOM是实现这一目标的基础工具，但最终SBOM是达到目的的一种手段。SBOM的另一个关键元素是VEX，它作为SBOM 的“辅助工件”，使其成为产品制造商和软件供应商发现其产品的第三方依赖项中的漏洞，并率先评估这些漏洞可利用性的理想选择。VEX（漏洞利用交流）概念在SBOM和漏洞管理领域中将发挥至关重要的作用。
VEX是什么？
VEX代表“漏洞利用交流”。VEX概念和格式是美国国家电信和信息管理局 (NTIA) 软件组件透明度多利益相关方流程的一部分而开发的。虽然开发VEX概念是为了满足有关使用软件物料清单 (SBOM) 的特殊需求，但VEX并不限于与SBOM一起使用，也不一定预期包含在SBOM本身。
VEX的主要用例是向用户（例如，运营商、开发人员和服务提供商）提供有关产品是否受到包含组件中的特定漏洞影响以及如果受到影响，是否有建议采取补救措施的额外信息。在许多情况下，由于各种原因（例如，编译器未加载受影响的代码，或者软件中其他地方存在一些内联保护），上游组件中的漏洞在最终产品中不会被“利用”，等等。
为了减少用户调查不影响软件产品的不可利用漏洞所花费的精力，供应商可以发布VEX。VEX 是关于特定产品中漏洞状态的断言。状态可以是：
不受影响– 无需对此漏洞进行补救。
受影响– 建议采取措施来修复或解决此漏洞。
已修复的 – 表示这些产品版本包含针对漏洞的修复。
调查中——尚不清楚这些产品版本是否受到漏洞影响。更新将在以后的版本中提供。
虽然供应商可以通过电子邮件或任何其他方式通知用户不可利用的漏洞，但VEX是机器可读的。机器可读性可实现自动化并支持集成到更广泛的工具和流程中。用户可以将来自SBOM的组件数据与来自VEX的漏洞状态信息集成，以提供漏洞状态的最新视图。这可能会允许用户采取更有针对性的方法来查找和修复其软件中的漏洞。单个VEX 可以传达有关一个产品或多个产品中多个漏洞的信息。VEXes将由软件供应商发布，但也可以由第三方生成，用户将决定如何使用这些数据。
VEX已作为通用安全咨询框架 (CSAF) 中的配置文件实施。CSAF是由OASIS Open CSAF技术委员会开发的机器可读安全建议标准。正如 CSAF所定义的，VEX还可以提供丰富的信息，例如供应商、系统集成商和运营商可以提供的修复、变通方法、所需的重启/停机时间、漏洞评分和风险。VEX 也可以在其他标准或框架中实现。
VEX如何助力SBOM实施管理漏洞
软件生产者和消费者都注意到，并不是所有的漏洞都是相同的，在一个上下文环境中容易受到攻击的代码在另一个上下文中可能不会受到攻击。如果上游供应商确定来自漏洞的潜在风险不明显或不可利用，他们可能希望将该风险信息传递给下游的其他用户，以帮助他们做出基于风险的决策。
VEX是SBOM工件的机器可读的可选配套工件，它允许制造商将在SBOM中列出的某个软件组件中发现的漏洞的当前状态与之交流。这个功能将增加SBOM对终端消费者的价值:
消除大部分误报
解决由于实现或其他控制措施而漏洞无法利用的实例
传达制造商在缓解漏洞方面的进展情况
建议的解决方法
可用的补丁或缓解新版本
虽然SBOM对于给定的构建通常是静态的，但VEX在其内容的更改中可能是高度动态的，例如制造商关于漏洞的当前状态:
知晓漏洞
筛查漏洞
调查漏洞的根本原因
调查漏洞的解决方法
利用漏洞
与监管机构和客户交流漏洞细节
正是这种支持活动的差异可能会迫使VEX和SBOM成为两个单独的工件，但是在某些用例中，这两个工件可以表示为一个工件，例如当SBOM可从制造商服务器获得而不是驻留在设备中时。
VEX应用示例
假设某次系统安全评估发现了产品中的200个漏洞。在这些漏洞中，有些漏洞在国家漏洞数据库 (NVD) 中被标记为严重。资产所有者要求供应商给出解释和答案。
供应商的客户支持代表受到许多其他客户提出类似问题的轰炸，他们向每个受影响的客户发送电子邮件，解释说虽然漏洞理论上会影响组件，但它们的可利用性取决于开发团队编译它们的方式。该代表还可能解释说，测试和代码审查表明没有一个关键漏洞会影响产品，并且只有20个低风险漏洞实际上是可利用的。
资产所有者决定这批低风险漏洞不需要紧急修补，并将等待下一次维护关闭以更新软件。不幸的是，一个月后，在另一个子组件中发现了几个新的严重漏洞，资产所有者（以及所有其他客户）重复了这个循环。
这可以被认为是传达漏洞风险和管理这些漏洞的成功方式，尽管耗时且非永久性。它确实依赖于供应商及时提供准确的SBOM，并且每个资产所有者有效地将多个软件组件与报告的漏洞相关联，这两者都是艰巨的任务。然而，最大的问题是大量时间浪费在客户和供应商之间的来回沟通上，所有这些都需要手动阅读电子邮件和支持性PDF文档。显然，这种情况对任何一方都不理想。
解决方案是使产品供应商能够发现其产品的第三方依赖项中的漏洞，并抢先评估这些漏洞的可利用性。评估完成后，供应商可以将结果导出为标准化、机器可读的VEX文档，客户可以访问并轻松解释该文档。
这很重要，因为并非所有漏洞都需要采取行动。在许多情况下，依赖组件中可能存在漏洞，但对于特定产品，它要么已被供应商开发团队缓解，要么攻击者无法访问。这方面的一个例子是OpenSSL中著名的HeartBleed漏洞，它需要激活特定的产品功能才能在防火墙等产品中利用该漏洞。
回顾示例场景，可以探索VEX文档的可用性如何提供更好的解决方案。资产所有者获得了SBOM和漏洞评估，但这次也从他们的供应商那里获得了VEX文件。结合所有文档，他们使用其资产管理系统来处理VEX文档，以确定200个漏洞中的哪些漏洞实际上是可利用的。他们确定只有20个漏洞确实是可利用的，而且都是低危急程度。这是资产所有者实际上可以解决的一个数字：它是可操作的，而不是瘫痪的。此外，VEX文档可以包含针对可利用漏洞的补救措施，资产所有者可以快速查看降低风险的选项，而无需联系供应商。
专家预计，VEX概念“可能会在2022年迅速流行，因为它减少了供应商和最终用户的工作量”。供应商可以轻松地传达客户因漏洞而面临的风险（或不存在风险）。供应商可以单击一个按钮并为公司生产的所有产品的所有版本创建一个VEX文档，而不是生成一个长长的PDF列表1000多个产品及其潜在的漏洞暴露。这大大减少了在漏洞恐慌时安抚客户所需的努力。VEX基于JSON格式，机器可读且易于构建工具。事实上，已经有安全公司正在赞助开发一种开源VEX工具，希望在2022年6月之前看到该工具的应用。
声明：本文来自网空闲话，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
