每一天，我们的数字生活都依赖于一个庞大且无形的软件网络。从手机上的应用程序到管理我们银行账户的系统，现代程序很少是从零开始构建的。相反，它们就像复杂的结构一样，利用被称为“开源依赖项”的预制部件进行组装，这些部件由世界各地的数千个不同个人和组织创建。虽然这种方法使技术得以飞速发展，但也引入了一个显著的风险：如果其中一个借用的部件存在缺陷或具有恶意，那么构建在其之上的整个应用程序都可能失效或遭到破坏。开发人员面临的挑战在于，目前还没有一种单一、简单的方法来判断这些无数组件的可信度。他们必须筛选安全报告、代码质量检查和项目历史，却往往缺乏一种明确的方法来权衡哪些因素最为重要。
为了应对这种不确定性，开姆尼茨工业大学的研究人员开发了一种名为“依赖置信度指数”（Dependency Confidence Index）的新工具。该系统充当了一个统一的计分卡，旨在帮助软件开发人员在决定使用特定的代码片段之前判断其是否值得信赖。研究人员并非仅仅发明了一套新的规则；他们将这种方法建立在现有的关于软件可靠性的科学理解基础之上。他们首先确定了九个对信任度有贡献的关键领域，范围涵盖了从代码本身的安全性到维护该项目的项目健康状况。这些领域包括代码编写的质量、项目是否拥有清晰的许可证、更新频率以及背后人员的声誉。
该项目的核心工作是将这些广泛的概念转化为具体的、自动化的测量指标。团队创建了一个数字平台，该平台可以扫描软件库并收集关于这九个因素的数据。为了确定每个因素在最终得分中所占的比重，他们咨询了一个由十名资深软件开发人员组成的小组。这些专家通过相互比较各项因素，以决定哪些因素对于安全性和可靠性最为关键。结果是一个加权系统，其中安全性脱颖而出成为最重要的因素，紧随其后的是源代码的质量和项目的整体健康状况。随后，该平台会将收集到的原始数据（例如已知漏洞的数量或代码更新的频率）合并为一个介于零到一之间的数字。接近一的分数表示该组件具有高度的可信度，而较低的分数则表明存在潜在风险。
研究人员在 Python 编程语言中使用的 92 个流行软件包上测试了他们的新指数。他们发现该系统运行非常稳定，在对相同软件包进行多次运行时会产生相同的结果。当他们将新得分与现有的安全工具 OpenSSF Scorecard 进行对比时，观察到了两者之间存在中度的吻合度。这表明新指数捕捉到了与既有工具类似的信息，但提供了不同的视角。有趣的是，分析显示，对于这些高质量的流行软件包而言，得分更多是由项目管理水平（如自动化测试的使用和清晰的依赖规则）驱动的，而非由安全缺陷的存在所驱动。在这一特定的测试组中，由于安全指标表现得非常一致且极高，因此不足以在不同的库之间产生差异。这并不意味着安全性不重要；相反，它表明对于成熟且流行的项目，软件的维护过程往往是信任度的最强信号。
该研究也强调了他们目前方法的局限性。研究人员指出，他们的系统依赖于一些有时难以自动获取的数据，例如能够维护项目的确切人数或文档的完整程度。此外，测试仅限于流行的 Python 库，这意味着对于那些更旧、知名度较低或带有恶意的软件包，结果可能会有所不同，因为后者更容易出现安全缺陷。团队谨慎地声明，该指数并不是专门安全工具的替代品，也不能保证一段软件是安全的。相反，它旨在作为一种筛选辅助工具，帮助开发人员整理有关库的大量可用信息，并识别哪些领域可能需要更仔细的检查。通过提供一个单一且可解释的数字以及每个因素的详细分解，依赖置信度指数旨在让构建我们数字世界的开发人员能够更轻松地应对复杂的软件供应链安全任务。
技术摘要：依赖置信度指数 (DCI)
问题陈述
选择值得信赖的开源软件 (OSS) 依赖项仍然是软件供应链安全中的一个关键挑战。虽然存在针对单个质量信号（如漏洞数量、测试覆盖率）的指标，但开发者缺乏一个统一且具有解释性的评分来指导依赖项的选择。现有的工具通常侧重于特定领域（安全性、代码质量或项目健康度），或者需要对异构数据进行人工聚合。此外，恶意开源软件包在 2024 年同比激增了 156%，且 96% 被下载的漏洞组件都有可用的修复程序，这凸显了可用信息与可操作决策之间的差距。
方法论
作者提出了依赖置信度指数 (Dependency Confidence Index, DCI)，这是一个复合形成型指数，旨在将九个经过经验加权的信任因子聚合为一个 [0,1] 区间内的归一化得分。该方法遵循结构化流程：
- 信任因子选择： 九个因子源自系统性文献综述 (Hou and Jansen [12])，并被分为属性维度（安全性、源代码质量、文档完整性、许可证声明）和过程维度（开发过程质量、项目健康度、发布节奏、依赖管理、声誉）。
- 通过 AHP 进行加权： 通过一项涉及 10 名软件开发者的探索性层次分析法 (AHP) 调查来确定经验权重。安全性 ($0.277)、源代码质量(0.164)和项目健康度(0.140$) 被确定为最具影响力的因素，共同占据了约 60% 的总权重。
- 测量实现 (GQM)： 使用目标/问题/指标 (GQM) 方法，利用 SonarQube、GitHub API 和 OpenSSF Scorecard 数据实现了 12 项自动化测量。这些测量包括缺陷密度（漏洞、Bug、代码异味）、注释密度、许可证存在情况、CI 使用情况、测试覆盖率、公交因子 (bus factor)、发布频率、依赖管理工具以及流行度（GitHub stars）。
- 归一化： 使用特定实现的参考值（例如，源自先前对 C/C++/Java 研究的上界）将连续测量值归一化到 [0,1] 区间。布尔值测量被映射为 0 或 1。
- 系统架构： 开发了一个容器化的评估平台，由评估平台（Web 界面、后端）和 JobRunner（Docker 隔离环境）组成。该系统自动执行仓库克隆、静态分析 (SonarQube) 和指标收集，以计算加权后的 DCI 得分。
核心贡献
- 复合信任模型： 一个结合了九个不同信任因子的形成型指数，通过 AHP 加权，为 OSS 依赖项提供单一的面向决策的评分。
- 自动化测量框架： 在安全性、代码质量和项目健康维度中实现了 12 项自动化测量，并部署在可复现的容器化环境中。
- 试点评估： 对流行的 Python 包进行了研究，评估了 DCI 与 OpenSSF Scorecard 的相关性及其重测信度。
结果
对流行 Python 包的试点评估得出以下发现：
- 样本量： 在最初选择的 100 个软件包中，92 个被 DCI 平台成功测量。然而，由于与现有的 OpenSSF Scorecard 数据缺乏重叠，最终用于对比评估的软件包数量为 85 个。
- 相关性： 归一化后的 DCI 得分与 OpenSSF Scorecard 得分显示出中等程度且具有统计学意义的相关性 (ρ=0.396,p=0.0002)。
- 可靠性： 在不变条件下，该系统对一组软件包展示了完美的重测信度。
- 因子影响： 与 AHP 调查中分配给安全性的高概念权重相反，安全性因子 (SV) 与最终 DCI 得分没有显著相关性 (r=0.033)。这归因于数据集由流行的、成熟的软件包组成，其漏洞和安全问题密度恒定（接近于零），导致该因子在此特定样本中缺乏区分度。
- 主导驱动因素： 过程类因子，特别是依赖管理 (r=0.760) 和开发过程质量 (r=0.602)，主导了高质量软件包的得分方差。
- 测量局限性： 若干测量项（如许可证声明、漏洞密度）在样本中是恒定的 (1.0)，而代码覆盖率 (P2) 由于 SonarQube 对 Python 项目的限制未能生成有效数据 (0.0)，从而降低了该试点中指数的有效维度。
意义与主张
本文将 DCI 定位为专门的安全工具的补充，而非替代品，作为支持依赖项审查的补充筛选信号。其主要意义在于：
- 综合性： 提供了一种对异构信号的共同表示，这些信号通常分布在多个工具（如 SonarQube、Scorecard 等）中。
- 透明度： 通过组织证据，帮助开发者识别特定领域的弱点（例如维护、许可、流程），而不是提供自动化的安全保证。
- 基础性： 提供了一个公开可用的实现和框架，用于进一步研究 OSS 可信度。
作者明确指出当前结果是初步的。归一化边界是工程近似值，而非针对所有生态系统的经验校准阈值，且 AHP 权重基于一个小型且同质的样本。该研究并不声称 DCI 是供应链风险的决定性衡量标准，也不声称当前的权重方案是恒定的；相反，它作为自动化依赖审计的基础性步骤。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。