响应安全事件

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

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

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

验证阶段可能很快：

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

3. 决定

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

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

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

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

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

步骤 2：包含威胁

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

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

重要

应根据威胁的性质、潜在范围和此时提供的证据来选择操作。我们不建议对每个事件采取所有这些操作。某些操作比其他操作更具破坏性或破坏性，因此，必须根据对上述威胁性质的评估来权衡每个操作的风险和好处。

撤销已泄露的凭据

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

吊销和限制选项

还有一些用于阻止凭据访问的其他选项。有关按凭据类型列出的完整列表，请参阅 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 和持久性机制，并收集用于围堵和完全消除威胁所需的证据。

重要

事件响应不是线性过程。在发现新的 IoC 或更详细了解攻击时，可能需要在调查、遏制和补救措施之间反复进行。

根据你所看到的信号和到目前为止收集的证据，制定一个 工作假设 ，了解所发生的事情，并决定你需要证明或反驳该假设所需的其他证据。
请考虑 AUTOTITLE 中概述的不同调查区域，以帮助指导调查。

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

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

```
       **清点** 所有受影响的工作流、存储库和组织，以系统地捕获事件的范围。
```
- 包括存储库名称、受影响的内容（代码、机密、工作流）和泄露时间线。
- 创建所有受影响的帐户和凭据的列表。请注意，哪些令牌、SSH 密钥或其他凭据可能已公开或滥用。
```
       **根据证据验证** 你的工作理论。
```
- 查看已收集的证据。它是否支持你的初始假设？
- 请考虑替代说明。你观察到的活动是否有其他原因？
- 如果假设被反驳，请根据证据形成新的假设，并根据需要重复调查步骤。
如果发现新的 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：反射和强化

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

编写 事件摘要。这应包括从第一个指示到解决的事件的时间线，以及根本原因分析、决策和行动以及吸取的教训。
跟踪安全事件中的任何未完成操作项，例如剩余补救任务，以及需要根据所吸取的教训实施的任何安全改进。
如果还没有，请确保您的公司或团队具有最新的一份安全事件响应计划。这应包括已定义的角色和责任、升级路径、通信协议、严重性分类条件和常见威胁类型的分步响应过程。 Copilot 可以帮助根据特定需求和资源生成和优化此计划。有关其他指南，请参阅什么是事件响应。

后续步骤

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

在本文中