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 Advanced Security的组织。 请参阅“创建和管理安全活动”。
继续审核访问权限和许可
随着人员加入和离开组织，随着项目的发展，访问要求会发生变化。 安排定期评审：
- 组织成员身份和角色。
- 外部协作者访问权限。
- 存储库级权限和团队分配。
- 已授权的 OAuth 和 GitHub Apps.
这可确保访问与最低特权原则保持一致，即使组织发生更改也是如此。
保持依赖项更新
易受攻击的依赖项是攻击者的常见入口点。 Dependabot 可以自动打开拉取请求以更新具有已知漏洞的依赖项，但这些拉取请求仍需及时查看和合并。
建立分类和合并Dependabot 拉取请求的流程，以确保安全更新不会被延误。
请参阅 关于 Dependabot 自动分类规则 和 管理依赖项更新的所有拉取请求。
轮换密钥并强制设定过期时间
凭据存在的时间越长，公开或被盗的机会就越大。 在可能的情况下：
- 在personal access tokens上设置到期日期。
- 定期轮换机密。
有关管理令牌的信息，请参阅 管理个人访问令牌 和 令牌过期和吊销。
后续步骤
- 即使实施强有力的预防控制，安全事件仍可能发生。 应提前设置几个关键工具和响应过程。 请参阅“准备应对安全事件”。