方法论

本页面是公开记录中每一个数值如何计算的人类可读规范。方法论作为整体进行版本管理——当前版本为 v1.13.0——每份报告都记录生成它的版本。各项指标的细节载于维基；本页面阐述整体体系。

标准化量表

每一项衡量结果——组成部分、指标、类别、总体——均为 1–100 范围内的整数，数值越高越好，并映射到五个标准化的 评级等级：优秀（85–100）、良好（70–84）、 中等（50–69）、存在风险（30–49）、危急（1–29）。等级阈值是版本化方法论的组成部分。

三级层次结构

数值透明地逐级汇总：组成部分 → 指标 → 类别 → 总体（详见 健康指数）。

1. 指标是各组成部分的加权和；组成部分的权重合计为 100。每个组成部分都会报告其实际得分与满分，以及一个状态——达标、部分达标、未达标或已排除。有四项载入文档的政策属于例外：被报告为恶意包的依赖会对安全态势应用乘数与上限，已确认的高风险司法辖区暴露以更宽松的上限做同样的事，已确认的非自然增长发现会折减流行度的星标与复刻组成部分，而弃置判定则对健康指数本身应用乘数。
2. 类别通常是可用指标的加权平均值。这四项政策都只作为惩罚性乘数存在——它们都不会提高其所作用的指标，也都不带任何自身的附加权重。
3. 总体健康指数先计算可用类别的加权平均值。某项政策一旦触发即应用其乘数，其中一些还会设置上限：恶意依赖或已声明的弃置为 29（危急），高风险司法辖区暴露或疑似弃置为 49（有风险）。若有多项同时触发，只适用最严格的那一项——它们绝不叠乘。

缺失数据绝不计为零

当某个组成部分的底层数据不可获得时，它会被排除，其余权重重新归一化——项目只在可观测的范围内接受衡量。同一规则同样适用于整个指标与类别，每一次重新归一化都会记录在受影响指标的注释中。

风险警示

本方法论中的绝大多数证据都是计分的：它获得分值，分值汇总为指标，指标再平均为类别。风险警示是其中的例外——这类发现不计入某个数值，而是 调整它，并且报告将其呈现为一项具名的警示，而非一个数字。

设立这一类别，是因为有些发现无法被诚实地平均掉。一个被报告为恶意的依赖，不是工程实践中的八分；它是一种状态。按交付排期到来的星标，不是流行度的一个低分；它是不再采信该计数的理由。若把二者当作扣分来处理，其他方面的优异表现便足以将其吸收，而这恰恰是错误的结果。

本方法论中的每一项风险警示都遵守同样的五条规则：

1. 它只会使数值下降。任何风险警示都不带附加权重，干净的结果也绝不会提高任何数值。没有发现并不构成一项资质证明。
2. 它被明确陈述，而不只是被扣减。该发现会作为警示出现在报告中，指明其证据，并链接到定义它的指南。读者必须能够看到评级为何发生了变动。
3. 它描述的是一项观察，绝非一种意图。每一项都是关于公开证据的陈述 ——某份资料所公开的所在地、某个公告数据库所指名的软件包、星标事件的发生时间。它们都不确立任何人的动机、责任或不当行为。
4. 无法回答不等于干净。当某项警示所需的证据从未被收集时，报告会如实说明。无法评估的仓库，绝不会被呈现为通过了评估的仓库。
5. 只适用最严格的那一项。当有一项以上的警示触发时，最严重的那一项单独决定分值，其余照常报告但不再次移动它。乘数陈述的是一项发现有多严重；把若干乘数相乘会得出一个没有任何政策选择过的数字。

目前已定义的警示为非自然增长政策、 弃置政策、恶意依赖政策与 高风险司法辖区政策，各自在下文列明。每一项在整个记录中出现的频率，公布于汇总统计。

仓库类别与权重

非自然增长政策

GitHub 星标是开源领域被阅读得最广泛的信任信号，也是其中唯一没有签发方的信号：星标与复刻被公开批量售卖。因此，每份报告收集的逐日星标与复刻历史会被读取，以找出其形态不是自然关注所能产生的增长——按排定节奏到来、未带来复刻、未留下尾部，或发生在项目发布任何东西之前的爆发。

爆发本身绝不构成一项发现；真实的项目也会发布、也会登上热门。只有当至少两项独立信号相互佐证时，一个窗口才被确认。一个已确认窗口将流行度的星标与复刻组成部分折减 40%，两个及以上折减 70%。关注者及其他任何类别都不受触动，干净的历史也绝不会提高评分。

已收集的历史无法回答该问题的仓库——没有历史、星标数不足 100，或窗口跨度不足 60 天——结果为无法核验，不予扣分。收集范围限于近期窗口，因此早于该窗口的操纵对本政策不可见；无法核验意味着无法回答，而非干净。完整的 增长真实性指南载明各项阈值、四种状态，以及证据的界限。

这是一项关于公开事件发生时间的陈述。它不证明关注是被购买的，也不证明若确有购买，仓库的维护者曾参与其中。

弃置政策

项目并不因为安静就算被弃置。这一领域的每种工具都用距上次提交的天数来回答 “这东西死了吗？”，而它们都在同一批项目上判断错误：一个小而完备的库三年无需提交，那是已经完成，而非被弃置。

因此这项判定依据的是另一个问题——弃置是未履行的义务，而非没有动静。一个安静而没有任何待办事项的仓库不欠任何人。而一个安静的仓库若有十五个无人评审的拉取请求，或者一份一年前的安全公告、其补丁当周即已发布，那它并非在休息。

沉默是必要的，却从不充分。枯水期自最后一次人类提交起计算，只有当未履行的义务佐证它时，它才成为判定：无人回应的贡献队列、维护者从未答复的问题、直接依赖中未修复的安全公告、以项目自身节奏衡量的发布停滞、失败或已有一年之久的持续集成，或整个提交窗口内缺席的唯一维护者。能够解释沉默的读数——维护者仍在事务跟踪器中回应、没有待答复的开放事项、一年内有发布、依赖干净——将结果止步于 休眠，而休眠完全不带来任何扣分。安静已经计入 开发活跃度；为其重复收费只会惩罚那些恰恰值得信赖的、已完成而稳定的库。

判定对健康指数应用乘数：存在风险为 85%，疑似弃置为 60% 并附带 49 的 “存在风险”上限，已声明为 40% 并附带 29 的“危急”上限。已声明是引述维护者自己的表态而非推断——仓库已归档，或其发布的每一个包均已被标记为弃用或撤回。没有提交样本、事务队列不可读，或历史不足 180 天的仓库读作无法核验，不予扣分。完整的弃置指南载明每一项阈值、信号与保全理由。

恶意依赖政策

存在漏洞的依赖是失误；恶意依赖则是攻击。每份报告都会将已解析的依赖图与 OpenSSF 恶意包语料库比对，而该语料库由 OSV.dev 与普通公告一并提供——因此这项检查不会额外消耗任何报告本就不必发出的请求。

恶意包既没有严重程度评级，也没有修复版本，因为它二者皆无：它是一种状态，而非一种程度，补救办法是移除或改弃被入侵的名称，而不是升级。若注册表此后已撤下仓库所解析到的那个确切版本，就不再有可安装之物：该发现予以记录报告，但不计分。因此把它当作公告计分等于低估了它；它被移出公告类发现，并作为一项警示处理。任何已确认的报告都会对安全态势与加权总体分应用 35% 的乘数以及 29 的“危急”上限——这比司法辖区上限严格一个等级，因为这是已确认的入侵，而不是暴露于风险之下。直接依赖与间接依赖同等计入：安装时执行的载荷在依赖图的任何深度都会运行。

这项发现按其构造就很罕见——注册表会在数日内撤下恶意包，而发布前在 46,889 个已解析依赖上的一次运行没有发现任何一例。它针对的是已发布形态的软件包，而非被扫描仓库的维护者，后者可能是在不知情的情况下解析到该包的。完整的 恶意依赖指南载明来源、计分方式以及该主张的界限。

高风险司法辖区政策

当前俄罗斯、伊朗或朝鲜政策范围内的高置信度公开自报位置会触发政策乘数：仓库所有者 20%、 top contributor 50%、公开组织关联 75%。歧义或缺失数据不扣分，也不推断国籍、公民身份、制裁状态或意图。

任何确认命中都会对安全态势和加权总体分应用乘数与 49 上限。安全类别直接反映调整后的态势，不重复乘算。报告保留所有基础数值。完整的 治理指南说明企业场景、证据保护和适当响应。

某项指标在总体指数中的有效权重通常为类别权重 × 类别内权重——在报告中每张指标卡片上均有显示。非自然增长政策、弃置政策、恶意依赖政策与高风险司法辖区政策是乘数形式的例外，它们都不带任何自身的附加权重。 AI 就绪度的权重为 0：它是一枚独立的附加徽章，绝不影响健康指数。

依托注册表的指标（生态采用、 软件包维护）仅适用于发布了软件包的仓库——参见支持的生态系统。

依赖安全公告

仓库的依赖会与 OSV 比对。OSV 是聚合 GHSA、PYSEC、RUSTSEC 等来源的开放公告数据库。受影响的包会连同其严重程度、相关公告以及各自的修复版本一并列出。

所衡量的是使用者实际安装的内容。对于发布了包的仓库，被评估的集合是该包的运行时依赖闭包——安装它时真正被拉取进来的东西。只有当仓库没有发布任何包时，才转而评估其自身的依赖图；而该图还包含从不交付的开发与测试版本固定。每份报告都会说明它评估的是两者中的哪一个，并给出包名。

这一区分会实质性地改变结果。Flask 的仓库依赖图中带有针对旧版 Werkzeug 与 Jinja 的公告，那些版本是它为自身测试矩阵而固定的；而安装 Flask 只会引入六个包，无一受影响。只有后一个事实，说的才是他人所依赖的那个软件。

目前可解析运行时闭包的有 npm、PyPI、crates.io 与 Maven。发布在其他registry 的包，在索引覆盖它们之前，仍按仓库依赖图评估。

这是有意与安全态势分开的独立指标。Scorecard 自身的漏洞检查已经查询同一个数据库，并且已经计入安全态势；若在同一指标内再对一个源自它的信号计分，等于把同一份证据算了两次。二者回答的问题不同：安全态势问的是项目是否存在已知的易受攻击依赖，本指标问的是具体是哪些、严重到什么程度、以及什么能修复它们。

它不主张的内容：此处的公告仅表示依赖图中记录的版本落入某条公告的受影响范围。可达性未经分析；依赖图也不会把开发与测试依赖同项目实际交付的内容区分开，因此某项发现可能只涉及工具链而非交付的软件。每份报告都会声明其覆盖范围：评估了多少依赖、有多少未能评估。

没有依赖图的仓库不会因此被扣分：该指标将被排除，其余权重重新归一化，与任何其他不可用输入的处理方式一致。

共享的 Scorecard 证据

安全类别依旧是完整的、按风险加权的 OpenSSF Scorecard 评估。其中七项检查同时为其明确描述的其他维度提供佐证：维护状态、签名发布、贡献者、代码评审、许可证、CI 测试与固定版本依赖。其中六项以小型附加卡片的形式出现在其目标指标中，同时保留其对安全类别的贡献。第七项—— 许可证——则有所不同：它是社区健康中许可证信号的一项输入，而非其全部——详见下文。这种有意为之的跨类别影响在各指标中均有记录；Scorecard 的 n/a 与不可用结果在所有位置一律排除。

许可

仓库的许可证由所有可用来源共同判定为三种状态之一——仓库自身的许可证元数据、GitHub 的社区档案，以及 OpenSSF Scorecard 的 License 检查。只要任一来源发现了许可证文件即计为存在，因此单个端点不可用不会导致许可证被报告为缺失。

自定义许可证是真实的许可证，可获得大部分权重。它不能获得全部权重：自动化工具无法识别的许可证是采用过程中的实际障碍，因为策略工具、企业法务审查与软件包注册表都依赖可识别的标识符，而读者若不亲自阅读文本便无法确定自己被允许做什么。

在 v1.3.0 之前，自定义许可证的得分本已略低，但那是 Scorecard 评分方式的副产物，而非一项明示的立场。上述分级是有意为之的，并且现在构成完整的许可证信号。

组织评估

组织按同一量表与等级进行评估，分为两个类别——活跃度与影响力（75%）和治理与档案（25%）——详见 组织评估。仓库的报告中也会嵌入其所属账户的档案，该档案驱动托管责任指标。

配置

一次扫描可以停用某个组成部分、指标或类别；这种排除的处理方式与缺失数据完全相同，并嵌入报告之中，因此每个结果都可以按发布时的状态复现。配置绝不改变任何公式、权重或阈值——参见 扫描配置。

版本管理

对公式、权重或等级阈值的任何变更都会提升指标版本号。完整的、注明日期的历史——从 0.1.0 到当前的 1.13.0——载于 方法论版本。

计算示例

pallets/flask（组织持有），于 2026-07-16 按方法论 1.4.0 完成检视—— 最新数值始终以完整报告为准：

AI 就绪度为 58，权重为 0，因此不计入总和。

同一仓库若在拥有相同关注度的个人账户名下，将失去组织背书的加成以及 托管责任中的已验证域名组成部分，进而拉低治理类别的得分。这种所有权影响是有意为之的、明确的且可审计的。

以上数值均为某一时点的快照。随着证据变化与方法论版本更新，数值会发生变动；所链接的报告始终呈现当前值。

路线图（尚未纳入衡量）

• 问题与 PR 延迟的百分位数，按时间窗口而非整个生命周期统计。
• 依赖新鲜度：有多少依赖在上游被标记为弃用、已归档，或多年未发布新版本。已知公告现已纳入衡量——参见依赖安全公告—— 但新鲜度是另一个信号，尚未计入评分。
• 按流行度归一化的期望值（50 星的仓库不应以 50,000 星仓库的基准来要求）。
• 测试覆盖率与 CI 通过率信号。

上述每一项都将伴随版本号提升而推出，绝不悄然上线。