规范藏进文档，阻断不了供应链投毒
2026 年 11 月 6 日，PyPI 正式上线全站界面改版。这项重构由 OpenSSF（开源安全基金会）资助，并与设计机构 Kabu Creative 联合展开。原本深藏在底层规范里的数字证明（Digital Attestation），被做成了醒目的状态横幅。全新的安全标签页，也首次进入一级入口。
开源生态的供应链安全，长期陷入执行断层的困境。PyPI 早在 2024 年就引入了数字证明，允许维护者将产物与代码仓库关联。然而在日常开发中，极少有工程师会在执行 pip install 前核验签名。缺乏即时可见的反馈，严密的安全规范就会被日常下载普遍忽略。
判断依赖包是否安全，过去高度依赖下载者的自觉排查。开发者既要通读构建文档，还要自行翻阅历史版本。这种繁琐要求脱离了实际工程节奏，也留下了投毒空当。分发平台必须改变策略，把底层密码学证据直接做成界面信号。
安全标签页登场：两档基准切分验证边界
图：项目详情页新增 Security 独立标签页，将包文件的安全与验证信息提到一级入口。来源：PyPI 官方博客。
改版的核心载体，是项目页新增的独立安全标签页（Security tab）。新界面集中展示当前版本的来源证明（provenance）状态，并逐一列出文件详情。平台根据分发文件的证明覆盖率，直接计算出整包的验证基准。
在新模型下，发行版本的基础状态被切分为两档。第一档是完整来源证明（Full provenance），要求该版本 100% 的分发文件均携带有效证明。这涵盖了由 Trusted Publisher 签发的发布证明，以及精确追溯至源码提交的 SLSA 构建证明。
第二档则是无来源证明（No provenance），代表该版本没有任何文件携带来源证明。PyPI 官方在规范中明确强调，无来源证明不等于恶意。它只表示文件来源无法用密码学手段验证。大量历史上线的成熟项目与尚未配置凭据的个人工具，都属于这一档。
明确这一分界线至关重要。若将缺少证明一概标为高危，频繁误报只会让开发者麻木。官方建议在面对无证明项目时，结合维护者资历与仓库活跃度进行综合权衡。平台只呈现事实，将判断的主动权交还给工程团队。
四类警报拉响：盯住流水线构建异动
图：项目页顶部的 Incomplete provenance 警告横幅，提示部分构建文件未包含来源证明。来源：PyPI 官方博客。
除了两档基础状态，PyPI 还在项目页顶部引入了四类异常构建警示横幅。这些警告的核心目标，是捕捉账号遭窃或发布链路被篡改的痕迹。当流水线行为偏离常态时，页面会第一时间给出视觉干预。
第一类是不完整来源证明（Incomplete provenance），指同版本中部分文件具备证明，部分文件缺失。许多团队习惯将 Wheel 包接入 GitHub Actions 自动化发布，却用本地令牌上传源码包（sdist）。缺口就出在这里：用户可以验证 Wheel 的出身，源码包的出身却无法核对。
第二类是不一致来源证明（Inconsistent provenance）。它提示同一版本文件来自不同系统或仓库。第三类则是来源变更（Change of provenance），标明本次发布关联的工作流与上一版本不一致。仓库更名虽然常见，但工作流突变往往预示着权限失窃。
最后一类是来源丢失（Loss of provenance）。它警示此前一直带证明、新版本却突然中断的项目。若无合理解释，官方建议直接质疑该版本。四类警告把隐蔽动作搬上台面，大幅降低了排查门槛。
时限拦截与隔离横幅：平台层收紧高危窗口
图：改版后的发行历史页，版本时间线并排展示文件数、provenance 状态与下架原因。来源：PyPI 官方博客。
针对发行维度的安全治理，文件列表页与发行历史页同样迎来了深度调整。黑客常在首发数周后，利用冷门版本静默追加恶意构建。改版后的时间线列出文件数与状态，对 14 天后补传打上橙色警告。
这项迟交警告目前仅作用于历史遗留版本。自 2026 年 7 月起，PyPI 已经实施了更为严厉的技术限制。系统直接拒绝在首发 14 天后上传任何新文件。从软性警示升级为硬性策略阻断，展现了平台治理高危漏洞的清晰演进。
页面层级的信息展示逻辑也同步做出了收敛。当项目被官方实施隔离（Quarantine）时，所有常规警告自动隐藏。页面只保留唯一的隔离横幅。在紧急时刻，单一警报远比复杂参数有效。
此外，项目元数据的组织架构转为按照实用性排序。每一项信息均标明属于官方验证数据（Data verified by PyPI）或是发布者自填数据（PyPI data）。这种细粒度的区分，打消了以往把作者自填链接当作官方认证的普遍误解。
视觉警示只是前哨，终端拦截才是硬仗
PyPI 将密码学验证搬上网页界面的举措，改变了供应链安全信号的传递效率。然而在评估实际效能时，必须认清界面交互的天然边界。如果安全信号仅仅停留在浏览器视窗内，平台实际上是将审核负担转移给了终端开发者的肉眼。
在现代工业级软件工程中，依赖包的拉取普遍发生在无头环境。持续集成流水线与自动化升级脚本，在执行命令时根本不会请求网页 HTML。页面横幅再醒目，也无法在终端阻止危险安装。
界面信号的价值，是为人工排查提供直观依据。原本繁琐的哈希核验，被简化为扫视即知的状态。但真正的防线，必须下沉到客户端。
当 pip 能直接读取证明并阻断安装时，视觉改造才真正落地。PyPI 把隐蔽的供应链风险推向了台前。开源投毒的阻击战，最终仍要由终端工具链接手。
参考链接：
- PyPI 官方博客界面改版完成公告
- PyPI 官方博客界面更新规划
- OpenSSF 数字证明风格指南
