安全与安全工程师：第一年回顾
您好，读者！我是 Mike，我加入 PSF 担任 Python 包索引 (PyPI) 的安全与安全工程师已经一年多了。关于加入 PSF
我想花点时间回顾过去的一年，并分享一些我一直在做的事情。
您可能还记得，当宣布该职位时，不久之后就宣布了一个恶意软件报告项目，这两个项目都得益于来自外部捐赠者的慷慨资金，特别是亚马逊网络服务 (AWS) 和安全与新兴技术中心 (CSET)，如果没有他们，这一切都不可能实现。请您以任何方式感谢他们。
过去一年的部分重点摘要
所有用户双因素身份验证 (2FA)
在 2023 年的最后几个月，我承担了将双因素身份验证 (2FA) 的进展带给所有 PyPI 用户帐户的任务，该任务始于 2019 年。这是一项艰巨的任务，因为系统中有大约 850,000 个帐户。
这里有一些相关的博客
以及一些与 2FA 相关的事件报告，这些报告突出了 2FA 的必要性
在第二次事件后，PyPI 管理员决定使所有未完成 2FA 设置的用户帐户电子邮件地址失效，作为最小化帐户接管攻击的一种方式。
这是一个多步骤过程，我很高兴地宣布，截至今天，超过140,000 名用户启用了一种或多种形式的 2FA。截至今天，约 80% 的自 2024 年 1 月以来登录的所有用户都启用了 2FA。其余用户尚未完成 2FA 注册流程，因此无法在 PyPI 上执行任何操作。随着时间的推移，启用 2FA 的用户数量将继续增长，并且返回发布项目更新的旧用户帐户必须作为该流程的一部分注册 2FA。
现在，所有发布者都必须对 PyPI 使用 2FA，因此通过帐户接管恶意代码被传递的风险已大大降低，我们整个社区都更安全。感谢在推广期间注册 2FA 的每个人。
PyPI 首次审计
同样在 2023 年下半年，开放技术基金 (OTF) 为 PyPI 提供了资金，对其进行了审计，这是其历史上首次进行审计。阅读三部分博客系列的第一部分，以详细了解审计及其发现。希望您喜欢这个系列！
为了为审计做准备，我创建了PyPI 基础设施的系统架构图，这些图被用作审计的一部分，以帮助告知审计师关注的重点。在审计期间，我每周都会与审计师会面，以了解任何发现并努力确定优先级并解决问题。
审计结束后，我与审计师一起处理了他们的最终报告，以及与社区分享的博客系列。
恶意软件响应和报告
如果您定期阅读此博客，您可能会注意到，一直在关注恶意软件响应，事实确实如此。由于恶意软件对 Python 生态系统构成持续威胁，我一直在努力开展一些项目，以更好地应对恶意软件。以下是一些重点内容
传入通知
最初，联系 PyPI 管理员的唯一方法是通过电子邮件。我们已经用共享收件箱系统取代了直接电子邮件，从而最大限度地减少了重叠响应，甚至错过了响应。我们获得了通过工作流程自动执行响应、使用元数据标记和收集报告的能力。
我试图在这篇博客中捕捉到流程的状态：传入恶意软件数量报告
然后，我在 PyPI 代码本身中开发了观察结果。对现有数据模型的增强，通过添加将半任意注释或批注附加到 PyPI 数据库中其他模型（例如项目、版本或文件）的能力。例如，观察结果可以通过任何登录用户的 Web 界面提交，也可以通过受信任报告者的安全测试版 API 提交。API 工作需要实施更细粒度的权限模型，从而减少特定操作的范围，并在代码中使权限更加清晰。
基于 Web 表单和 API 的方法围绕报告创建了更多结构，从而加快了对“简单”恶意软件案例的调查和解决时间，并为调查“更难”案例提供了更多时间。
您可以在此处阅读有关此内容的更深入探讨：恶意软件报告的演变
自 2023 年 8 月以来，传入通知流程已收到约 2,000 条传入消息。新的观察和报告流程是在 2024 年 2 月实施的，约有 1,400 条传入通知通过这种方式传入（3 月和 6 月的两个较大的恶意软件活动，分别约有 500 个报告）。
自 2024 年 3 月以来，我们在项目删除后保留了这些报告。以前，当我们删除恶意项目时，我们也会删除相关的观察结果。现在，我们为了后代和分析而保留了这些报告。
我们已经看到了 76 个不同的报告者，其中 3 个提交了超过 200 个不同的报告，5 个报告者提交了数十个报告，其余部分是少量报告的较长尾部。
自 2024 年 3 月以来，按报告渠道细分的传入报告如下所示
| 来源 | 计数 |
|---|---|
| Web 按钮 | 498 |
| 测试版 API | 403 |
| 管理员 UI | 6 |
感谢所有向 PyPI 报告恶意软件的人，以及更多愿意尝试测试版报告 API 的人！
管理员响应
当收到报告后，PyPI 管理员有责任确定给定报告的有效性并采取相应的措施。
基于现有的 PyPI 管理员用户界面，我创建了视图和快速响应按钮，以实现更快的评估和采取行动，同时最大限度地减少错误或手动/一次性操作。
自 2023 年 8 月以来，超过 90% 的问题在 24 小时内得到解决，其中超过 95% 的问题处理时间不到一分钟。对于自 2024 年 3 月中旬以来删除的约 900 个项目，我们根据合格的恶意软件报告的传入通知生成了约 1,300 个不同的报告。这些报告可以作为私人测试版提供给感兴趣的各方。
使用从 2024 年 1 月开始收集的一些观察数据（不包括晚上和周末，因为我们还没有 24/7 响应团队），我们可以看到以下趋势
上图显示了 2024 年每个导致项目删除的传入报告的堆叠时间（以分钟为单位）。蓝色条形表示从项目创建到向 PyPI 报告的时间。红色条形表示 PyPI 管理员响应和删除项目所需的时间。
我们可以观察到 PyPI 上恶意软件存活时间的趋势在下降，从几个月和几天到几小时和几分钟。
为了更清楚地显示响应时间，让我们只查看报告接收时间和项目删除时间之间的间隔
6,000 分钟的异常值发生在 7 月 4 日的假期周末。
希望随着我们改进流程和工具，这种趋势会继续改善。
项目生命周期状态 - 隔离
除了从 PyPI 删除项目的传统响应之外，我还为给定项目的生命周期引入了另一个操作 -“隔离”。此状态允许 PyPI 管理员将项目置于非破坏性隔离状态以进行进一步分析，在经过进一步调查之前，最终用户将无法轻松安装该项目。
拥有此中间阶段使 PyPI 管理员能够为最终用户创造更大的安全保障，通过 PyPI 管理员删除可疑软件包来更快速地保护最终用户，同时允许进一步调查。由于从 PyPI 删除项目是一个破坏性操作，因此创建隔离状态允许在被视为误报的情况下恢复项目，而不会破坏任何项目的历史记录或元数据。
我还没有为此写博客，但可能会很快写一篇。
CISA 响应
在 2023 年 8 月初，网络安全和基础设施安全局 (CISA) 宣布了有关开源软件安全的征求意见书 (RFI)。实际RFI 文本可以在此处阅读。
2023 年 11 月，PSF 提交了对 CISA RFI 的回复。
我以前从未给联邦政府写过任何东西，所以这对我来说是一次全新的体验。我们 PSF 中的许多人共同撰写了回复，我在文档中主导了 PyPI 相关的和包装安全相关的部分。
这是一个极好的机会，可以突出 PyPI 在 Python 生态系统中的重要性，包括其对几乎所有组织的至关重要性。
等等
在处理上述所有工作的同时，我还做了很多其他事情。以下是一些示例
- 为新的 API 端点采用基于 OpenAPI 的方法
- 重构核心数据模型以增强可扩展性
- 重构权限模型以更细致地控制用户操作
- 使用新的验证码服务在注册期间捕获更多机器人
在整天都在 warehouse 代码库中工作时，我已经对开发环境、测试速度和代码质量进行了各种改进，主要是为了帮助我自己，并且额外的好处是让其他人更轻松地做出贡献。
以及“日常”工作 - 处理传入的报告、分析和响应。
我还参加了一些会议、圆桌会议和会议，包括 Fastly Altitude 2023、AWS re:Invent 2023、PyCon US 2024 和 AWS re:Inforce 2024 等。我还更多地参与了OpenSSF 的安全软件存储库工作组。
我根本不可能在这里涵盖所有内容，但希望这已经为您提供了我所做工作的概览。我非常期待明年的工作，敬请期待更多内容！