方法论作为整体进行版本管理。对公式、权重或等级阈值的任何变更都会提升指标版本号，且每份公布的报告都记录其生成时所依据的版本（metrics.metrics_version）。这使结果在时间维度上可审计：历史数值可以依据当初产生它的确切规则重新推导。
当前版本为 2.10.0。其实现发布于 inspect-software/scanner。可将报告中的 metrics.metrics_version 与仓库历史中的 METRICS_VERSION 对照，以确定执行计算的代码。
每个条目都指明具体的变更、其影响范围，以及既有结果是否仍可比较。日期是公开方法论记录的一部分。
版本历史
2.10.0 — 2026-08-22
只有可能真正缺少某个接口的软件，才会被要求具备它。 机器可读接口这项指标此前对每个被纳入的仓库都执行全部三项检查，于是一个 examples/ 目录——几乎每个库都会有——就足以让项目被指出缺少 OpenAPI 模式和 MCP 服务器。记录中超过四分之一的仓库仅因示例目录而进入该指标。一位维护者说得很直接：他不明白这两项检查如何适用于他的数据库驱动——他是对的。API 模式现在仅对网络服务和聊天机器人提出要求，MCP 服务器仅对网络服务，可运行示例则面向所有软件；其余情况将被排除，其余权重重新归一化。已存在的证据始终计分。没有仓库会新进入该指标，也没有分数会下降。
2.9.0 — 2026-08-22
为其发布的一切托管文档的注册表，计为文档站点。 2.7.0 接受通过注册表声明的文档 URL。crates.io 更进一步：它为接受的每一个 crate 构建并提供文档页面，无论清单是否声明——因此仅仅省略了这个可选键的 crate 依然会失分，这衡量的是手续而非文档。该检查现在会在考虑所有已声明的 URL 之后，回退到那个托管页面。目前只有 crates.io 符合条件；某个生态加入该名单，取决于其托管是否经过实测，而非看起来相似。分数只会上升，且该修正无需重新扫描即可生效。
2.8.0 — 2026-08-22
组织的已验证域名终于被读取，"未读取"不再等同于"未验证"。 管理中的已验证域名检查此前从 GitHub 的用户端点读取该标志，而该端点虽然也返回组织，却完全不包含验证字段——只有组织端点才携带它。因此记录中的每一个组织，无论实际状态如何，都未能通过这项 20 分的检查，而记录中 59% 的仓库归组织所有。一位维护者在阅读自己的报告时发现了它。现在仅针对组织查询组织端点。评分随之改变：未读取的标志——存在于此前生成的每一份报告中，以及任何查询失败时——现在会被排除并对其余权重重新归一化，而不是记为"未验证"：从未发出的请求不能作为域名未验证的证据。
2.7.0 — 2026-08-20
通过注册表声明的文档予以计入。文档指标的文档站点检查此前只接受 GitHub 的 homepage 字段。Rust 库在 docs.rs 上提供文档，通过清单中的 documentation 键声明（由 crates.io 镜像），且很少设置 GitHub homepage，因此整个生态的库都失去了这些分数；一位收到徽章 pull request 的维护者在自己的报告中发现了这一错误，syn 和 serde 也存在同样的问题。该检查现在会回退到通过软件包注册表声明的文档或主页 URL：crates.io 的 documentation 与 homepage、PyPI 的 project_urls、RubyGems 的 documentation_uri、Hex 的文档链接、npm 与 Packagist 的 homepage、NuGet 的 projectUrl。托管在 github.com 上的主页只是重复仓库链接，不予计入。分数只会上升，且仅当注册表声明了仓库已经发布的内容时才会变化。既有报告在重新扫描后获得此项修正，因为注册表声明是在采集时记录的。
2.6.0 — 2026-08-19
采用度证据必须指回本仓库。 生态采用度 现在仅统计注册表条目声明本仓库为其所属仓库的包的下载量和依赖方数量。仓库清单中声明、但注册表条目未声明任何仓库的包名，仍保留存在性上的善意推定，但不再把其下载数字借给仓库：该规则曾让一个无关 npm 包的每月 25 次下载出现在报告中，取代了项目在 PyPI 上约 1400 万/月的真实数字 —— 由项目维护者本人发现。被排除的包现在会在指标输入中列明。仅有未验证数字的仓库将该指标显示为无数据并重新归一化。只有此前统计了未验证数字的仓库分数会变动；已验证的证据不受影响。
2.5.0 — 2026-08-04
分类首次影响评分：安全态势 回退机制中的依赖锁文件期望对已发布的应用程序恢复生效。此前仅凭发布这一事实就会免除该检查——而被免除的恰恰是这条指引所针对的仓库：ruff、black 和 poetry 都是已发布的应用程序，包管理器自己的建议就是让应用程序提交锁文件。清单中声明了可执行文件的已发布软件包现在保留该期望。
此变更附带两道防线。常设规则，未来的每次接入都将遵循：评分只读取清单声明—— 从文件结构、主题或描述推断出的标签会被展示，但绝不移动分数。且影响范围在发布前已经测量：锁文件组件只存在于 OpenSSF Scorecard 不可用时的回退机制中（49,846 份已存储报告中的 472 份），其中恰好 4 份报告发生变化——1 份加分，3 份减分。该变更实际上面向未来：它约束今后没有 Scorecard 的扫描，并让方法论践行自己的表述。
2.4.0 — 2026-08-04
分类词汇表改为显式的两级树——库 · 应用程序 · 宿主扩展 · 笔记本，应用程序与宿主扩展之下设子类型——取代原先十九个标签的扁平列表。不影响任何评分。
三项结构性变更。五个标签并入「库」：框架、SDK、API 客户端、中间件和驱动没有站得住的边界——axios 既是 API 客户端也是库，flask 既是框架也是库—— 且没有任何使用方对这一区分做过任何事。答案可以停在顶层：Cargo 的二进制目标和 Go 的 cmd/ 布局证明的是可执行文件而非其种类，这类仓库现在被直接归类为「应用程序」，而不是以降权的方式被硬塞进「命令行工具」。宿主扩展按宿主类别设子类型——插件、浏览器扩展、编辑器扩展、主题——因为类别决定了所继承的信任面，而 WordPress 与 Chrome 之间的命名差异什么也决定不了。
2.3.2 — 2026-08-04
围绕 Go 仓库与代码质量工具的三项分类更正，源于对 go-critic 的复查——这个 Go linter 的报告仅凭一个事实就被读作库：它的模块能在 Go 代理上解析。 不影响任何评分。
Go 模块代理不再算作发布。 其他每个注册表记录的都是维护者的有意行为；而代理会在任何人请求时立即索引任何带 go.mod 的仓库——服务器和命令行工具携带该条目的方式与库完全相同。与 2.3.1 中的 MCP 信号一样，它现在只作旁证而不作决断：唯一的库证据是代理条目的仓库将失去该标签，直到出现更有力的证据。
Go 的文件树被当作它本来就是的声明来读取。 这门语言没有描述构建产物的清单字段；cmd/ 布局和由编译器强制执行的 internal/ 规则就是它的表达方式。现在 cmd/ 目录内的任何源文件都标记一个二进制产物——此前只有字面名为 main.go 的文件才算，这掩盖了 go-critic 的第二个命令——而未被 internal/ 规则封闭的包计入 库，为代理条目提供旁证。
linter 与 formatter 标签承载命令行读法——宿主扩展除外。 标注 linter 或 formatter 的仓库几乎总会提供可运行的检查器。例外是系统性的而非偶然的：在全部记录上测量，256 个带 linter 标签的仓库中有 42 个是面向宿主 linter 的规则包或配置，那里可运行的工具是宿主。一旦独立证据把仓库标记为插件、扩展、主题或编辑器工具，该贡献即被完全撤回。
2.3.1 — 2026-08-03
对数小时前发布的分类所做的更正：Model Context Protocol 信号不再单凭自身把仓库判定为 MCP 服务器。不影响任何评分。
该信号由 .mcp.json 触发——那是把编辑器配置为调用 MCP 服务器的文件——也由任何名称以 mcp 结尾的依赖触发，而客户端声明这类依赖的方式与服务器完全相同。它记录的是一个项目已配置为与编码代理协作，而不是它本身就是被调用的服务器之一。在全部记录上测量：仅凭该信号就产生了带此标签的 3115 个仓库中的 1746 个， freeCodeCamp 亦在其中。现在它需要旁证；真正的服务器仍可通过其主题或依赖被分类。
2.3.0 — 2026-08-03
每份报告现在都会说明仓库构建的是什么：该软件是作为代码被引用、作为程序被运行，还是被安装进由宿主提供信任模型的环境。本版本不改变任何评分——分类 以数据形式发布，尚未作为任何指标的输入。
在此之前，这个问题一直由单一的替代信号代答：仓库是否向注册表发布了软件包。按此标准，PyPI 上的每个命令行工具都会被读作库，顺带发布了一个辅助包的每个应用程序同样如此——然而由此推导出的期望差别很大。已发布的库理应不提交依赖锁文件；而目录中与它并列的应用程序理应提交。
分类会记录证据所支持的全部读法，而不是其中一种。既是已发布的库、又是可运行的工具，这是常态而非矛盾；这样的仓库将同时承担两种读法的义务，而不是取其中最宽松的一种。证据按可信程度分级：构建清单直接声明的内容——OutputType、 Composer 的 type、npm 的 bin 条目、控制台脚本入口点——比文件树结构、已声明的依赖和自行标注的主题更有分量，任何单一的弱信号都不足以独自支撑一种读法。当证据无法回答这个问题时，报告如实记录这一点，而不是猜测。
将分类接入依赖它的各项指标——首先是依赖锁文件，现行规则对已发布的工具明显有误——将作为另一个注明日期的版本发布。
2.2.0 — 2026-08-02
高风险司法辖区分类器不再把否认读作声明，并且现在将政策范围之外被点名的地点视为相互矛盾的证据。
这两处缺陷都是在用真实资料检验朝鲜范围时暴露出来的。「not north korea」、「def not north korea」与「Seoul, Korea (not DPRK)」这类所在地此前一律返回高置信度命中：资料中提到该国，恰恰是为了与之划清界限，而政策却把它记为自行声明。现在否认会被计入——但仅限于它与命中相邻之处；「No. 5 Lenin St, Moscow, Russia」依然声明俄罗斯，并未收回任何内容。
第二处缺陷属于结构性问题。随附的地名库只收录俄罗斯、伊朗和朝鲜的地名，因此命中旁边的外国城市是不可见的，命中便被读作无可辩驳：「Seoul, North Korea」与「New Dehli / Beijing / Hong Kong / Pyongyang」都被判为高置信度。政策范围之外的首都、大城市与技术中心现在会使所在地变得含糊——这与外国国名此前的作用完全一致 ——而美国州名现在适用于每一个政策国家，而不再只针对俄罗斯。
发布前在全部记录上测得：358 个高置信度所在地中有两个发生变化——其一为「London, Munich, St. Petersburg」，那是办公地点清单而非声明，其二为「Amsterdam, Netherlands / Leningrad, Russia」。仅有一个仓库失去红旗。此变更之下评分只会上升。
2.1.0 — 2026-08-02
响应性新增“新人 PR 接受”组成部分（权重 13）。在最近 30 天内得到裁决、且其作者此前在该仓库没有任何已合并拉取请求的拉取请求中，该组成部分衡量被合并的比例。由自动化账号提交的拉取请求在计数之前即被排除。两个全生命周期组成部分重新配权以腾出空间——议题解决 46.75 → 42、 PR 接受 38.25 → 30——OpenSSF Scorecard 的 Code-Review 组成部分维持 15 分。
既有的 PR 接受率是全生命周期比率，在成熟项目中几乎不会移动：一个拥有数千个已合并拉取请求的仓库，无论当下如何行事，一年之内也无法改变它。它同样无法区分两类项目：一类迅速合并常规贡献者的工作，另一类则不接纳这个圈子之外的任何贡献。这两个比率分化的情形足够常见，因而只有后者才描述了首次贡献者应当预期的情况。
当窗口内没有任何新人的拉取请求得到裁决时，该组成部分被排除，指标其余权重重新归一化。无人叩门与无人获准进入并非同一事实，而只有后者出于项目自身的作为。分母是新人已裁决的拉取请求，而非其在全部合并中所占的份额，因此一个由常规贡献者完成大部分工作的成熟项目，不会因为拥有常规贡献者而被扣分。
相关证据在扫描过程中采集，因此仅出现在本版本之后生成的报告中。此前的报告缺少该项输入，会在不含它的情况下重新归一化；这一变更因而随仓库的重新扫描逐步生效，而非一次性作用于整个记录。在该组成部分存在之处，分值可能向任一方向移动。
社区健康度记录 README 的状态徽章，但不计分。README 显示多少枚徽章、来自哪些服务，现已作为不带权重的观察项载入报告。徽章所宣称的每一项事实——CI 在运行、存在测试覆盖率、已发布版本——均已直接在仓库上测得，而徽章不过是一行 Markdown，没有任何机制核验它指向的正是它所在的项目。
2.0.0 — 2026-08-02
对分值量表本身的第一次重大修订，由三个相互关联的部分组成。整个记录已在此版本下重新计分；此版本前后公布的分值不可逐分比较——跨越这一边界时，比较的单位是等级，而不是分值。
总指数依据公开记录进行校准。类别加权平均对 1–100 量程的利用很差：在全部 47,516 个已检验仓库上测得，一半的记录落在 50 与 69 之间，开源软件的前十分之一也只达到 70 分代后段，量表的大部分区间什么也区分不了。公布的指数现在对原始加权平均应用一条固定的单调曲线——锚定于某个注明日期的快照上记录经验分布的选定百分位。等级由此具有百分位含义，而原始平均保留在每份报告中（overall.inputs.weighted_overall_raw）以供审计。该曲线是本版本的常量，而非实时百分位：分值只随仓库自身证据的变化而移动。曲线在量表顶端饱和——原始平均达到 91 及以上即公布为 100——因为高于这条线的最后几个原始分值区分不出任何读者应当据以行动的东西。类别与指标数值按未校准的形式公布。
五个等级变为七个。薄弱（35–49）现位于存在风险与中等之间， 卓越（93–100）位于优秀之上。新阈值为：危急 1–19、存在风险 20–34、薄弱 35–49、中等 50–64、良好 65–79、优秀 80–92、卓越 93–100——如此选定，使校准后的各等级把记录切分为规模相当的群体，而在旧划分下仅中等一档就占了记录的约一半。每个等级还配有一个字母评级，从 C 到 AAA。风险警示的上限随其命名的等级一同移动：高风险司法辖区与疑似弃置的上限现为 34（存在风险的顶端，此前为 49），恶意依赖与已声明弃置的上限为 19（危急的顶端，此前为 29），且作用于总体分的政策现在作用于校准后的指数，因此报告所陈述的上限就是页面显示的数字。
AI 就绪度以 4% 计入加权平均。该类别自引入以来一直按权重 0 测量并公布；代理工具链此后已成为一项寻常的维护信号，现在承载真实的 ——刻意设小的——权重。其余类别各让出一分：可持续性与治理 23%、活力 21%、工程质量 19%、社区与采用 17%、安全 16%（未变）。该权重与校准曲线的饱和点一同定尺，使没有任何 AI 就绪度信号的仓库仍能达到 100/100——该类别可以推动指数，绝不封住量表的顶端。
1.14.0 — 2026-08-02
高风险司法辖区政策现在要求贡献者侧的命中具有提交权重才会触发红旗：至少 50 次提交，或至少占抽样人类提交的 10%。所有者命中不受影响。
此前的规则只要显示的主要贡献者中出现任何高置信度所在地命中，就会标记仓库，无论其贡献多小。在生产记录上测得：1,763 个仓库带有该红旗，其中仅 199 个源自所有者账户；其余仓库中，56% 依据的是提交不足十次的贡献者，70% 依据的是占项目提交历史不到 5% 的贡献者。一些广泛使用的项目仅因单个低排名、约占历史 1% 的贡献者而被标记。对偶发贡献者的所在地命中属于信息披露，而非风险敞口，据此触发的红旗无法告诉审查者是谁在实际维护这份软件。
低于两项阈值的命中仍以记录形式保留在报告中，仅供审查；不触发红旗，也不移动任何评分。此变更只会使评分上升，且仅限红旗完全依赖低于阈值命中的仓库。阈值公布在每份报告中，规则所读取的提交计数此前已在采集范围内，因此既有报告无需重新扫描即可重新评分。
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
初始方法论。
版本管理保证什么
- 可复现性——报告记录输入数据和方法论版本，相应的评分实现已经公开。贡献者资料适用文档所述的隐私例外。
- 可比较性——在同一版本下接受检验的两个仓库，依据完全相同的规则度量。
- 可问责性——方法论变更公开、注明日期并附有说明；不存在无声的调整。