Python 官方包索引 PyPI 正式上线了重构后的项目详情页，最核心的变化是新增了独立的 Security（安全）标签页，把此前藏在底层元数据里的数字签名与出处凭证（Provenance）直接摆到了开发者眼前。这并非一次简单的视觉美化，而是开源软件供应链防御逻辑的一次主动纠偏：PyPI 试图用一套极其克制的界面语言，把“这个包是谁构建的”讲清楚，同时戳破开发者长期以来“有官方认证图标就代表代码无毒”的虚假安全感。
为什么三分之一的开发者看不懂安全信号
PyPI 早在 2024 年就引入了数字凭证（Digital Attestations），用来记录发布文件的来源，并在 2026 年 7 月启动界面重构。但密码学机制落到真实开发场景里，很快就撞上了认知高墙。在 PyPI 官方 Warehouse 仓库 Issue #20111 披露的用户调研中，受访的 6 位社区开发者里有 2 位（占比三分之一）根本不理解 Provenance 这个词的含义；更危险的是，有 2 位受访者直接把旧版界面上的 Verified by PyPI 标签，误解为“PyPI 官方已经对这些代码做过安全审计”。
这种误读比没有安全机制更可怕。攻击者只要注册合法账号、走完自动化构建流程，就能拿到相同的验证标签，而下游开发者却因为看到绿色勾号而放下了戒心。为了拆掉这个认知雷区，PyPI 在 OpenSSF（开源安全基金会）资助下联合设计机构 Kabu Creative 重构了界面，并成为全球首个全面落地《OpenSSF 凭证 UI/UX 样式指南》且达到最高 Level AAA 标准的软件包注册表。
新版界面砍掉了原本按“是否验证”来堆砌元数据的做法，改为按实用性排序，并将数据明确区分为用户自行填写的 PyPI data 和平台核验的 Data verified by PyPI。对于没有凭证的历史版本或未配置项目，页面会显示 No Provenance，但官方特意在文案中强调：无凭证不代表软件包有恶意，仅代表文件来源无法通过密码学验证。
抓出账号劫持的四个黄色叹号
理解新版 Security 标签页的关键，是看懂它如何把原本黑盒的发布过程拆成两条公开证据链。一个拿到 Full Provenance（完整出处凭证）状态的发布版本，意味着该版本下 100% 的文件都带有数字凭证，通常包含两类信息：第一类是 PyPI Publish 凭证，证明文件确实由预设的可信发布者（Trusted Publisher）上传，而非通过容易泄露的个人 API Token 手动提交；第二类是 SLSA Build Provenance 构建凭证，直接将二进制文件或源码包死死锚定到具体的 GitHub 或 GitLab 源码提交记录（Commit）、构建平台和构建指令上。
溯源凭证只证明包裹从哪条流水线发出，不保证盒子里装的不是毒药。
真正给企业安全团队和日常开发者省时间的，是当这根证据链出现裂缝时，PyPI 直接顶在页面最上方的四类出处警告（Provenance Warnings）：
| 警告类型 | 触发条件 | 现实场景与潜在风险 |
|---|---|---|
| Incomplete（不完整） | 同版本仅部分文件有凭证 | 如 Wheel 包走 CI 自动发布，源码包却用本地 API Token 手动补传，存在单点篡改风险 |
| Inconsistent（不一致） | 同版本文件来自不同构建源 | 同一批文件由不同的代码仓库或 CI 系统编译打包，极可能是构建环境遭入侵 |
| Change（出处变更） | 仓库或工作流与历史版本不同 | 可能是正常的项目迁移或组织改名，也可能是维护者账号被劫持后指向了恶意仓库 |
| Loss（凭证丢失） | 曾有凭证的项目突然变成无凭证 | 维护者意外改回 API Token 手动上传，或攻击者拿到权限后绕过受控流水线直接投毒 |
除了这四道防线，新版 Release files（发布文件）标签页还对 2026 年 7 月新规生效前的历史版本增加了“延迟上传文件”橙色警告——只要某个文件是在版本首次发布 14 天后才补传的，就会被单独标出（2026 年 7 月后 PyPI 已直接禁止超过 14 天的版本追加新文件）。如果某个版本因为确认恶意而被官方隔离（Quarantined），隔离横幅会直接压过所有其他警告独占页面顶部。
- 提醒.即便一个软件包显示 Full Provenance 且没有任何警告，也只说明它完整走完了维护者设定的自动化构建流程；如果维护者本人在源码里写了恶意逻辑，或者上游依赖被投毒，密码学凭证不会报警。
5 万个项目入局之后，供应链防御卡在哪
将密码学凭证做成基础设施，最难的从来不是定标准，而是让整个生态愿意用。从官方披露的底盘数据来看，这套机制已经度过了冷启动期：截至 2025 年 12 月 31 日，PyPI 上接入可信发布者（Trusted Publishing）的项目数量已经突破 50,000 个；在整个 2025 日历年中，PyPI 平台上有超过 20% 的文件上传是通过可信发布者完成的，其中 17% 的上传文件附带了数字凭证。
如果把视野拉到更核心的头部开源项目，采纳速度还在加快，但与其他语言生态相比仍有身位差。安全研究机构 EasyxLab 在 2026 年 10 月发布的抽样研究草案中测算，在 14,995 个热门 PyPI 项目里，有 23.2% 的最新版本已经包含了出处凭证；而在同样被高频攻击的前 1,000 个热门 npm（JavaScript）项目中，包含出处凭证的比例已经达到 30.8%。
这里还藏着一个单看新闻通稿极易忽略的口径落差：第三方学术研究在统计“已凭证包”时，通常只要一个版本里“至少有一个文件带凭证”就算达标；但 PyPI 这次上线的网页端极其严苛，必须 100% 的发布文件都带凭证才会给 Full Provenance 标识，哪怕漏掉一个源码压缩包，也会直接降级并弹出黄色的 Incomplete Provenance 警告。这意味着很多习惯在 GitHub Actions 里自动构建二进制 Wheel 包、但习惯在本地用命令行手动补传 .tar.gz 源码包的开源维护者，如果不统一自己的发布工作流，项目主页顶部就会常年挂着安全警告。
对于开源维护者来说，把本地打包工具（如 Flit、Hatch、Twine）全部迁入支持自动生成凭证的 CI 流水线，已经从“加分项”变成了避免被下游用户质疑的“必选项”。而对于每天都在执行 pip install 的一线开发者和企业 DevSecOps 团队，网页端变清楚只是第一步——毕竟绝大多数依赖安装都发生在终端黑框和自动化容器里，没人会在安装几百个传递依赖前逐个去刷网页。接下来真正决定这套安全信号能不能拦住投毒攻击的变量，是 pip、uv 等主流命令行包管理工具何时能把这四类出处警告直接集成进终端安装拦截策略中。