软件保证和供应链风险管理中的度量挑战

自2009年以来，软件供应链风险呈指数级增长，当时Heartland支付系统漏洞的肇事者获得了1亿个借记卡和信用卡号码。随后在2020年和2021年发生的事件(如SolarWinds和Log4j)表明，第三方软件供应商的破坏规模可能是巨大的。2023年，MOVEit漏洞泄露了160万人的信息，给企业造成了超过99亿美元的损失。这种风险的一部分可以归因于软件重用，它使系统的部署速度更快，但也可能引入漏洞。SecurityScorecard最近的一份报告发现，在其抽样的23万个组织中，98%的组织在过去两年内有过第三方软件组件被攻破的情况。

度量软件保证的局限性直接影响了组织在整个生命周期中处理软件保证的能力。整个供应链的领导层继续在软件保证方面投资不足，特别是在生命周期的早期。因此，设计决策倾向于锁定弱点，因为没有方法来描述和度量可接受的风险。这篇SEI博客文章考察了软件保证和供应链管理领域的度量现状，特别关注开源软件，并强调了一些有前途的度量方法。

供应链中的度量

在当前的环境中，供应商急于推出新功能以激励买家。然而，这种匆忙是以花费在分析代码以消除潜在漏洞上的时间为代价的。通常情况下，买家评估所购产品风险的手段有限。即使供应商快速解决了已识别的漏洞并发布了补丁，也要由该软件的用户来应用补丁。软件供应链有很多层次，补丁经常应用于深埋在供应链中的产品。在一个开源软件项目的例子中，我们计算了超过3600个独特的软件组件依赖关系，它们跨越了近35个“深度”级别(即“a”依赖于“b”，而“b”又依赖于“c”，等等)。每一层都必须应用补丁并向链上发送更新。这可能是一个缓慢而有缺陷的过程，因为对每个特定产品在哪里使用的了解对于供应链中较高的人来说是有限的。最近创建软件材料清单(soms)的命令支持改进可见性的尝试，但是修复仍然需要由包含漏洞的许多层中的每个层来处理。

开源安全基金会(OSSF)记分卡包含了一组可以应用于开源软件项目的度量标准。其理念是，OSSF认为有助于更安全的开源应用程序的项目属性，然后使用加权方法进行报告，从而得出一个分数。

从参数的角度来看，这种方法存在局限性:

• 开源社区正在推动和发展哪些项目需要度量，因此，哪些项目需要纳入工具。
• 每个因素的相对重要性也内置在工具中，这使得很难(但并非不可能)根据特定的、自定义的、最终用户的需求定制结果。
• 工具中度量的许多项目似乎是由开发人员自己报告的，而不是由第三方验证的，但这是开源项目的一个共同“属性”。

其他工具，如MITRE的Hipcheck，也有同样的限制。对于OSSF项目，可以使用记分卡和单个依赖项目的分数来获得项目的分数，但是这种方法会产生问题。这些个人分数如何计入总分?你是在所有依赖项中选择最低的分数，还是应用某种加权平均分数?此外，最近的一篇研究论文指出，在某些情况下，被Scorecard评分较高的开源项目实际上可能产生具有更多报告漏洞的包。诸如此类的问题表明需要进一步研究。

软件网络安全风险度量：实践状态

目前，可以收集大量与一般网络安全相关的数据。我们还可以衡量与网络安全相关的特定产品特征。然而，尽管收集的许多数据反映了攻击的结果，无论是尝试的还是成功的，但是关于早期安全生命周期活动的数据通常没有认真收集，也没有像生命周期的后期那样彻底地分析。

作为软件工程师，我们相信改进的软件实践和过程将产生更加健壮和安全的产品。然而，哪些具体的实践和过程实际上会产生更安全的产品呢?在改进过程和实践的实现与产品的后续部署之间可能会有相当长的时间间隔。如果产品没有被成功攻击，是否意味着它更安全?

当然，政府承包商有盈利动机，证明满足适用于他们的网络安全政策要求是合理的，但他们知道如何衡量其产品的网络安全风险吗?他们如何知道它是否得到了充分的改善?对于开源软件，当开发人员没有得到补偿时，是什么激励他们这样做呢?为什么他们会关心一个特定的组织——无论是学术、工业还是政府——是否有动机使用他们的产品呢?

度量软件网络安全风险：当前可用的度量

SEI领导了一项研究工作，以确定生命周期内当前可用的指标，这些指标可用于提供潜在网络安全风险的指标。从收购生命周期的角度来看，有两个关键问题需要解决:

• 收购是否朝着正确的方向发展，因为它的设计和构建(预测性)?
• 实施工作是否保持了可接受的运行保障水平（反应性）？

随着开发进一步转向敏捷增量，其中许多包括第三方和开源组件，不同的工具和定义被应用于收集缺陷。因此，这个指标在预测风险方面的意义变得模糊不清。

使用有效且管理良好的零信任原则实现的高度脆弱的组件可以交付可接受的操作风险。同样，具有弱接口的构造良好的高质量组件也很容易受到成功的攻击。操作环境对风险暴露至关重要。使用类似于通用漏洞评分系统(Common vulnerability Scoring System, CVSS)的分数对每个潜在漏洞进行简单的评估可能极具误导性，因为没有上下文的分数在确定实际风险方面价值有限。

然而，由于缺乏对用于开发第三方软件(特别是开源软件)的开发过程和方法的可见性，这意味着与所使用的过程和部署之前发现的错误相关的度量(如果存在的话)不会添加到有关产品的有用信息中。缺乏对产品弹性的可见性，因为它与用于开发它的过程有关，这意味着我们没有对风险的全面了解，也不知道用于开发产品的过程是否有效。衡量看不见的东西即使不是不可能，也是很困难的。

网络安全的度量框架

早期的软件度量基本上关注于跟踪提供即时反馈的有形项目，例如代码行或功能点。因此，开发了许多不同的度量代码大小的方法。

最终，研究人员考虑了代码质量度量。复杂性度量被用来预测代码质量。故障报告中的Bug计数，检查期间发现的错误，以及故障之间的平均时间驱动了一些度量工作。通过这项工作，有证据表明，在软件生命周期的早期定位和纠正错误比后期成本更低。然而，说服开发经理提前花更多的钱是一件困难的事情，因为他们的绩效评估严重依赖于控制开发成本。

一些专门的研究人员在很长一段时间内跟踪了度量结果。Basili和Rombach在度量方面的开创性工作产生了目标-问题-度量(GQM)方法，用于帮助软件项目的管理人员决定哪些度量数据对他们有用。在这项开创性工作的基础上，SEI创建了目标、问题、指标、度量(GQIM)方法。在GQIM中，指标确定了回答每个问题所需的信息。然后，依次确定使用指标来回答问题的度量标准。这个额外的步骤提醒涉众注意数据收集的实际方面，并提供一种方法来确保为选定的指标收集所需的数据。这一方法已被民用和军事利益相关方应用。

网络安全方面也收集了类似的数据，这些数据表明，在生命周期的早期纠正可能导致漏洞的错误比在软件运行的后期纠正错误成本更低。这些研究的结果有助于回答有关开发成本的问题，并强调使用良好开发过程的重要性。在这方面，这些结果支持了我们的直觉。对于开源软件，如果对开发过程没有可见性，我们就缺乏关于过程的信息。此外，即使我们对开发过程有所了解，在软件运行后，与漏洞相关的总成本可能从零(如果它从未被发现和利用)到数百万美元不等。

纵观软件工程的历史，我们已经了解到我们需要过程和产品的软件度量。这与开源软件的网络安全没有什么不同。我们必须能够度量开发和使用软件的过程，以及这些度量结果如何影响产品的网络安全。仅仅度量可操作的代码、它的漏洞以及随之而来的成功黑客攻击的风险是不够的。此外，成功取决于协作性、不偏不倚的努力，允许多个组织在合适的保护伞下参与。

主要买家与第三方买家

当软件是购买而不是自己开发时，有三种情况:

• 定制合同软件的购买者可以要求承包商提供他们的开发实践和SCRM计划的可见性。
• 收购方可以指定需求，但开发过程对买方是不可见的，而且收购方对开发过程中发生的事情几乎没有发言权。
• 软件产品已经存在，买方通常只是购买许可证。产品的代码可能是可见的，也可能是不可见的，这进一步限制了可以度量的内容。反过来，产品也可能包含在供应链中进一步开发的代码，从而使度量过程复杂化。

开源软件类似于第三种情况。代码是可见的，但是用于开发它的过程是不可见的，除非开发人员选择描述它。拥有这一描述的价值取决于获取方确定哪些代码质量好，哪些代码质量差，哪些是好的开发过程，哪些是高质量保证过程的能力。

今天，许多美国政府合同要求供应商有一个可接受的SCRM计划，其有效性大概可以衡量。然而，深层的供应链——包括多层次的买家和依赖关系——显然令人担忧。首先，您必须知道链中有什么，然后您必须有一种度量每个组件的方法，最后您需要可靠的算法来为由产品链构建的最终产品生成底线度量集。请注意，当国防部的供应商也合并了其他专有或开源软件时，该供应商现在就成为了一个收购者，并面临着与第三方买家相同的挑战。

度量与最终产品的攻击面相关的风险是有帮助的，但前提是您可以确定攻击面是什么。对于开放源代码，如果构建选择了产品的最新版本，则应该重新审视度量过程，以确保您仍然有一个有效的底线数字。然而，这种方法提出了一些问题:

• 度量完成了吗?
• 度量过程及其结果的有效性如何?
• 每次产品/构建中的组件发生变化时都要重复度量吗?
• 你甚至知道产品/构建中的组件何时发生变化吗?

潜在有用措施的例子

Synopsys对安全测试和分析进行了为期三年的广泛研究，发现92%的测试在被测试的应用程序中发现了漏洞。尽管一年比一年有所改善，但这些数字仍然呈现出一幅严峻的现状。在这项研究中，开源软件的改进似乎源于改进的开发过程，包括检查和测试。但是，不再维护的旧开源软件仍然存在于某些库中，并且可以下载这些软件，而无需进行相应的改进。

这项研究和其他研究表明，社区已经开始在这一领域取得进展，通过定义超出识别开源软件漏洞的措施，同时牢记目标是减少漏洞。在SCRM中有效的度量与开源软件相关。一份SEI技术说明讨论了软件保证框架(Software Assurance Framework, SAF)如何说明特定活动的有希望的度量。注释演示了下面的表1，它属于SAF实践领域2.4项目风险管理，并提出了“项目是否管理项目级网络安全风险?”

表1:特定软件保证活动的有希望的度量标准

活动/实践	输出	候选指标
确保项目策略和计划处理项目级网络安全风险(例如，与网络安全资源和资金相关的项目风险)。	项目计划技术发展战略(TDS)备选方案分析(AoA)	接受网络安全风险培训的项目经理有网络安全相关风险管理计划的程序
识别和管理项目级网络安全风险(例如，与网络安全资源和资金相关的项目风险)。	风险管理计划风险存储库	有网络安全风险的程序每月跟踪网络安全相关的风险

对软件保证度量标准的新需求

一旦我们了解了预测开源软件网络安全所需的所有指标，我们就需要标准，使这些指标更容易应用于供应链中的开源和其他软件。供应商可以考虑将带有指标的软件产品纳入其中，帮助用户了解产品的网络安全状况。例如，在操作层面，漏洞利用交换(Vulnerability Exploitability eXchange, VEX)可以帮助用户了解特定产品是否受到特定漏洞的影响。这些公开可用的信息可以帮助用户对供应链中的开源和其他产品做出选择。当然，这只是如何收集和使用数据的一个例子，它关注的是现有软件中的漏洞。

在整个软件产品开发过程中，都需要类似的记录和报告网络安全风险的标准方法。我们在分析数据时面临的挑战之一是，当数据被收集时，它可能不是以标准的方式收集或记录的。报告通常以非结构化的散文形式写成，不适合分析，即使在扫描报告、搜索关键词和短语并以标准方式分析报告时也是如此。当以非标准的方式编写报告时，分析内容以获得一致的结果是具有挑战性的。

我们已经提供了一些可能有用的度量标准的示例，但是需要数据收集和分析来验证它们实际上在包括开源软件的供应链中是有用的。这种验证需要支持数据收集和分析方法的标准，以及确认特定方法有用性的证据。这样的证据可以从案例研究开始，但是随着时间的推移，这些需要通过大量的例子来加强，这些例子清楚地展示了度量标准在减少黑客攻击、减少产品生命周期中的时间和金钱支出、提高组织声誉和其他价值度量方面的效用。

还必须制定尚未假定的新指标。一些研究论文可能会在一两个案例研究的同时描述新的度量标准。然而，真正信任这些指标所需的大量数据收集和分析却很少发生。无论是否有足够的证据支持新指标的使用，新指标要么被搁置一边，要么被随意采用，因为著名的研究人员和有影响力的组织支持它们。我们相信，定义度量标准、收集和分析数据以说明它们的效用，以及使用标准方法，都需要无偏倚的协作工作来实现期望的结果。

关注微信公众号【赛希咨询】，了解更多精彩内容。