入站恶意软件数量报告

背景

当前的 PyPI 安全报告流程指导报告者向 security@pypi.org 发送包含详细信息的电子邮件。security@ 之前是 admin@ 的电子邮件别名，后者是一个包含所有当前 PyPI 管理员（4 人）的 Google 群组。

我将在此处将 security@ 地址称为 安全收件箱，尽管它不是传统的收件箱，以及我们对其进行的更改。

入站报告工作流程大致如下

管理员收到发送到安全收件箱的电子邮件
任何管理员都会阅读电子邮件
管理员检查攻击指标 (IOC)、软件包和用户历史记录。通常使用 inspector.pypi.io 来调查软件包内容
管理员采取行动（通常是将其删除为恶意软件）
管理员回复报告者，并将安全收件箱抄送至跟踪信息

这是一个展示通知流程的大致顺序图

sequenceDiagram
  participant External
  participant googleMail as Google Mail Routing
  participant googleGroup as Security Inbox<br/>(Google Group)
  participant pypiAdmins as PyPI Admins

  External->>googleMail: sends an email report
  googleMail->>googleGroup: sends an email report
  googleGroup->>+pypiAdmins: sends an email report
  pypiAdmins-->>+External: Hi, thanks for your report...
  pypiAdmins-->>-googleGroup: CC response to group

title Previous Inbound Flow

我想回答几个问题，以便获得一些数据

我们收到了多少入站恶意软件报告？（每天/每周/每月）
管理员从收到恶意软件报告到将其删除需要多长时间？

使用基于电子邮件的系统回答这些问题不会完全准确，因为存在一些导致不准确性的条件，但由于我们正在查看大量的记录，因此这些不准确性不太可能导致数量上的重大差异。以下是一些示例

报告者在单条消息中提交多份报告
报告者回复其原始电子邮件以进行新的报告，而不是开始新的主题/对话
与管理员联系以寻求支持的人员可能会向安全收件箱发送电子邮件
与安全相关的非恶意软件报告问题
垃圾邮件

这主要是为了确定我们目前的基线位置。有了这个度量，我们就可以观察到我们流程的更改是否对数量和响应时间产生积极或消极影响。

注意：此分析不是对报告的恶意软件软件包的准确衡量，因为多个研究人员可能会报告同一个软件包，这将显示为不同的对话主题。我们可以尝试标准化软件包，但是由于电子邮件结构化程度较低，这可能需要比实际需要更多的精力。无论如何，管理员都会回复重复项，因此仍然存在非零的工作量。

今年早些时候，我们的一位管理员在推特上发布了一些移除统计数据（在我们拥有博客之前！）。

在 2022 年，@pypi 团队移除了超过 12,000 个独特的项目。每个项目都是垃圾邮件、错字抢注、依赖项混淆、数据窃取和/或恶意软件的实例。

2022 年：约 12K（主要是恶意软件）
2021 年：约 27K（主要是依赖项混淆）
2020: ~500
2019: 65
2018: 137
2017: 38
— Dustin Ingram (@di_codes) 2023 年 1 月 4 日

入站恶意软件报告的频率如何？

为了确定这个答案，我选择使用电子邮件本身，因为这是我们拥有的详细信息来源。虽然这不是一个完美的数据源，但它应该足以让我们做出一些初步的断言。我们还可以利用迄今为止生成的任何统计数据来帮助衡量未来的进展。

我的 PyPI Google Workspace 帐户是在 2023-03-02 创建的，之后开始接收 security@pypi.org 电子邮件。Google 群组没有提供任何我能找到的 API，允许经过身份验证的用户直接从群组中列出/读取对话。

这种方法提供了更清晰的信噪比，因为如果邮件没有用（垃圾邮件、营销等），我经常会删除发送到安全收件箱的随机邮件。我们可以接受过去几个月的这种数据收集方法，或者探索其他方法从旧帐户/邮件列表中收集长期数据，所有这些方法都受制于不同的数据质量问题。

使用截至 2023-08-14 发送到安全收件箱的 1,303 个电子邮件主题的数据，我们可以生成此图表

Inbound Malware Reports by Date

相同的数据，按周号分组

Inbound Malware Reports by Week

一个观察结果是，在 5 月份的 PyPI 周末暂停（第 20 周）之后，总体数量下降了一段时间。没有确凿的证据表明原因，但有趣的是，短暂的中断减少了维护人员目前承担的一些工作量。

为了完整起见，以下是月度视图

Inbound Malware Reports by Month

响应需要多长时间？

为什么响应时间很重要？恶意软件包可供最终用户安装的时间越长，它可能影响的人员和系统就越多。任何捕获恶意软件的软件包镜像都会使情况更加复杂，并且可能无法像 PyPI 管理员那样快速将其删除。我们已经从报告者那里获得了轶事证据，表明 PyPI 管理员在处理入站报告方面已经非常快（#humblebrag），但让我们看看是否可以从相同的电子邮件中获取数据。

同样，由于电子邮件的性质在这种情况下不能 100% 准确，因此我们将依赖于计算主题的第一条消息和主题的最后一条消息之间的时间长度（以分钟为单位）。这没有考虑报告者偶尔重复使用同一主题来报告更多软件包的行为，也没有反映管理员和报告者之间任何其他来回通信。因此，删除总消息数超过 4 条的任何主题有助于从分析中消除异常值。

入站报告会在一天中的任何时间到达，并且也可能由报告者自动生成。在我们的睡眠时间，报告通常会等待处理。周末和节假日通常响应时间也更长。

有时，入站报告可能会被忽略，我们正在尝试通过一个新系统来解决这个问题，稍后会详细介绍。

响应时间更长可能意味着大部分是志愿者的管理员第一次错过了对它的响应。为了进行此分析，我已经排除了 7 个总响应时间，这些时间超过了 14 天（20,160 分钟），以消除这些异常值。

Response Times by Date

使用中位数而不是平均值可以帮助我们处理频谱两端的异常值。

将线性趋势线应用于收集的数据表明，响应时间总体上随着时间的推移而减少，这是一件好事。

以下是自 2023 年 3 月以来收集数据的响应时间分布

Response Times Histogram

此图表告诉我们，大多数对报告的响应在约 485 分钟（约 8 小时）内完成，几乎所有响应都在报告后的几天内完成，并有一个长尾。

总的来说，这并没有反映出响应时间的全貌，这就是为什么我们一直在努力创建一个新系统来帮助我们更快地响应并生成更好的报告的原因。

结果发生了哪些变化？

PyPI 恶意软件报告和响应项目的一部分是探索进一步减少响应时间的方法，同时减少维护人员的工作量，并提高报告者的可见性。

根据此分析，我们目前已经做出的一个更改是利用一个共享收件箱系统 Help Scout 来接收入站电子邮件，并允许我们标记、分配和关闭报告。这通过避免错过报告并防止管理员重复响应来帮助我们。

以下是如何更新我们的 Google Workspace 流程，以便我们能够继续接收入站电子邮件，以及将 Help Scout 中的对话复制到 Google 群组中以进行长期存档。

sequenceDiagram
  participant External
  participant googleMail as Google Mail Routing
  participant googleGroup as Google Group<br/>Archive
  participant helpScout as Security Inbox<br/>(Help Scout)
  participant pypiAdmins as PyPI Admins

  External->>googleMail: sends an email report
  googleMail->>+helpScout: sends an email report
  googleMail->>googleGroup: archive email
  helpScout->>+pypiAdmins: inbound notification
  pypiAdmins-->>-helpScout: Hi, thanks for your report...
  helpScout->>googleGroup: archive via auto-bcc
  helpScout-->>-External: Hi, thanks for your report...

title Updated Inbound Flow

对最终用户没有更改，我们希望我们的更改能让我们继续及时地响应报告。

以下是我们开始使用 Help Scout（2023-09-05）以来的响应时间初次查看，使用其报告。在开始使用 Help Scout 以来的一段时间内，总共有 31 个对话，与之前图表中最后两周的数据（59 个对话）相比，我们可以看到响应时间有所改善

响应时间范围	总数的百分比	使用 Help Scout 之前
< 15 分钟	40%	53%
15-30 分钟	20%	10%
30-60 分钟	20%	5%
1-2 小时	10%	7%
2-12 小时	10%	15%
12 小时以上	0%	10%

我们现在很高兴地报告，所有报告的 80% 在收到后的 60 分钟内得到响应，100% 的报告在 12 小时内得到响应。

我们将继续监控我们的响应时间和数量，并在需要时进行调整。

下一步是什么？

我们正在努力设计一个新的系统来帮助我们更快地响应入站报告并提供更好的结果。这还处于起步阶段，我们正在设计中整合 PyPI 管理员、外部研究人员和报告者的集体经验中的许多想法。

我们邀请您参与有关以更易于机器读取的格式报告恶意软件的对话，具体请参见此 GitHub 问题，并在适当的情况下考虑发送拉取请求。