响应安全事件

本文中的指南面向企业所有者、组织所有者、安全经理和安全团队。 但是，需要具有企业所有者角色才能执行本文中所述的多项操作。 某些步骤可能需要与组织所有者或存储库管理员进行协调。

Introduction

本指南逐步讲解如何应对安全事件，概述用于验证和调查威胁的各个方面，并介绍可用于控制和修复威胁的工具。

Prerequisites

理想情况下，你已为企业启用了 审核日志流式处理 和 源 IP 地址可见性 （将数据流式传输到安全信息和事件管理 （SIEM） 系统），并且你有权访问该数据。 请参阅“流式处理企业审核日志”。

在整个响应中

在进行响应过程中，请确保：

• 保留证据：获取可疑活动的屏幕截图、导出日志或查询结果，并在清理之前保存受影响文件或代码的副本。
• 记录：记录你的发现（例如，时间、日期、泄露指标（IoC）、受影响的存储库），并记录你做出的每个决定。
• 沟通：通知相关利益干系人（如安全主管和工程经理，以及法律和隐私团队（如果敏感数据处于危险状态），并使其保持更新。

步骤 1：评估信号并快速验证

目标是快速确定你看到的信号是否可能是真正的主动威胁。

1. 识别

尝试识别所看到信号的性质。 例如，信号是否显示以下指示：

• 凭证泄露 （泄露机密的警报，外部站点上发现凭证的报告）
• 未经授权的访问或帐户泄露 （可疑登录报告、不熟悉的提交或更改）
• 数据外泄 （可疑文件更改或添加报告、意外工作流运行、异常 API 活动、未知存储库创建或意外存储库可见性更改）
• 恶意代码注入 （报告可疑代码更改、意外的工作流运行、添加新文件）
• 供应链攻击 （可疑包版本报告、易受攻击依赖项的警报）

若要帮助识别整个组织或企业中的这些威胁信号，请参阅 常见安全事件调查领域。

建议不要在调查的早期阶段花费太多时间进行深入检查，因为初始目标是 确定 威胁信号，以 验证 威胁信号并制定响应策略。

2. 验证

检查是否有证据来验证潜在威胁是否真实，以及它当前是否处于活动状态。

以下 GitHub 工具和表面可以帮助。

工具/表面	Purpose
安全概述和安全警报	查看整个组织或企业的安全警报
审核日志	搜索与要调查的信号相关的事件，例如令牌创建、权限更改或存储库可见性更改
活动视图	查看特定存储库的推送、提交和分支活动的时间线
[

          GitHub 代码搜索](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | 跨存储库搜索已知泄露指标，例如特定文件名或代码模式 |

| 依赖项关系图 | 检查存储库是否依赖于特定包或包版本 | | 工作流运行和日志 | 查看工作流执行历史记录并检查可疑活动的日志输出 |

有关每个工具的详细信息，请参阅 安全事件调查工具。

验证阶段可能 很快：

• 旨在收集足够的证据，以确定信号是否可能是 真实 和 积极的 威胁。
• 如果无法快速排除信号为误报，则假定它是真实的。
• 稍后可以执行深入调查。

3. 决定

根据收集的证据，确定三件事：

1.        **这是真正的威胁吗？** 如果不能快速自信地将信号排除为误报，请将其视为真实信号并继续遏制。
   

2.        **威胁是否仍处于活动状态？** 如果攻击者似乎仍然具有访问权限或仍在活动，请优先立即采取控制措施。 如果妥协看起来是历史的，你仍然需要调查和修正，但你可能有更多的时间来计划你的响应。
   

3.        **潜在的范围是什么？** 考虑泄露可能达到的距离—单个凭据、存储库、组织或整个企业。 这将帮助你适当地调整响应。
   

如果有疑虑，请将威胁视为真实威胁，然后根据证据适当调整响应。

步骤 2：包含威胁

下一步假设你正在处理真正的主动威胁。 现在的目标是根据你目前所知立即降低持续风险。

可以选择执行多个包含操作来限制攻击者的访问和功能。

撤销已泄露的凭据

对于公开或利用的凭据，可以采取的最直接操作是撤销受影响的凭据，以防止进一步滥用。

• 通过 API 撤销

  如果令牌是以下类型之一，并且令牌的文本值是已知的，则可以通过 REST API 提交请求来撤销令牌（或任何人）。 请参阅“撤销”。

  • Personal access token (classic)
  • Fine-grained personal access token

• 吊销和限制选项

  还有一些用于阻止凭据访问的其他选项。 有关按凭据类型列出的完整列表，请参阅 GitHub 凭据类型参考。

• 紧急行动（重大事件）

  企业所有者可以在GitHub Enterprise Cloud上采取批量紧急措施来封锁整个企业的访问权限。 对于具有 Enterprise Managed Users此功能的企业，这包括 删除所有用户令牌和密钥。 这些是具有高影响力的操作，会破坏自动化，应该仅用于重大事件。 请参阅“响应企业中的安全事件”。

限制访问

若要限制对企业、组织或存储库的访问，可以立即执行多项操作。

• 配置 IP 允许列表

  阻止未知或可疑的 IP 地址访问组织或企业。 请参阅 使用 IP 允许列表限制企业网络的流入流量 （企业管理员）和 管理组织允许的 IP 地址 （组织所有者）。

• 删除遭到入侵或可疑的用户

  删除用户或暂停帐户。 请参阅 从组织中删除成员 （组织所有者）。

• 将存储库可见性更改为专用

  将受影响的存储库可见性更改为专用存储库，并限制其他人进行进一步更改的能力。 例如，如果敏感代码在属于组织的公共存储库中公开，或者恶意参与者将存储库的可见性设置从专用更改为公共，则可以更改存储库的可见性。 请参阅 设置存储库可见性 （存储库管理员和组织所有者）和 限制在组织中更改仓库可见性 （组织所有者）。

• 紧急行动（重大事件）

  在 GitHub Enterprise Cloud 上的企业所有者可以采取批量紧急措施来限制对其企业的访问权限。 其中包括 锁定 SSO 以阻止所有非所有者访问，并 撤消跨组织的所有用户 SSO 授权。 这些是高影响的操作，会中断自动化，应仅在重大事件中保留使用。 请参阅“响应企业中的安全事件”。

禁用恶意组件和活动

• 停止恶意工作流运行

  如果怀疑 GitHub Actions 工作流或运行程序正在用作活动攻击的一部分，则可以执行以下操作：

  • 取消受影响存储库的正在进行的工作流运行。 请参阅“取消工作流程运行”。
  • 对组织中受影响的存储库或特定组织禁用 GitHub Actions 。 请参阅 禁用或限制组织的 GitHub Actions （组织所有者）和 在企业中强制实施GitHub Actions策略 （企业管理员）。
  • 删除自托管运行器。 请参阅“删除自托管的运行器”。

• 禁用 Webhook

  如果怀疑泄露的存储库或组织 Webhook 正在用作实时数据外泄通道，则可以禁用它。 请参阅“禁用网络钩子 (Webhook)”。

• 删除恶意分支

  如果已识别包含恶意代码或工作流的分支，请立即将其删除以防止执行。 请参阅“在库中创建和删除分支”。

步骤 3：完全调查

立即遏制后，目标是了解事件的完整范围和影响，识别所有 IOC 和持久性机制，并收集用于围堵和完全消除威胁所需的证据。

1. 根据你所看到的信号和到目前为止收集的证据，制定一个 工作假设 ，了解所发生的事情，并决定你需要证明或反驳该假设所需的其他证据。

2. 请考虑 AUTOTITLE 中概述的不同调查区域，以帮助指导调查。

   不要将调查限制在单一方向。 许多攻击使用多种技术的组合，例如恶意包安装与凭据利用、工作流文件注入和数据外泄相结合。 确保正在调查所有潜在的攻击途径。

3.        **记录** 迄今已知的所有 IoCs，搜索GitHub上所有区域的痕迹。
   

4.        **清点** 所有受影响的工作流、存储库和组织，以系统地捕获事件的范围。
   

   • 包括存储库名称、受影响的内容（代码、机密、工作流）和泄露时间线。
   • 创建所有受影响的帐户和凭据的列表。 请注意，哪些令牌、SSH 密钥或其他凭据可能已公开或滥用。

5.        **根据证据验证** 你的工作理论。
   

   • 查看已收集的证据。 它是否支持你的初始假设？
   • 请考虑替代说明。 你观察到的活动是否有其他原因？
   • 如果假设被反驳，请根据证据形成新的假设，并根据需要重复调查步骤。

6. 如果发现新的 IoC 或持续活动的证据，需要立即采取行动，请回到隔离措施。

对所发生的事情和根本原因的理解高度有信心后，请记录调查结果并继续修正。

步骤 4：修正

现在的目标是删除所有泄露跟踪，修复根本原因，并将系统还原到安全状态。 修正操作将取决于你面临的漏洞，但一些良好做法如下所示。

轮换令牌和机密

即使你不确定凭据是否被泄露，如果有泄露的可能，也应该更换它。

• 生成新的令牌和密钥以替换已吊销或可能已泄露的任何令牌和密钥。
• 轮换存储在 GitHub 存储库、环境和组织级别的机密。
• 更新可能已使用已泄露令牌访问的外部系统中的任何凭据。
• 请考虑启用令牌过期策略，以鼓励今后定期轮换。 请参阅“在企业中强制实施个人访问令牌策略”。

对持久性机制的审核

你需要检查攻击者可能已建立的持久性机制，以确保在您进行初步封锁措施之后，访问权限仍然可以保持。

这包括（但不限于）检查以下内容：

• 可能已添加或修改的可疑或不熟悉的工作流文件。
• 指向不熟悉的域名的新 Webhook。
• 新的自承载跑步者。
• 对自托管运行器的修改。
• 新安装的 GitHub Apps 或 OAuth app 授权。
• 新的部署密钥已添加到代码库中。
• 新的二进制文件或可执行文件。

审核并重新安装依赖项

受损的依赖项可以作为攻击途径。 请确保对依赖项进行全面审核，并从受信任的源重新安装依赖项。

• 查看有关易受攻击依赖项的Dependabot警报，并在有可用时查看有关恶意软件包的Dependabot malware alerts警报。 （Dependabot malware alerts目前可用于 npm 生态系统。若要调查其他恶意软件公告，请在依赖项图中type:malware搜索GitHub Advisory Database并审核匹配项。
• 将依赖项固定到已知良好版本或提交 SHA，然后从包注册表重新安装。

验证修正

确认修正工作已成功。

• 查看 code scanning 警报以确认代码漏洞已解决，并且未引入任何新漏洞。
• 查看 secret scanning 警报，确认未在任何存储库中公开任何机密，并且所有警报都已解决。
• 在事件发生后的几天和几周内，继续查看和监视审核日志及其他相关方面。

步骤 5. 文档

完整的文档对于剩余阶段和将来的参考至关重要。

• 记录调查期间发现的所有 IoC。
• 记录执行的所有修正步骤，包括时间戳和执行每个操作的人员。
• 维护受影响存储库、工作流和帐户的清单。
• 记录决策及其背后的推理。
• 请注意任何合规性、法律或隐私方面的影响。 请考虑此事件是否构成需要通知的数据泄露。

步骤 6：反射和强化

现在的目标是从事件中吸取教训，加强安全态势，以防止类似的事件。

1. 编写 事件摘要。 这应包括从第一个指示到解决的事件的时间线，以及根本原因分析、决策和行动以及吸取的教训。

2. 跟踪安全事件中的任何未完成操作项，例如剩余补救任务，以及需要根据所吸取的教训实施的任何安全改进。

3. 如果还没有，请确保您的公司或团队具有最新的一份安全事件响应计划。 这应包括已定义的角色和责任、升级路径、通信协议、严重性分类条件和常见威胁类型的分步响应过程。 Copilot 可以帮助根据特定需求和资源生成和优化此计划。 有关其他指南，请参阅 什么是事件响应。

后续步骤

• 如果尚未这样做，请考虑强化安全状况，以减少未来事件的风险。 请参阅“防范安全威胁”。