整理 | 如烟
出品 | 51CTO技术栈（微信号：blog51cto）
Python 已成为世界上最流行的编程语言之一，许多 Web 应用程序都是使用它构建的。然而，随着受欢迎程度的增加，安全风险和漏洞也随之增加。
2023年年初，Python 软件基金会（Python Software Foundation，PSF）宣布了启动为期一年的安全增强计划。6 月，PSF 聘请 Seth Larson 加入 PSF，成为首位常驻安全开发人员（SDIR）。
一、首位驻场安全开发，要做哪些事情
Larson 在 Python 社区中广为人知，并且在他的博客撰写了大量有关 Python 和安全相关的文章。他在博客中表示：“Python 社区是我生活中非常重要的一部分，我很感激有这个难得的回馈机会。我期待与大家合作，构建一个更安全的Python生态系统。”
据 Larson 介绍，SDIR 的工作职责包括：
- 对 PyPI 代码库和基础设施进行安全审计
- 规范并改进 CPython、PyPI 和更广泛的 Python 社区的安全实践
- 解决 CPython 和 PyPI 等 PSF 项目的安全问题，并提高识别和解决未来问题的能力
- 与其他致力于安全改进的贡献者合作，包括PSF 招聘的新PyPI安全工程师
- 建立安全态势指标以显示影响
Larson 作为 PSF 首位驻场安全开发人员，目前提出了哪些有关 Python 的安全问题？又是如何解决的呢？我们从 Larson 的博客中提炼出部分内容，以供参考。
1.Python发行版中的捆绑库漏洞
Python 以其作为“粘合”语言的能力而闻名，这要归功于它的 C API 以及对用 C、C++、Go、Fortran 和 Rust 编写的库的访问。这一特性可能是 Python 广泛流行的原因之一。但Python 的这种“超能力”对供应链安全有一定影响。
发现问题：
PyPI（Python Package Index，Python 软件包仓库）仅托管 Python 发行版，包括源发行版和 Wheel 发行版。
想要利用编译库的 Python 发行版要么需要用户自己安装这些编译库，要么随发行版附带预编译库。必须使用系统包管理器安装已编译的库，然后从源代码编译每个包，这对用户来讲真的很不方便。
二进制Wheel的常见工作流程是并行运行cibuildwheel和auditwheel repair，从而在许多不同的操作系统和架构（manylinux、musllinux、macOS、Windows 等）中构建 wheel，然后使用auditwheel repair，这样需要捆绑的库就会自动捆绑到 wheel 中。
看似操作好像更方便了，但在这个过程中，不断捆绑的库也带来了漏洞风险，特别是当pdftopng包含易受攻击的libpng版本时(在其他库中)。
这些捆绑的库不会出现在requirements.txt或pip freeze中，因此审核工具更难了解正在使用的库和版本。
解决方法：
软件物料清单 (SBOM)可以解决以上问题。通过编程方式了解下载的发行版中包含哪些内容，包括非 Python 组件。如果审核工具可以访问这些 SBOM 以及相关组件的漏洞来源，就可以检查发行版是否不易受到攻击，包括其子组件。
不仅仅是二进制库，pip等软件包还捆绑了大量Python库及其源代码， jupyter-notebook 捆绑了 TypeScript 和 JavaScript。将这些捆绑项目添加到 SBOM 也将有助于工具查找这些捆绑项目的漏洞。
2.Sigstore 签名很混乱
发现问题：
自 Python 3.11.0 版本以来，所有 Python 版本 tarball 均使用 Sigstore 进行签名。
给定 Python 版本（即 3.7、3.8 等）的每个发布经理在 Sigstore 信息页面都有一个身份（电子邮件地址为@python.org）。Sigstore 使用 OpenID Connect，这意味着我们还需要指定一个身份 (IdP) 来验证签名。
图片
据了解，验证签名的说明与工件的签名方式并不一致。我整理了一些简单的脚本，这些脚本尝试根据其签名验证每个 Python 版本工件并发布结果。其中发现了一些问题：
- Ned Deily 和 Łukasz Langa 使用GitHub 的IdP，Pablo Galindo Salgado 和 Thomas Wouters使用 Google 的 IdP。
- 所有签名的 Łukasz 身份都是lukasz@langa.pl，而不是记录在案的lukasz@python.org。
- Python 3.11.4 是使用 Pablo 的正确身份进行签名的，但使用的是 GitHub 的 IdP，而不是 Google 的 IdP。
- Python 3.7.14 是由 Pablo 签署的，但 Ned 是 3.7 的发布经理。
- Python 3.8.14和3.9.14已生成签名，但由于权限问题而无法访问python.org/download。
- Python 3.10.1 和 3.10.7 及以上版本已签名，但 3.10.0 和 3.10.2-3.10.6 未签名。不过这很好，因为只有 3.10.7 及更高版本被记录为已签名。
解决办法：
根据这些发现，发布经理采取了以下步骤，以使签名验证保持一致：
- Ned 以自己的身份退出了 3.7.14 版本。
- Pablo 从 3.11.4 退出了 Google IdP。
- Łukasz 修复了 3.8.14 和 3.9.14 的权限，使签名可用。
- 必须清除 CDN 缓存才能使更新可用。
你可以在对上述数据集中看到状态的变化。此刻需要做的就是在签名上修复 Łukasz 的身份。我还在 Python 的发布工具中打开了一个 PR ，以使 Sigstore 签名与未来 Python 版本的文档保持一致。
3.证书和信任库问题
早在 7 月底，certifi 就发布了关于删除 e-Tugra 根证书的 GHSA 公告。该公告有一个关联的 CVE ID，因此最终应该会进入 PyPA 公告数据库，但自动化无法自动导入它。该问题解决后，pip 能够获得 PR 升级证书到最新版本。
发现问题：
Certifi 是Python生态系统中的一个关键包，由于Python的ssl模块与 OpenSSL 库的紧密联系，它是配置 SSLContext 实例的最常见方式。
每当根 CA 出现安全问题时，在 pip 中使用 certifi 的后果（特别是由于捆绑）会导致一系列问题：
- Mozilla Root CA Bundle 中发生删除。
- Certifi 捆绑了 Mozilla Root CA Bundle，需要更新、咨询和新版本的 certifi。
- Pip 捆绑了 certifi，需要新版本的 pip。
- 新的 pip 版本需要发布get-pip。
- Python 捆绑了 pip 的默认版本，并且最好捆绑不易受任何 CVE 攻击的 pip 版本（但用户可以修复此问题）。
每当 certifi 中删除 CA 时，此更新链都会导致大量混乱，并且不考虑单个应用程序锁定文件中需要发生的所有升级。
解决办法：
Truststore 是我和 David Glick 编写的一个库，可以通过使用系统信任存储而不是硬编码捆绑来消除对证书的需求，这样一来保持信任存储的责任就在系统本身上（对于 macOS 和Windows 可以在后台自动更新）。
由于PDM通过 pdm[truststore]或pdm[all]安装时采用了该库，Truststore 最近收到了大量消极用户。如果安装了 truststore，则会自动使用代码路径，这意味着我们可以确保该库按预期工作，适用于各种应用配置。我一直在监控 PDM 的问题跟踪器中是否存在与信任库相关的问题，到目前为止，每天安装大约 2,000 次后还没有出现任何问题。
如果已经安装了信任库，pip 目前支持使用信任库，并且我有一个出色的 PR，可以向 pip 添加信任库支持，而无需单独安装该库。
下面是直接依赖于 certifi 的项目列表（按下载量排序），这些项目也可能是从 certifi 切换到 truststore 的备选方式，但不存在与 pip 相同的捆绑证书问题：
图片
该列表是根据 pypi-data 数据集上的以下 SQL 查询生成的。
图片
我希望能够放弃 certifi，以减少使用 PyPI 作为 CA 分发渠道所产生的流失量。
二、三个关键“原则”
在 9 月份的演讲中，Larson 强调了他作为 PSF 驻场安全开发人员工作的三个“指导原则”：可持续性、清晰度和可见性。
“可持续性”意味着要专注于产生持久的影响，包括改进流程、自动化、处理官僚主义或发布标准。全职意味着有一个宝贵的机会进行改进，这需要一致和长期的承诺，例如与外部组织合作、跟上新标准以及向其他开源生态系统安全人员倡导 Python 的观点。开展这项工作并提供成果应该有助于解锁进一步的下游改进，而不会给志愿者带来时间负担。
“清晰度”：开源软件安全领域一直在经历新举措、新技术以及爆炸式增长。随着新安全工具的不断出现，Larson 努力保持思路清晰，从而找出最适合 Python 生态系统的方法。
“但我一个人做不到！开源领域有很多专家，他们比我更了解他们感兴趣的领域。我们可以互相学习。”
“可见性”：这个角色所做的大部分工作都将公开完成，Larson将通过博客文章和公告的形式，让Python 生态系统的安全问题得到更多的关注。
“我对迄今为止所取得的成就感到非常自豪，”Larson 在 10 月份的一篇博客文章中写道，“这显示了通过雇用人员全职工作来投资开源安全的价值。”
三、写在最后
针对开源项目和基础设施的开源供应链发生的安全攻击与日俱增，让人们越来越认识到 Python 和 PyPI 等提供安全可靠的生态系统的重要性。
此前，PSF 对关键安全问题的改进，只是从专门的志愿者团队或者现在有基础设施工作人员中抽时间来进行，或者偶尔收到赠款才会专门去做。
如今，PSF 在维护Python安全和促进Python社区发展方面做出不少努力。光是2023年，PSF就招聘了一位常驻安全开发人员，一位 PyPI 安全和安保工程师，以及支持社区活动和传播的两位全职工作人员，让 Python 社区变得更加强大和多元。
除了招兵买马壮大队伍，PSF 今年终于获得授权成为 CVE 编号机构（CNA）。这是 PSF 改善 Python 生态系统关键项目漏洞响应流程战略的重要里程碑。Python 软件基金会 CNA 范围涵盖 Python 和 pip，这两个项目对于 Python 生态系统至关重要。
Larson 的加入将负责解决 CPython 和 PyPI 等 PSF 项目的安全问题，并与社区志愿者合作实现关键措施的改进，此外还将建立新的流程和功能，让预防、检测和应对安全风险变得更容易，从而使整个社区能够更轻松、可持续地识别和解决未来的安全问题，期待 Larson 和他的伙伴们能带来更多创新和惊喜。
参考链接：
https://thenewstack.io/pythons-new-security-developer-has-plans-to-secure-the-language/
https://sethmlarson.dev/blog
https://www.python.org/psf-landing/
