方法论作为整体进行版本管理。对公式、权重或等级阈值的任何变更都会提升指标版本号，且每份公布的报告都记录其生成时所依据的版本（metrics.metrics_version）。这使结果在时间维度上可审计：历史数值可以依据当初产生它的确切规则重新推导。
当前版本为 1.13.0。
每个条目都指明具体的变更、其影响范围，以及既有结果是否仍可比较。日期是公开方法论记录的一部分。
版本历史
1.13.0 — 2026-07-22
两处更正，均由本记录有史以来发布的第一例恶意依赖发现所促成。
风险警示不再叠乘。此前每一项政策都在上一项所剩的数值上再乘一次，因此同时带有两项警示的仓库落在二者的乘积上。有一个项目在恶意依赖乘数下从加权 50 降到 18，又在弃置乘数下降到 11——这个数字没有任何一项政策选择过，也没有任何一项政策可以被指出来解释它。乘数陈述的是一项发现有多严重；它不是一笔应当累加的代价。现在由最严格的那一项政策单独决定，其余的照常报告，但不再第二次移动分值。在这项变更下分值只会上升，且仅限于带有一项以上警示的仓库。
已撤回的包不再按存续中的恶意软件计分。现在每一项恶意发现都会向注册表询问它是否仍在提供恰好这一版本。若不再提供，就不再有可安装之物：该发现仍留在报告中，因为项目依赖着一个曾被入侵的名称，但它不触发风险警示，也不扣分。
这项检查询问的是已解析的版本，而不是该包的最新版本，而这一区分能决定真实案例的结果。撤下之后，npm 会留下一个占位发行版作为该包的最新版本，这保护的是所有解析版本范围的人，而不是任何精确锁定了那个有问题版本的人。若读取最新版本，本项发现首次触发的那个仓库恰恰会被判为干净——而它把被入侵的包锁定在注册表至今仍在提供的那个精确版本上。在根本无法得到答案之处，该发现按包仍然存续来计分——无法访问注册表，并不能证明恶意软件已被撤回。
1.12.0 — 2026-07-22
弃置政策的已声明层级过度触发，所依据的注册表证据并不属于它所判断的那个仓库。
设立该层级是为了引述维护者，而不是作任何推断：当项目已归档，或它发布的每一个包都已停止供应时，才算已声明无人维护。两个缺陷把它撑宽了。除非注册表明确否认，否则一个包就算作项目自己的包——这就接纳了那些根本没有声明任何仓库的条目，而这恰恰是被抢注名称所呈现的样子。此外，最新发行版被撤回也算作停止供应，尽管撤回一次发行版通常只是构建有误、修复紧随其后。
二者合力，仅凭一个它并未发布的 PyPI 占位条目，就把一个评分为 68 的项目压到了 27。现在一个包必须声明这个仓库，并且被明确标记为弃用；撤回的发行版不再计入。在处于已声明层级的 403 个仓库中，391 个依据的是 GitHub 自身的归档标记，从未有过疑问。
1.11.0 — 2026-07-21
弃置成为覆盖整份报告的风险警示。
这一领域的每种工具都以距上次提交的天数来回答“这个项目死了吗？”，而它们都在同一批项目上判断错误：一个小而完备的库三年无需提交，那是已经完成，而非被弃置。把它标记为死亡，恰恰会在最值得信赖的软件上损害公开记录的可信度。
因此评估依据的是另一个问题——弃置是未履行的义务，而非没有动静。沉默自最后一次人类提交起计算，本身从不构成判定；只有当工作明显送达却无人处理时，它才构成判定：无人回应的贡献队列、从未有维护者答复的问题、直接依赖中未修复的安全公告、以项目自身节奏衡量的发布停滞、失败或已有一年之久的持续集成、整个窗口内缺席的唯一维护者。能够解释沉默的读数将结果止步于休眠，而休眠不带来任何扣分 ——安静已经计入开发活跃度，为其重复收费只会惩罚这一区分本就为之而设的那些已完成的库。
判定对健康指数应用乘数：存在风险为 85%，疑似弃置为 60% 并附带 49 的 “存在风险”上限，已声明为 40% 并附带 29 的“危急”上限。已声明是引述维护者自己的表态而非推断——仓库已归档，或其发布的每一个包均已弃用或撤回。无法评估的仓库读作无法核验，不予扣分。参见弃置。
可比较性：相对于 1.10.0，数值只会下降，且仅限于枯水期有未履行义务佐证的仓库。安静而维护良好的项目按设计不受影响。
1.10.0 — 2026-07-21
被报告为恶意包的依赖成为一项独立的安全风险警示，与漏洞公告分离开来。
证据本来就已经在到达。OSV.dev 将 OpenSSF 的恶意包语料库与普通公告一并提供，走的正是本记录本就发出的同一次查询——但恶意包报告既没有严重程度评级，也没有修复版本，于是它落入“未知严重程度”，并按中等漏洞计分。一个被查明为恶意软件的包，其分量略低于一个平均水平的 CVE。
恶意包现在被移出公告类发现，并按其自身的标准计分：对安全态势与加权健康指数应用 35% 的乘数，并对二者设置 29 的“危急”上限。这比高风险司法辖区的上限严格一个等级，因为恶意依赖是已确认的入侵，而不是暴露于某种风险之下。直接依赖与间接依赖同等计入——安装时执行的载荷在已解析依赖图的任何深度都会运行。
预计这项发现会很少出现：发布前在覆盖 46,889 个已解析依赖的 300 个仓库样本上运行，未发现任何一例。注册表会在数日内撤下恶意包，因此一份至今仍解析到恶意包的锁文件是不寻常的。参见恶意依赖。
可比较性：对于没有恶意依赖的每一个仓库——也就是几乎全部仓库——没有变化。一旦发现恶意依赖，其“安全”与健康指数便与任何更早的版本都不可比较。
1.9.0 — 2026-07-21
1.6.0 引入的人类作者身份因子，不再作用于那些只是把自动化做得很好的项目。
单看自动化程度高，结果证明是个糟糕的信号。在提交流量大部分由机器署名的仓库中，最健康的那些仅凭比例无法与已被放弃的区分开来：一个 59,000 星标的项目约有四分之三的提交经由依赖机器人完成，而两天前刚有过一次人类提交；一个整个存在目的就是自动升版的软件包注册表则高达 93%。两者此前都被扣分。
现在这项折减需要第二个条件：机器还必须已经连续单独提交超过 90 天。这一间隔是在采样的提交窗口内测得的，而不是对照当前时钟，因此已存储的报告重新计分时始终得到同一数值。有近期人类提交的仓库，在任何自动化程度下都不再受影响；真正依靠自动化维持的项目则保留其折减。
可比较性：相对于 1.8.0，数值只会上升，且仅限“活力”。
1.8.0 — 2026-07-21
撤回一项信号。增长真实性的先于实质内容的突增 曾主张：发生在项目首次发布之前的爆发能够说明什么问题。在 795 个普通仓库上实测后发现，该政策产出的五项发现中，它每一项都命中——而那五项无一例外都是寻常的项目发布。先公开、再吸引关注、随后才发布版本，本就是项目运作的常态。
这一比较在第二个层面上同样站不住脚。报告所携带的发布版本清单以最新的 100 条为上限，因此对于任何超出该上限的项目，其中最早的一条并非它的首次发布，于是每一次爆发看上去都发生在它之前。
取而代之的从未发布过版本只保留了绝对情形：该项目从未发布过任何版本。它是刻意做弱的，并且只提供佐证，而不下结论。普通仓库群体中的发现数量回落到零，而评估样本中两项已确认的发现依然成立。
一套无法撤回自己已不能再为之辩护的信号的公开方法论，算不上方法论。这正是版本历史存在的意义。
1.7.0 — 2026-07-21
增长真实性新增第五项信号——星标集中度：最忙的五天占据了本次扫描所收集全部星标的 80% 及以上。
它是在该政策首次实地评估之后加入的。那次评估显示它精确，却几乎失明——在 714 个普通仓库中，它一个都没有标出；在 45 个因具备购买关注所留下的形态而被选出的仓库中，它标出了一个。该阈值是从记录中读出来的，而非事先选定的：在 100–1,500 星标区间的 502 个普通仓库中，中位数把 6.9% 的星标放在最忙的五天里，且没有任何一个达到 80%。
该信号为突增提供佐证，绝不单独下结论。一次正当的、由公告驱动的发布会呈现接近的形态——某次研究模型发布测得 73.7%——而一项无法区分二者的信号，不得单独作出判定。
在此项变更之下，评分只会下降，且仅影响本就出现突增的仓库。其余一切不变。
1.6.0 — 2026-07-21
可被人为抬高的输入，不再按面值计入。
新增增长真实性。每份报告收集的逐日星标与复刻历史，现在会被读取以找出其形态不是自然关注所能产生的增长；非自然增长政策会折减流行度的星标与复刻组成部分——一个已确认窗口折减 40%，更多则折减 70%。突增本身绝不构成一项发现：确认需要至少两项独立信号相互佐证，因此产品发布与登上首页的日子仍读作自然增长。已收集的历史无法回答该问题的仓库，其结果为无法核验，不予扣分。该政策不带任何附加权重，因此干净的历史绝不可能提高评分。
开发活跃度在其提交节奏与提交量组成部分之上新增了一项人类作者占比因子。完全依靠自家机器人维持的项目，不再读作处于活跃开发之中；人类占比自 40% 起即可获得满分，因此大量但真实的自动化不受影响。维护者韧性现在只计入人：此前自动化账户会被列入项目的维护者之中，而这恰恰美化了自动化程度最高的那些项目。
除以下情形外，既有数值仍可比较：存在已确认增长发现的仓库，其“社区与采用” 会发生变化；贡献者名单以自动化账户为主的仓库，其“活力”与“可持续性与治理” 会发生变化。在这些变更之下，评分只会下降，绝不会上升。
1.5.0 — 2026-07-20
新增依赖安全公告。每份报告本就会收集的已解析依赖集合——直接依赖加传递闭包——现在会与 OSV 公告数据库比对，受影响的包会连同其严重程度以及各自的修复版本一并列出。
"安全"成为安全态势占 80% 与该新指标占 20% 的加权平均。高风险司法辖区政策的乘数保持不变：它仍然作用于安全态势与加权总分，并且本身不带任何附加权重。
当依赖图或公告查询不可用时，新指标将被排除，其余权重重新归一化——仓库绝不会因关闭依赖图而被扣分。除"安全"之外，既有数值仍可比较；在"安全"上，任何拥有依赖图的仓库现在都会依据此前未纳入考量的证据进行评分。
1.4.0 — 2026-07-19
新增高风险司法辖区暴露，识别俄罗斯、伊朗或朝鲜的高置信度自报位置。层级乘数：仓库所有者 20%、top contributor 50%、公开组织关联 75%。确认命中会对安全态势应用乘数和 49 上限，并在加权后对总体分再次应用；安全类别直接反映调整后的态势。缺失、歧义或无命中数据不扣分。该信号用于确定加强审查优先级，不判定国籍、公民身份、制裁状态、意图或个人可信度。
1.3.0 — 2026-07-18
社区健康的许可证信号变为三态分级—— 标准、自定义或无——取代了此前单一的存在/缺失判定。若仓库的许可证文件存在但其文本不是可识别的许可证，现在获得许可证权重的四分之三，而不再是全额或零分。
检测方式也随之改变：该状态由全部三个许可证来源共同判定（仓库的许可证元数据、GitHub 的社区档案，以及 Scorecard 的 License 检查），而不再优先采用 Scorecard 单一来源。存在与否采用逻辑「或」，只要任一来源发现文件即计为存在。这些来源在约 1% 的仓库上存在分歧。
在本版本之前，自定义许可证的得分本已略低于标准许可证，因为 Scorecard 给它们的评分是 10 分中的 9 分而非 10 分。该差距承袭自工具本身，而非一项明示的立场；现在它是有意为之并载入文档的。
可比较性：既有结果依据各份报告中已存储的数据按 1.3.0 重新计算 ——没有任何仓库被重新扫描，因此除本次变更外不存在其他导致数值变动的原因。变动幅度很小：许可证一行在社区健康的 100 分中占 22.5 分，而社区健康本身占社区与采用的 35%，后者又占总指数的 18%。
1.2.0 — 2026-07-14
新增 Go（模块代理）、Maven Central 与 NuGet 的已发布软件包注册表适配器，并将 PyPI 软件包识别扩展到传统的 setup.py 清单。在这些生态中发布的仓库现在于软件包维护 中携带注册表证据——发布新近度、版本历史、弃用状态——NuGet 还通过其历史累计下载量输入生态采用。Go 与 Maven Central 不发布任何形式的下载统计，因此不贡献采用信号。公式与权重均未变更——变化仅在于哪些仓库拥有可用的注册表证据。
1.1.0 — 2026-07-14
社区健康现在只检测许可证一次。此前它包含两个相互重叠的许可证组成部分——GitHub 社区档案标志与一张独立的 License 共享证据卡片。二者现合并为单一的 License 行，由 OpenSSF Scorecard 的 License 检查检测，社区档案标志仅作为没有 Scorecard 的仓库的回退方案保留。Scorecard 自身的 License 检查仍是 安全态势的完整组成部分。此次合并消除了重复计分，并在两个来源不一致时以 Scorecard 更可靠的检测为准。本版本会改变受影响仓库的 community_health 分数；报告通过其记录的 metrics_version 保持可复现。
1.0.0 — 2026-07-13
当某项安全实践同时能佐证另一健康维度时，OpenSSF Scorecard 检查现在提供共享证据。Scorecard 在安全态势 中仍完整保持风险加权；七项选定检查另外在其目标指标中获得数值较小、有文档记录的权重：Maintained、Signed-Releases、Contributors、 Code-Review、License、CI-Tests 与 Pinned-Dependencies。
这是有意为之的跨类别影响，而非对 Scorecard 安全风险权重的复用。报告为 n/a 的检查或不可用的 Scorecard 数据将从目标指标中排除，其余组成部分重新归一化。本版本会改变受影响仓库的分数；报告通过其记录的 metrics_version 保持可复现。
0.9.0 — 2026-07-07
安全态势的回退检测不再将已发布的库缺失依赖锁定文件视为缺陷。锁定文件是应用层实践；许多库与 gem 正确地省略了它。对这类仓库，回退组成部分现被排除，其余组成部分重新归一化。OpenSSF Scorecard 路径未变。
0.8.0 — 2026-06-30
新增 AI 就绪度类别，包含四项指标（代理上下文、验证循环、 代码可读性、接口），评估仓库对可靠的 AI 辅助开发的支持程度。该类别权重为 0.0：它是独立的附加徽章，绝不改变总健康指数。既有仓库公式未变。
0.7.0 — 2026-06-20
受支持的生态系统扩展。当注册表不发布月度数字时（RubyGems）， 生态采用回退到历史累计下载量，Ruby 与 Hex 软件包因此获得采用数值。新增 RubyGems 与 Hex 注册表适配器；声明依赖解析扩展到 Go、Maven、RubyGems、NuGet 与 Hex。参见 受支持的生态系统。
0.6.0 — 2026-06-09
安全态势基于 OpenSSF Scorecard 重建：工具无关、按风险加权的检查，不再因项目使用非 GitHub 工具链而扣分，无法得出结论的检查被排除而非按零计入。粗粒度的文件树检查作为回退方案保留。仅安全类别受影响。
0.5.0 — 2026-05-29
新增软件包生态指标：社区与采用类别中的 生态采用（注册表下载量），以及可持续性与治理类别中的软件包维护（发布新近度、弃用状态）。对不发布软件包的仓库，两者均为 null。类别内部权重重新平衡；类别权重与其他公式未变。
0.4.0 — 2026-05-18
指标重新归组为五个加权类别，并逐级汇总数值。新增四项仓库指标： 发布纪律、流行度、 托管责任与文档。 activity 更名为开发活跃度。总指数现在汇总类别而非单个指标。
0.3.0 — 2026-05-06
新增组织指标——资料完整度、组合活跃度、社区影响力与组织总分（参见组织评估）。仓库公式未变。
0.2.0 — 2026-04-25
每项指标新增逐组成部分的结果，报告因此能准确显示哪些判定标准通过、部分通过或被排除。公式、权重与等级阈值与 0.1.0 相同。
0.1.0 — 2026-04-15
初始方法论。
版本管理保证什么
- 可复现性——一份报告加上其记录的版本号，完全决定了每个数值是如何计算的。
- 可比较性——在同一版本下接受检验的两个仓库，依据完全相同的规则度量。
- 可问责性——方法论变更公开、注明日期并附有说明；不存在无声的调整。