摘要

  • OpenSSF Scorecard 对一组自动化启发式检查分别给出 0 至 10 的结果，并按风险权重汇总；它明确承认误报与漏报。
  • 该项目不把自己定义为适用于所有项目的最终报告或要求。相同总分可能来自完全不同的检查组合。
  • 消费方可以把扫描当作证据之一，但扫描不能界定实际采用的版本、组织的风险容忍度、例外责任人或后续行动。

分数为何有用，又为何不能越界

OpenSSF Scorecard解决的是一个很实际的问题：公开仓库留下的信号太多，而维护者和使用者没有时间在每次依赖选择前从头审阅。它把若干可自动观察的安全相关启发式条件转化为单项分数，再按风险权重形成汇总分数。这个结果可以提示应当先问什么，而不是宣布问题已经得到回答。

项目自己的表述很清楚。检查项的取舍、重要性与计算方式都包含判断；启发式方法会产生假阳性和假阴性；Scorecard 的非目标包括成为一份最终、通用的报告或要求。总分也不告诉读者每一项具体行为是否存在，检查集合改变或规则改进后，同一对象的结果还可能变化。

这不是工具的软弱之处，反而是它的诚实边界。一个分数记录的是在某一时间、以某种可得数据和规则观察到的仓库表面。它不是对全部源码、所有发布物、下游构建环境或实际运行风险的全景承诺。

总分压缩信息，不能压缩责任

总分易于放进徽章、供应商清单和治理看板，也容易被误用成一个阈值。可分数是不同检查项的风险加权平均，不是对一个统一性质的直接测量。两个仓库可以得到相同分数，却在某个特定使用者最在意的条件上相反。

检查文档说明了这一点。Maintained 依据限定时期内可见的活动判断，同时承认活动较少的软件并不必然有风险。SBOM 检查在指定的源码、流水线或发布位置寻找清单。找到清单是“存在”的证据，却不能证明它完整、准确、对应将被部署的二进制文件，或足以解决某个使用方的暴露面。

观察路径也不能丢失。公开周度扫描有已声明的范围；因大规模运行成本，API 结果会省略某些检查；具备不同权限的本地运行可能看到不同资料。目标标识符和解析后的引用、扫描时间、工具版本、可访问数据、单项结果与细节，共同定义了一个分数到底在说什么。只有数字而没有这些要素，今天的显示就可能被误读成对过去版本或另一种制品的证明。

注释补充语境，不授予信任

低分并不等于失职、漏洞、入侵或停止维护。它只能表明一个已定义的自动观察没有得到预期信号。Scorecard 多次提醒：实践可能存在而未被识别。因此，结果应触发核查，而不是形成对项目的裁决。

其维护者注释机制正是为此保留余地。test-data、remediated、not-applicable、not-supported 和 not-detected 等标签可说明检查为何没有呈现全部背景。它们有价值，因为它们让工具的盲区可见。但注释仍是维护者提供的说明，不是独立验证，更不是让任何消费方必须接受依赖的授权。

由此至少存在三种不能混合的记录：工具观察到什么；维护者如何解释观察；采用方决定如何使用具体组件。前两项不能替第三项承担后果。

真正的决策对象在扫描之外

组织依赖的可能是一个锁定提交、一个包版本、内部镜像或自建流水线产生的制品。它可能拥有不同网络权限、处理不同数据，或者位于有替代方案和退出计划的环境里。采用方可以暂时例外、增加隔离和监测、索取补充材料、选择替代品，或拒绝引入。所有这些动作都属于承担风险的一方，不能从加权平均数中自动导出。

因此需要一份简短的“扫描—依赖决策”记录。第一部分保存仓库标识和解析引用、Scorecard 版本和扫描时点、数据访问限制、总分以及真正相关的单项检查、理由和维护者注释。第二部分单独写明被考虑的包或版本、使用场景、补充证据、决策责任人、阈值或例外理由、采取的动作以及下一次复核条件。

这样的记录不把 Scorecard 变成认证体系。它只是阻止一次自动观察悄悄借用本应属于当地组织的决定权。

来源

  1. OpenSSF Scorecard README
  2. OpenSSF Scorecard 检查文档
  3. OpenSSF Scorecard 维护者注释