【免费下载链接】publicationsPublications from Trail of Bits项目地址https://gitcode.com/GitHub_Trending/pu/publications点击查看免费下载本文基于 Trail of Bits 开源出版物仓库中收录的 SigstoreCon 2024 演讲《The Next 5 Years of Supply Chain Security on PyPI》演讲者William WoodruffREADME、slides.pdf展开。PyPI 在过去五年密集引入了 scoped API tokens、安全事件告警、强制 MFA、Trusted Publishing 以及 PEP 740 包级加密证明attestations等一系列机制本文将完整梳理这套演进时间线解释每个机制解决了什么威胁并重点解析演讲提出的三大五年目标——扩展 attestation 的广度与深度、把验证能力下沉到pip等下游用户工具、以及建立 Gosumdb风格的索引级二元透明binary transparency帮助读者理解 Python 打包生态供应链安全的现状、瓶颈与演进方向。背景PyPI 不是一个工具而是一整套标准驱动的生态理解下一个五年的规划先要理解 PyPI 和 Python 打包生态的基本盘。演讲给出的关键事实截至 2024 年 11 月PyPI读作 Pie-pea-eye是pip install背后的官方包索引规模约为 86 万用户、57.5 万项目、610 万 releases、1220 万文件每月下载量约 510 亿次日均流量超过 2TB演讲指出这部分数字因大量工具和大型 CI/CD 提供商缓存不足而有所虚高。PyPI 只是 Python 打包星丛constellation中的一块拼图其余部件包括安装器installerspip、uv、poetry等构建工具与后端build tools and backendssetuptools、hatch、flit、poetry等上传工具upload toolstwine、uv、poetry等。很少有单一工具能覆盖全部环节尽管正在缓慢变化。更关键的是 Python 打包是标准驱动的Python Enhancement ProposalsPEPs一旦被接受就成为 PyPAPython Packaging Authority的活标准。这与 Rustcargo和 JavaScriptnpm的自顶向下、由官方工具主导的模式不同。Python 社区庞大且高度多元——经验、背景、兴趣、技能、投入时间的各种组合并存为生态找到一个安全问题的公共分母本身就极其困难。演讲者甚至类比这个生态更接近一个国家甚至多个国家而非其他软件生态。方法论把安全问题当作可用性问题解决这是整场演讲的立论基础也是理解后续所有机制设计取舍的钥匙Python 生态的多元性既是其优势也是系统性安全变革的挑战缺乏系统性规划会自我强化——因为任何新的系统性方案都必须兼容既有约定与期望另一方面激进的系统性规划会伤害生态健康惩罚性的安全要求onerous security requirements会把新人吓跑。由此得出的核心结论是要让打包安全取得系统性进展必须把安全当作一个可用性问题usability problem来解决。社区可以分成两个人群爱好者enthusiasts占 1%5%会主动采用新事物。好消息是大多数头部包由这个人群维护坏消息是他们在全部包维护者中占比极小。其余所有人占 95%99%只关心自己工作流的可靠性除非安全变更让他们的工作流更容易否则不会接受要求显著行为改变的新机制。好消息是一旦真的变简单了他们会欣然采用。这解释了为什么 PyPI 近几年的标志性进展——Trusted Publishing 和 PEP 740——都被刻意设计为默认开启、零额外配置的形式。过去PyPI 打包安全的演进时间线演讲回顾了从 2003 年至今的关键节点这条时间线值得完整保留因为它展示了把安全当可用性问题策略的实际落地路径时间事件2003 年前后PyPI 诞生更非正式的前身打包方式可追溯到 1998 年2005PyPI 开始直接托管文件此前只是指向其他托管方的索引早期是 HTTP 跳转随机服务器2013 年前后PyPI 引入 HTTPS对 Web 用户强制、对pip和easy_install默认启用2015PEP 503 标准化索引 API包含文件摘要 digestsPEP 470 正式弃用外部托管并移除残留外链2017PyPI 重写从 legacy PyPI 迁移到 Warehouse2018现行 PyPI 后端Warehouse正式上线2019PyPI 实现并启用 MFATOTP WebAuthn 物理密钥实现 API tokens含项目级 scoping与用户名/密码并列为上传凭证2020首次尝试引入 TUFPEP 458启动恶意软件检测/扫描的初次尝试2022对关键critical项目强制 MFA向指定项目免费发放 WebAuthn 令牌2023Trusted Publishing 上线补充complement手动 API tokens2024-01-01所有项目强制 MFA同时强制上传必须使用 API tokens 或 Trusted Publishing两个值得注意的弯路2020 年基于 PEP 458TUF的索引签名方案最终未能在 PyPI 落地后来被 PEP 740 路线取代以及 PyPI 早期 PGP 签名上传的失败——后者在仓库中的 die, PGP, die 演讲中有专门论述PGP 的设计、工具与信任模型的固有缺陷使它不适用于大规模现代生态的代码签名。当前与进行中的工作Verified Project URLs让冒充更难Verified的含义是PyPI 能够交叉佐证这个 URL其 ground truth 来源正是 Trusted Publishing 配置。效果是typosquattertyposquatting 攻击者等冒充者即使提交内容恶意但链接看起来很真的项目也难以通过验证。演讲将其影响概括为打击所谓 starjacking 类伪装。PEP 740 Attestations在 Trusted Publishing 之上自举包签名这是演讲的核心现态。要点Trusted Publishing 的巨大成功本身就是可用性与安全性的双赢因为它把配置长期 API token这个高危环节替换为基于 OIDC 的临时凭证该机制的完整背景可参见仓库中 Securing your Package Ecosystem with Trusted Publishing 与 Trusted Publishing: Lessons from PyPI 两篇演讲摘要PEP 740 在 Trusted Publishing 之上自举bootstrap包签名因为签名身份直接复用 Trusted Publisher它默认覆盖了约 2 万个发布工作流且不需要任何额外配置底层构建在 Sigstore 之上没有长期签名密钥只有机器身份Sigstore 模型在 Python 生态的早期介绍见 Ergonomic Codesigning for the Python Ecosystem with Sigstore在演讲时点2024 年 11 月该功能已在 PyPI 上线约两个月。Attestations 到底提供了什么可公开验证的包来源证明provenance语义上等价于这句话包 foo 版本 1.2.3 由 GitHub 仓库 foo/foo 通过工作流 pypi.yml、在 commit cafe… 时构建产出对索引与各个发布者的外部透明性与可审计性每条 attestation 都有对应的 transparency log 条目可被审计审查以及一个可被主动监控proactively monitored的对应机器身份。这使得攻击者即使成功入侵了某个包或其仓库也难以悄悄得逞演讲者同时保持克制这不是万能的因为 attestations不是也不可能是强制的。上线两周的采用情况PyPI 上已接收 10,000 条 attestations360 个头部项目中 18 个5%上传了 attestations考虑到其中约三分之二在项目启用该功能后才首次上传也可以按 15% 解读对仅启用两周而言这是不错的数字。未来五年三个目标目标 #1扩展 attestations 的广度与深度breadth/depth按 PEP 740 的定义attestations 是刻意受限的MVP 取向只有 Trusted Publisher 可以用作签名身份attestation 谓词predicate刻意限定为 SLSA attestation 和 PyPI publish attestation 两类。未来要扩展的方向更多 attestation 类型VSAVerifiable Security Attestations安全属性证明第三方 attestation例如该包已被某方审计评审更多签名身份邮箱身份——PyPI 已经知道哪些邮箱地址完成过验证天然可用作身份域名身份也有可能。README 摘要中还提到一类值得注意的设想counter attestations——类似 PEP 740 但由审计者和社区成员发起允许他们以密码学方式登记自己对某个 PyPI 包的信任把信任本身也变成可验证的链式记录。目标 #2把验证能力带给下游用户演讲对此的论述最为具体也暴露了当前最大的工程瓶颈签名是容易的部分验证才是难的。索引即 PyPI在上传时验证 attestations 是可控的但让pip这类用户侧代理做验证要难得多架构约束pip出于 vendoring把依赖直接内置分发的历史传统原因必须是纯 Python 的而 Sigstore 的 Python 客户端sigstore-python不是纯 Python——它经由 PyCAcryptography使用 Rust 实现。这直接阻碍了pip内置验证能力标准与工具缺失缺少标准 lockfile 格式使得面向用户的 TOFUTrust On First Use首次信任后锁定验证故事难以展开——必须先有一种方式锁定某个包预期由哪些签名身份签发。README 摘要把这个问题进一步展开为两条具体路线通过 lockfiles 实现 TOFU 风格的身份锁定可能结合 Python 的 PEP 751即包元数据中引入 URL 规范化/锁定方向的提案以及为 PEP 740 attestations 构建可扩展的见证witnessing与监控体系包括用 rollup 技术降低pip这类纯 Python 安装器的集成负担。此外摘要还提到使用 TUF 分发复杂的身份策略——把哪些身份对哪些包有效这类策略从工具代码中抽离出来、以 TUF 的元数据框架分发与更新。目标 #3索引级透明index-level transparencyAttestations 有根本性的作用域局限不是所有人都用或能用Trusted Publishing——这没问题但意味着总存在覆盖盲区用分散在用户侧的逐包 attestation 做全索引监控几乎不可能需要监控的签名身份数量是无界的attestations 并不能降低对索引本身的信任——PyPI 依然是高价值攻击目标这一点在 Imagining a zero-trust future for PyPI 演讲中有更系统的零信任未来推演。演讲的结论是我们需要无条件的透明性与真实性属性——即 PyPI 的二元透明binary transparency先例prior artGo 的sumdb、npm 的 publish attestations演讲指出后者与 PyPI 的做法方向相反理想的客户端性质验证成本 1 条或数条ECC 签名验证 1 次成员证明inclusion proof检查对pip这种纯 Python 安装器是可承受的但代价同样明显它需要一套监控与见证witnessing生态而对这类生态能长期健康运行的公开证据还很薄弱evidence for these is scant。愿景小结今天有什么明天要什么演讲的收尾the dream把现状与目标压缩成一张对照表今天已经拥有抗误用misuse-resistant的凭证 默认开启的发布 attestation——这是 Trusted Publishing 基于 Sigstore 的索引 attestationPEP 740共同带来的。明天想要Attestations 的下游验证——今天技术上已可行但官方包工具链尚未支持上游维护者对发布身份的监控——今天已可行但体验不佳Sigstore 需要一个CI 版 Cert Spotter证书透明度日志监控工具级别的能力索引级透明 健康的见证网络——需要大量设计思考且明确向社区发出邀请you can help!。最终的终极目标用演讲自己的话表达是能够说出这样的句子when i download sampleproject v4.0.0, i know that it came from the repository its supposed to come from and that PyPI served the same file to me as everyone else.当我下载 sampleproject v4.0.0 时我知道它来自它本应来自的仓库且 PyPI 发给我和大家的是同一个文件。这句话精确概括了整条技术路线的终点provenance 由 attestation 保证一致性由透明日志保证验证成本被压缩到纯 Python 工具可以承担的量级。延伸阅读仓库内同一作者的相关演讲本仓库Trail of Bits publications中收录了 William Woodruff 围绕同一主题、不同阶段的完整演讲序列可作为本文各章节的深入阅读材料PEP 740 and PyPI: Bootstrapping Provenance for the Python EcosystemSOSS Fusion 2024PEP 740 与 Sigstore、in-toto、SLSA 的集成细节以及如何在 Trusted Publishing 之上完成 provenance 自举Attestations: a new generation of signatures on PyPIPyCon US 2025attestations 的架构细节、上传侧实现、安全属性与透明性以及大规模验证这一缺口的现状Securing your Package Ecosystem with Trusted PublishingPackagingCon 2023与 Trusted Publishing: Lessons from PyPIPackagingCon 2023OIDC 临时凭证方案的安全性性质、PyPI 实现细节、多 IdP 支持与威胁模型What does it look like to code-sign for an entire packaging ecosystem?ACM SCORED 2023整生态代码签名的工程与现实考量维护者运维负担、匿名生态中的身份隐私问题Ergonomic Codesigning for the Python Ecosystem with SigstorePyCon 2023Sigstore 安全模型对 Python 开发者的入门die, PGP, dieSummerCon 2022为什么 PGP 路线走不通是现代 attestation 路线的对照面。最后重申适用边界本文所有规模数据下载量、项目数、attestation 采用率等均为演讲时点2024 年 11 月功能上线约两周的快照未来五年部分是演讲者的个人意见演讲原文注明 disclaimer: my opinions代表对生态演进方向的判断而非已确定的路线图涉及 PEP 751、VSA、rollup、TUF 身份策略等内容同样属于设想阶段落地形态以 PyPA 与 Sigstore 社区的后续标准工作为准。赞分享【免费下载链接】publicationsPublications from Trail of Bits项目地址https://gitcode.com/GitHub_Trending/pu/publications点击查看免费下载相关推荐解读 PyPI 新一代签名方案PEP 740 数字证明Attestations的架构、实现与未来解读 PyPI 新一代签名方案PEP 740 数字证明Attestations的架构、实现与未来 本文基于 Trail of Bits 公开出版物仓库中的Cognee 供应链安全实战PEP 740、SLSA 与 SBOM 三级制品溯源与发布验证指南Cognee 供应链安全实战PEP 740、SLSA 与 SBOM 三级制品溯源与发布验证指南 本文以 supply_chain_provenance.md人工智能AI AgentRAG知识图谱后端MCP 服务ZeroClaw 发布供应链安全基于 GitHub Artifact Attestations 的 SLSA v1.0 Build Level 2 来源证明实践ZeroClaw 发布供应链安全基于 GitHub Artifact Attestations 的 SLSA v1.0 Build Level 2 来源证明实人工智能AI Agent交互助手工具调用MCP Clients本地部署Agent 工作流RAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
