提示
本文是大规模采用 GitHub Advanced Security 系列的一部分。 有关本系列的上一篇文章，请参阅“第 5 阶段：推出和缩放代码扫描”。
可以使用 security configuration大规模启用安全功能，这是可应用于组织中的存储库的安全启用设置集合。 可以在组织级别使用 Advanced Security 自定义 global settings 的功能。 请参阅“关于批量启用安全功能”。
本文介绍了一个高级流程，该流程专注于为组织中的所有存储库启用 secret scanning。 即使采用更加交错的方法来为各个存储库启用 secret scanning，仍然可以应用本文中描述的原则。
使用 GitHub Copilot Enterprise 许可证，还可以向 GitHub Copilot 聊天功能 寻求帮助，以更好地了解组织中存储库中的 secret scanning 警报。 有关详细信息，请参阅“在GitHub中询问有关GitHub Copilot的问题”。
1. 重点关注新提交的机密
启用 secret scanning 时，应重点关注修复机密扫描检测到的所有新提交的凭据。 如果专注于清理已提交的凭据，开发人员可能仍会无意中推送新的凭据，这意味着机密数据的总数量将保持在同一水平，而不会如预期般减少。 因此，必须在专注于撤销任何当前机密之前阻止泄露新凭据。
可以通过多种方法处理新提交的凭据，其中的示例方法如下：
-
**通知：** 使用 webhook 确保正确的团队尽快看到所有新的机密警报。 创建、解决或重新开启机密警报时会触发 webhook。 然后，可以分析 webhook 有效负载，并将其集成到你和你的团队所用的任何工具中，例如 Slack、Teams、Splunk 或电子邮件。 有关详细信息，请参阅 [AUTOTITLE](/webhooks-and-events/webhooks/about-webhooks) 和 [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#secret_scanning_alert)。 -
**后续步骤**：创建适用于所有机密类型的高级修复流程。 例如，可以联系提交机密的开发人员及其在该项目中的技术负责人，强调向 GitHub 提交机密的危险，并要求其撤销并更新检测到的机密。注意
可以自动化执行此步骤。 对于拥有数百存储库的大型企业和组织，手动跟进不可持续。 可以在第一步中定义的 webhook 流程中引入自动化。 Webhook 负载包含泄露密钥的存储库和组织信息。 使用此信息可以联系存储库上的当前维护人员，并创建电子邮件/消息发送给负责人或开启问题。
-
**培训**：创建分配给提交机密的开发人员的内部培训文档。 在本培训文档中，你可以说明提交机密所带来的风险，并引导其查阅有关在开发中安全使用机密的最佳做法信息。 如果开发人员没有借鉴经验并继续提交机密，你可以创建升级过程，但培训通常效果很好。
对泄露的任意新机密重复最后两个步骤。 此过程可鼓励开发人员负责安全地管理代码中使用的机密，并使你能够估计新提交机密的减少量。
注意
更高级的组织可能希望对某些类型的机密执行自动修复。 可以将名为 GitHub 机密扫描器自动修复器 的开源计划部署到 AWS、Azure 或 GCP 环境中，并根据定义的最关键内容进行修改以自动撤销某些类型的机密。 这也是一种以更自动化的方式处理提交的新机密的绝佳方式。
2. 启用推送保护
启用 secret scanning 后，还应启用推送保护。 通过推送保护，secret scanning 会检查推送中是否存在受支持的机密，并在机密暴露给其他用户_之前_阻止推送到 GitHub。 有关如何启用推送保护的信息，请参阅“为存储库启用推送保护”。
启用后，可以执行以下操作：
-
**提供指导：** 在参与者将在其推送被 secret scanning 阻止时看到的消息中配置一个自定义链接。 链接的资源可以为参与者提供有关如何解决推送受阻问题的指导。 有关详细信息，请参阅“[AUTOTITLE](/code-security/secret-scanning/enabling-secret-scanning-features/enabling-push-protection-for-your-repository)”。 -
**通知：** 定义一个 webhook，专门跟踪有人使用警报属性 `"push_protection_bypassed": true` 绕过推送保护时创建的 机密扫描警报。 或者，使用 API 通过筛选 `"push_protection_bypassed": true` 的结果列表来获取有关哪些 机密扫描警报 是推送保护绕过结果的更新。 有关详细信息，请参阅“[AUTOTITLE](/code-security/getting-started/auditing-security-alerts)”。 -
**监视**：使用安全概览来查看有关推送保护在整个组织的存储库中执行情况的指标，以便快速识别可能需要采取操作的任何存储库。 有关详细信息，请参阅“[AUTOTITLE](/code-security/concepts/secret-security/push-protection-metrics)”。
3. 修复先前已提交的机密，从最关键的机密开始
建立减少向代码库添加机密的流程后，即可开始修复在引入 GitHub Advanced Security 之前提交的机密。
如何定义最关键的机密将取决于贵组织的流程和集成。 例如，如果不使用 Slack，则公司可能不会担心 Slack 入站 Webhook 机密。 你可能会发现从关注你们组织最关键的前五种凭证类型着手会很有用。
确定机密类型后，可以执行以下操作：
-
定义修复每种机密类型的流程。 每种机密类型的实际程序通常截然不同。 在文档或内部知识库中记录每种机密的过程。
注意
创建撤消机密的流程时，请尝试将撤消机密的责任交给维护存储库的团队而不是中心团队。 GHAS 的原则之一是开发人员对安全负责并负责解决安全问题，尤其是在开发人员引发这些问题的情况下。
-
创建团队将遵循的撤销凭据流程后，你可以整理有关机密类型的信息以及与所泄露机密相关的其他元数据，以便识别出将接收新流程的人员。
可以使用安全概览来收集此信息。 有关使用安全概览的详细信息，请参阅“在安全概述中筛选警报”。
建议收集的信息包括：
-
组织
-
资料库
-
机密类型
-
密码值
-
需要联系的存储库维护人员
注意
如果泄露的该类型机密很少，请使用 UI。 如果泄露的机密达到数百个，请使用 API 收集信息。 有关详细信息，请参阅“适用于机密扫描的 REST API 终结点”。
-
-
收集有关所泄露机密的信息后，为维护受每种机密类型影响的存储库的用户创建有针对性的沟通计划。 可以使用电子邮件、消息，甚至在受影响的存储库中创建 GitHub 问题。 如果可以使用这些工具提供的 API 自动发送通信，你可以轻松管理多种机密类型。
4. 扩展程序以包含更多机密类型和自定义模式
现在，你可以将五种最关键的机密类型扩展为更全面的列表，并重点关注培训。 你可以针对指定为目标的各种机密类型重复上一步，以修复先前提交的机密。
你还可以包含更多早期阶段整理的自定义模式，并邀请安全团队和开发团队提交更多模式，以建立针对新建的机密类型提交新模式的流程。 有关详细信息，请参阅“为机密扫描定义自定义模式”。
继续为其他机密类型生成修正流程时，请开始创建可与组织中所有 GitHub 开发人员共享的主动培训材料。 到目前为止，许多关注点都是反应型的。 最好一开始就将重点关注转变为主动，并鼓励开发人员不将凭据推送到 GitHub。 可以通过多种方式实现这一目标，不过创建简洁文档来说明风险和原因将会奠定很好的基础。
提示
本文是大规模采用 GitHub Advanced Security 系列的最后一篇。 如果有疑问或需要支持，请参阅“大规模采用 GitHub Advanced Security 简介”中有关 GitHub 支持 和 GitHub Professional Services 的部分。