Introduction
与响应安全事件相比，防止安全事件的成本更低，破坏性更低。 通过积极加固您的环境GitHub，可以减少因为凭据被利用、未经授权访问和供应链攻击等威胁带来的风险暴露。
本指南主要侧重于可跨属于企业 GitHub Enterprise Cloud一部分的组织应用的保护措施。 若要试用 GitHub Enterprise Cloud，请参阅 设置 GitHub Enterprise Cloud 试用版。
GitHub此处提到的许多安全功能（例如安全配置、分支规则集和访问控制）都可以在组织级别或企业级进行配置。
立即操作
这些操作是你现在可采取的高影响操作，用于在整个组织中建立安全基线。
建立安全防护措施
确保所有GitHubGitHub Advanced Security存储库中的工具都处于活动状态。 你可以创建并应用 安全配置，而不是逐个启用工具，这是一系列安全设置，可在单个操作中应用于整个组织或企业的存储库。
强配置可能包括：
Secret scanning
** 并 **推送保护** 以检测已提交到代码库的机密，并阻止推送新机密。 泄露的凭据是安全漏洞的最常见原因之一。
Code scanning
** 在源代码到达生产环境之前识别漏洞和编码错误。
Dependabot alerts
** 并 **Dependabot security updates** 通知你依赖项中的已知漏洞和恶意软件，并自动打开拉取请求以更新易受攻击的依赖项。
请参阅 删除自定义安全配置（组织）和 为企业创建自定义安全配置（企业）。
收紧控制
GitHub 提供一系列控制措施，用于控制存储库和组织中可能发生的情况。 确保正确配置这些控件对于降低风险至关重要。
使用规则集保护关键分支
规则集允许跨一个或多个存储库定义分支和标记的保护规则。 使用它们强制执行拉取请求评审和状态检查（例如自动安全扫描）等要求。 这有助于防止未经授权的更改访问生产代码，包括来自已泄露帐户的更改。
请参阅 创建组织中存储库的规则集（组织）和 使用规则集在企业中强制实施代码治理（企业）。
控制谁可以绕过推送保护
启用推送保护时，尝试推送检测到的机密的参与者会被阻止，但默认情况下，他们可以选择绕过阻止。 委派的绕过 要求绕过请求通过评审和审批周期，因此，如果没有显式的审核决策，则不会发生绕过。
请参阅“启用推送保护委派绕过”。
对拉取请求强制实施依赖项评审
通过显示拉取请求的依赖项更改中的已知漏洞，依赖项评审操作允许你在合并依赖项之前捕获易受攻击的依赖项。 就如同为敏感信息提供推送保护一样，它充当防护门，而非事后才发出警报。 可以在整个组织中强制实施对拉取请求的依赖项评审。
请参阅 关于依赖项评审 和 在整个组织内强制执行依赖项审查。
审查和限制访问
授予访问权限时是适当的，但之后可能不再需要。 定期评审谁以及有权访问组织的人员可降低未经授权的操作的风险。
审核成员访问权限并遵循最低特权原则
确保组织成员仅具有所需的访问权限。 移除那些不再需要访问权限的成员，降级那些不需要更多权限的角色，并审核外部协作者的访问权限。 过于宽松的访问权限会增加任何被攻陷账户的影响范围。
如果默认角色比组织要求更宽松，则可以创建自定义 角色 ，仅授予每个团队所需的特定权限。 对于采用零信任安全模型的组织来说，这特别有价值。
请参阅“确定企业所需的角色”。
查看授权的应用程序
OAuth apps 和 GitHub Apps 安装在组织中，可以访问数据。 查看授权的应用程序列表，并删除不再需要或不再信任的任何应用程序。 长期未更新的集成通常被忽视，但它们构成了攻击面。
请参阅 查看和修改已安装GitHub应用 和 关于 OAuth 应用访问限制。
使用 IP 允许列表限制网络访问
对于在 GitHub Enterprise Cloud 上的组织，如果您的组织在已知的网络范围内运行，请配置 IP 允许列表，以便只能从这些范围访问 GitHub 资源。 这增加了一层防御，防止从意外位置使用已泄露的凭据。
请参阅 管理组织允许的 IP 地址 和 使用 IP 允许列表限制企业网络的流入流量。
运行机密风险评估
运行一次免费的按需扫描，以便您获得关于组织内多个存储库中当前暴露的敏感信息总数的时间点视图。
请参阅“为您的组织运行保密风险评估”。
短期措施
这些操作对于安全状况也很重要，但可能需要进行更多准备和协调，然后才能推出它们。
加强身份验证
弱身份验证或泄露身份验证是帐户接管的最常见原因之一。 要求在整个组织中进行强身份验证可显著降低此风险。
对于所有成员，都需要双重身份验证（2FA），这可确保仅泄露的密码不足以访问帐户。 在执行要求之前，请与组织通信，以便成员有时间设置 2FA。
GitHub Enterprise Cloud组织可以通过实施单一登录（SSO）进一步拓展，将身份验证集中在您的身份提供者中。
请参阅 在你的组织中要求进行双因素身份验证 和 关于使用 SAML 单一登录进行的身份和访问管理。
GitHub Actions强化工作流
GitHub Actions 工作流通常可以访问敏感信息、部署凭据，并拥有对存储库的写入权限。 如果不仔细配置，泄露或恶意操作可能会泄露数据或注入恶意代码。
显式声明工作流权限
默认情况下，工作流可能会通过 GITHUB_TOKEN 获得广泛的权限。 使用工作流文件中的 permissions 密钥显式声明每个工作流所需的最低权限。 这限制了泄露的工作流步骤可能导致的损害。
固定第三方操作以提交 SHA
通过标记（例如，v1）引用第三方操作时，可以移动标签以指向不同的代码片段。 将操作固定到完整的提交 SHA 可确保您始终运行您已经审阅并批准的代码。 这可以防止在供应链攻击中标签被劫持的情况。
限制哪些操作可以运行
在组织或企业级配置策略，以控制允许哪些操作运行。 可以将操作限制为由GitHub创建的操作、经过验证的创建者创建的操作或特定允许列表内的操作。
有关所有这些做法的详细信息，以及专门针对 GitHub Actions 的额外安全使用做法，请参阅 安全使用指南。
持续的安全做法
这些做法应成为常规操作节奏的一部分。
使用安全概述监控您的安全态势
通过安全概述，你可以集中查看组织的和企业的安全环境。 使用它跟踪哪些存储库启用了安全功能，并识别具有开放警报的存储库，以便不会忽视新兴风险。
请参阅“关于安全概述”。
定期开展安全活动以减少安全债务
随着时间的推移，安全警报可能会累积。 通过安全活动，你可以组织和确定修正工作的优先级，向开发人员分配警报组（借助Copilot生成的修补程序），或直接将警报分配给Copilot。
安全活动可用于拥有启用GitHub Team的GitHub Enterprise Cloud或GitHub Secret Protection or GitHub Code Security的组织。 请参阅“创建和管理安全活动”。
继续审核访问权限和许可
随着人员加入和离开组织，随着项目的发展，访问要求会发生变化。 安排定期评审：
- 组织成员身份和角色。
- 外部协作者访问权限。
- 存储库级权限和团队分配。
- 已授权的 OAuth 和 GitHub Apps.
这可确保访问与最低特权原则保持一致，即使组织发生更改也是如此。
保持依赖项更新
易受攻击的依赖项是攻击者的常见入口点。 Dependabot 可以自动打开拉取请求以更新具有已知漏洞的依赖项，但这些拉取请求仍需及时查看和合并。
建立分类和合并Dependabot 拉取请求的流程，以确保安全更新不会被延误。
请参阅 关于 Dependabot 自动分类规则 和 管理依赖项更新的所有拉取请求。
轮换密钥并强制设定过期时间
凭据存在的时间越长，公开或被盗的机会就越大。 在可能的情况下：
- 在personal access tokens上设置到期日期。
- 定期轮换机密。
有关管理令牌的信息，请参阅 管理个人访问令牌 和 令牌过期和吊销。
后续步骤
- 即使实施强有力的预防控制，安全事件仍可能发生。 应提前设置几个关键工具和响应过程。 请参阅“准备应对安全事件”。