PyPI 推出“双人审核”当技术防线被绕过行业开始用流程筑墙《AI视界——从资讯看技术》专栏 · 第二十五期双因素认证被绕过之后Python 软件基金会没有选择更复杂的技术方案而是选择了一个更简单的流程方案。这件事背后是运维安全防线的一次思路转变。本系列专栏其他文章欢迎访问AI视界——从资讯看技术我的主页AOwhisky这里有更多运维系统性知识整理和其他有趣内容欢迎与我一起探讨学习~一、攻击之后行业如何回应本专栏的第五期我们聊过 PyPI 供应链攻击的三种手法。第二十期我们聊了攻击升级——社会工程学手段绕过了双因素认证恶意包被堂而皇之地发布到了官方仓库。那期的结尾我们提了一个问题行业怎么回应现在回应来了。Python 软件基金会宣布启动“双人审核”试点计划。核心规则很简单下载量超过一定阈值的包新版本发布需要另一位维护者审核确认后才能上线。这不是一个技术升级。这是一个流程升级。在双因素认证被绕过的背景下这个回应传递了一个微妙但重要的信号当技术防线被突破行业没有选择在技术上加更多的锁而是选择在流程上增加人的制约。这期我们拆解一下双人审核要解决什么问题它和我们专栏一直在聊的运维安全有什么关联二、双人审核到底要挡住什么先理解这个试点计划的细节。触发条件包的下载量超过一定阈值——官方没有公布具体数字但显然是针对那些“一旦被投毒、影响巨大”的高关注度包。审核机制维护者提交新版本后需要另一位已认证的维护者审核通过新版本才会在 PyPI 上正式发布。覆盖范围目前是试点只覆盖部分高下载量包。未来可能根据效果扩展。这个机制要挡住的是哪类攻击回顾第二十期那起事件攻击者通过社会工程学拿到了维护者的账号密码和2FA验证码。因为2FA认证通过系统认为操作者是合法的维护者直接放行了恶意包的发布。如果当时有双人审核攻击者拿到一个维护者的凭证还不够——他需要同时拿到两个维护者的凭证或者第二个维护者恰好粗心大意通过了恶意包的审核。双人审核不是让攻击变得不可能而是让攻击的成本翻倍、风险翻倍。两个人同时犯错的概率远低于一个人被骗的概率。三、为什么不是更复杂的技术方案双人审核试点公布后社区有一种声音“为什么不用更高级的技术方案比如代码签名强制验证、构建溯源链、发布前的自动化安全扫描”这些技术方案不是没用而是各有盲区。代码签名可以验证包的来源但签名密钥本身也可能被窃取——和第二十期的2FA绕过是同类问题。自动化安全扫描可以发现已知漏洞模式但对新型恶意代码的检测能力有限——和第十七期我们聊的AI代码审查是一个道理。在这个背景下双人审核的思路其实是务实的既然技术方案各自都有盲区那就在流程上加一层人与人之间的制约。这和我们第十期聊 Cloudflare 宕机事故的结论一致自动化流程中必须有人的硬阻断点。PyPI 的双人审核本质上就是在包发布这个关键环节上增加了一个硬阻断点。四、从技术防御到流程防御第五期我们聊供应链攻击时提了三道防线私有镜像源、依赖锁定与哈希校验、CI/CD 安全扫描。第二十期我们增加了第四道零信任依赖管理。现在回头看这些防线大部分是技术层面的。双人审核代表了一个新维度流程防御。技术防线解决的是“攻击者能不能突破系统”。流程防线解决的是“即使系统被突破还有一道需要人协作才能跨过的门”。对于运维来说这个思路可以迁移到很多场景。变更管理高危操作不能一个人完成——一个人提交、另一个人审批。应急操作也不能跳流程——紧急变更也需要事后复核。权限管理上关键系统的管理员权限不能集中在一个人手里。技术越自动化流程中人的制约点越重要。这个判断从第一期到第二十五期我们变着角度说了很多次。PyPI 双人审核是行业用行动给这句话投了赞成票。一期一会 · 本期核心笔记Python 软件基金会推出“双人审核”试点高下载量包的新版本发布需要另一位维护者审核确认后才能上线。这是对供应链攻击的流程层面回应——当技术防线被绕过行业开始在流程上增加人的制约。双人审核的核心理念是两个人同时犯错的概率远低于一个人。这个原则可以迁移到运维的变更管理、权限管理和应急操作中。这一期是安全话题线的“攻防闭环”。从第五期的攻击手法到第二十期的攻击升级到这期的行业回应——整条线走完了一个完整周期。但安全不是运维的全部。当安全防线逐渐完善运维的另一个核心命题——效率——正在被 AI 重新定义。下一期我们聊 OpenAI 和 Oracle 的多云合作深化当 AI 巨头都在搞多云运维的多云管理还远吗这是《AI视界——从资讯看技术》的第二十五期。二十五期了感谢还在。我们继续。如果这篇文章让你有所思考欢迎在评论区聊聊你的团队里高危操作的“双人审核”是强制执行的还是只停留在纸面上— Compiled and Authored by Whisky — Augest 3 rd, 2026