OSPS Baseline 声明必须带版本、级别与日期

摘要

问题可以从一张很普通的表格开始。采购人员看到某个依赖项旁边亮着绿格：“OSPS compliant”。这四个字很容易被排序、筛选，再复制进风险报告；但它们没有说明依据哪一版文本、适用哪一级要求、何时完成评估，也没有说清检查的是主仓库、全部子项目、构建系统，还是某个具体发布物。

OSPS Baseline 自己已经给出了补全办法。官网把 v2026.08.28 标为新符合工作应使用的当前版本，同时保留历史版本，并把开发中版本另列。FAQ 说明项目可以自行声明符合情况，又把这种符合状态称为“时间点状态”，建议声明同时写明截至日期、Baseline 版本与级别。

维护流程使用 YYYY-MM-DD 日历式版本号，历史版本原则上保持稳定。控制含义发生实质变化时会获得新标识；但较小改动，包括控制在不同级别之间移动，不一定更换标识。因此，只保存一个 OSPS-… 控制编号并不能永远还原当时的要求。声明必须指向冻结版本，证据也必须按那一版解释。

级别决定控制集合。2026.08.28 版把 Level 1 用于任何代码或非代码项目；Level 2 面向至少有两名维护者、拥有少量稳定用户的代码项目；Level 3 面向拥有大量稳定用户的代码项目。若只写“符合 Baseline”，选择适用控制的成熟度边界就消失了。

日期约束证据的寿命。维护者权限会调整，分支保护会被编辑，发布渠道会迁移，安全联系人会失效，签名清单可能只覆盖一次发布。旧评估不会因为表格一直保留绿色就自动成为今天的事实。

范围则让前三个坐标真正可用。一个项目名可能覆盖主仓库、插件、文档、包注册表、构建基础设施和多个维护分支。OSPS 控制所指的主体并不总是相同：有时是项目，有时是权威仓库、版本控制系统、流水线或正式发布物。证据必须跟随控制语句里的主体，不能用主仓库的一次观察替全部表面作答。

自我声明不是独立审计，但也不是无意义的自说自话。它能让维护者披露公共扫描器无法看到的特权设置。FAQ 坦率地区分了公开可观察控制与涉及受限配置的控制，并把选择权交给下游：接受项目声明，或者另行约定验证方式。

因此，记录应明确谁作出声明、凭什么权限作出声明，以及证据位于何种可见边界。安全政策、贡献指南、仓库历史或发布清单可以公开；权限配置可由基金会、资助方或客户在保密条件下查验。“已验证”只有在同时写出验证者、方法、对象和时间时才有信息量。没有公开链接既不应自动算通过，也不应自动算失败。

外部框架映射同样不能越界。2026.08.28 版说明，这些映射只是参考，并不保证完全匹配，也不构成功能连接。FAQ 更明确指出，映射不代表符合所列外部目录，不能替代审计或正式认证。不能用一次表格关联把 OSPS 声明放大成 NIST、ISO 或监管合规。

一份紧凑的 Baseline 声明凭据应包含：项目规范名称；纳入评估的仓库、子项目与发布范围；OSPS 版本和级别；评估日期；声明者及其权限；适用控制清单；每项控制的证据位置与观察时间；受限证据标识；例外和不适用理由；以及触发复核的期限或变更。

它不保证软件没有漏洞，不替用户批准依赖，不认证某个二进制，也不预测部署结果。它完成的是更小但更可靠的工作：让下一位阅读者知道究竟声明了什么、依据哪份文本、覆盖哪个表面、证据可依赖多久。

这样，权责不会混在一起。Baseline 维护者负责发布并版本化共同问题；项目维护者描述自己的控制状态；审阅者可核查特定证据；产品负责人仍决定某一版本是否适合某一使用场景。共同语言提供协调，而不是偷走下游决定权。

那一格绿色仍可保留，但应变成链接：“OSPS v2026.08.28，Level 2，评估于 2026-09-07”。完整凭据在链接之后。简短展示由此成为完整记录的视图，而不是完整记录的替代品。