# 安全使用指南

编写工作流和使用 GitHub Actions 功能的安全做法。

在编写工作流和使用 GitHub Actions 安全功能时，查找有关安全最佳做法的信息。

## 撰写工作流程

### 对敏感信息使用机密

但是，由于机密值可以通过多种方式转换，因此不能保证自动修订。 请遵循以下最佳做法来限制与机密相关的风险。

* ```
          **最低权限原则**
  ```
  * 对存储库具有写入访问权限的任何用户都有存储库中配置的所有机密的读取访问权限。 因此，应确保工作流中使用的凭据具有所需的最低权限。
  * Actions 可以从 `GITHUB_TOKEN` 上下文访问 `github.token` 来使用它。 有关详细信息，请参阅“[上下文参考](/zh/enterprise-cloud@latest/actions/learn-github-actions/contexts#github-context)”。 因此，应确保向 `GITHUB_TOKEN` 授予所需的最低权限。 将 `GITHUB_TOKEN` 的默认权限设置为只读取存储库内容是良好的安全做法。 然后可以根据需要增加工作流程文件中个别任务的权限。 有关详细信息，请参阅“[在工作流中使用 GITHUB\_TOKEN 进行身份验证](/zh/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)”。
* ```
          **屏蔽敏感数据**
  ```
  * 敏感数据绝不能以明文存储在工作流文件中\*\*\*\*。 使用 `::add-mask::VALUE` 屏蔽所有非 GitHub 机密的敏感信息。 这会导致值被视为机密并从日志中隐藏。 有关屏蔽数据的详细信息，请参阅“[GitHub Actions 的工作流命令](/zh/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#masking-a-value-in-a-log)”。
* ```
          **删除和轮换公开的机密**
  ```
  * 工作流运行器执行机密的修订。 这意味着只有当密钥在作业中使用且可被运行器访问时，才会对其进行脱敏处理。 如果将未修订的机密发送到工作流运行日志，则应删除日志并轮换机密。 有关删除日志的信息，请参阅“[使用工作流运行日志](/zh/enterprise-cloud@latest/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#deleting-logs)”。
* 切勿将结构化数据用作机密
  * 结构化数据可能导致日志中的密码编校失败，因为编校很大程度上取决于查找特定密码值的完全匹配项。 例如，不要使用 JSON、XML 或 YAML（或类似）的 Blob 来封装密码值，否则会显著降低密码被正确编校的可能性。 而应为每个敏感值创建单独的密码。
* 注册工作流中使用的所有机密
  * 如果机密用于生成工作流中的另一敏感值，则该生成值应正式[注册为机密](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)，以便在它出现在日志中时对其进行编辑。 例如，如果使用私钥生成签名的 JWT 来访问 Web API，请确保将该 JWT 注册为密码，否则，如果它进入日志输出，则不会得到编校。
  * 注册密码也适用于任何类型的转换/编码。 如果以某种方式（如 Base64 或 URL 编码）转换您的密码，请确保将新值也注册为密码。
* 审核机密的处理方式
  * 审查密钥的使用方式，以帮助确保按预期方式进行处理。 你可以通过检查执行工作流程的仓库的源代码并检查工作流程中使用的任何操作来进行审核。 例如，确认它们未发送到未预期的主机，或被明确地记录到日志输出中。
  * 在测试有效/无效输入后查看工作流程的运行日志，并确认密码已正确编校或未显示。 调用的命令或工具向 `STDOUT` 和 `STDERR` 发送错误的方式并不总是很明显，并且机密随后可能会出现在错误日志中。 因此，在测试有效和无效的输入后，最好是手动查看工作流程日志。 有关如何清理可能无意中包含敏感数据的工作流日志的信息，请参阅“[使用工作流运行日志](/zh/enterprise-cloud@latest/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#deleting-logs)”。
* ```
          **审核并轮换已注册机密**
  ```
  * 定期查查已注册的密码，以确认它们仍是必需的。 删除不再需要的密码。
  * 定期轮换密码，以减小泄露的密码有效的时间窗。
* ```
          **考虑要求对访问机密进行审查**
  ```
  * 您可以使用所需的审查者来保护环境机密。 在审查者批准之前，工作流程作业无法访问环境机密。 有关在环境中存储机密或需要审查环境的详细信息，请参阅“[在 GitHub Actions 中使用机密](/zh/enterprise-cloud@latest/actions/security-guides/using-secrets-in-github-actions)”和“[管理部署环境](/zh/enterprise-cloud@latest/actions/deployment/targeting-different-environments/managing-environments-for-deployment)”。

### 减少脚本注入攻击的良好做法

缓解工作流中脚本注入风险的推荐方法：

#### 使用操作而不是内联脚本

建议的方法是创建一个 JavaScript 操作，将上下文值作为参数处理。 此方法不易受到注入攻击，因为上下文值不用于生成 shell 脚本，而是作为参数传递给该操作：

```yaml
uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}
```

#### 使用中间环境变量

对于内联脚本，处理不信任输入的首选方法是将表达式的值设置为中间环境变量。 以下示例使用 Bash 将 `github.event.pull_request.title` 值处理为环境变量：

```yaml
      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi
```

在此示例中，尝试的脚本注入失败，日志中的以下行反映了这一点：

```shell
   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'
```

使用此方法，`${{ github.event.pull_request.title }}` 表达式的值存储在内存中用作变量，并且不与脚本生成过程交互。 此外，考虑使用双引号 shell 变量来避免[单词拆分](https://github.com/koalaman/shellcheck/wiki/SC2086)，但这是写入 shell 脚本的[众多一般建议之一](https://mywiki.wooledge.org/BashPitfalls)，并且不是专门针对 GitHub Actions 的。

#### 针对 code scanning 使用工作流模板

通过 Code scanning，可在安全漏洞进入生产阶段之前发现这些漏洞。 GitHub 为 code scanning 提供工作流模板。 您可以使用这些建议的工作流程来构建 code scanning 工作流程，而不是从头开始。 GitHub 的工作流 CodeQL 分析工作流程 由 CodeQL 提供支持。 还有第三方工作流模板可用。

有关详细信息，请参阅 [关于代码扫描](/zh/enterprise-cloud@latest/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning) 和 [配置代码扫描的高级设置](/zh/enterprise-cloud@latest/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions)。

#### 限制令牌权限

为了帮助降低暴露令牌的风险，请考虑限制分配的权限。 有关详细信息，请参阅“[在工作流中使用 GITHUB\_TOKEN 进行身份验证](/zh/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)”。

## 降低不受信任的代码检出风险

与脚本注入攻击类似，自动触发操作处理的不受信任拉取请求内容也可能构成安全风险。
`pull_request_target` 和 `workflow_run` 工作流触发器在与不受信任的拉取请求检出一起使用时，会使仓库面临安全漏洞。 这些工作流具有特权，这意味着它们与其他特权工作流触发器共享主分支的同一缓存，并且可能具有仓库写入权限以及访问引用机密的权限。 这些漏洞可能会被利用来接管仓库。

有关这些触发器的详细信息、使用方法以及相关风险，请参阅 [触发工作流的事件](/zh/enterprise-cloud@latest/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target) 和 [触发工作流的事件](/zh/enterprise-cloud@latest/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run)。

有关不受信任的代码检出风险的更多示例和指导，请参阅 GitHub Security Lab 的[防止 pwn 请求](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)和 OpenSSF Scorecard 的[危险工作流](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow)文档。

### 较好做法

* 如果并非必要，请避免使用 `pull_request_target` 工作流触发器。 对于工作流之间的特权分离，`workflow_run` 是更好的触发器。 仅在工作流实际需要特权上下文时才使用这些工作流触发器。

* 避免将 `pull_request_target` 和 `workflow_run` 工作流触发器与不受信任的拉取请求或代码内容一起使用。 使用这些触发器的工作流不得显式检出不受信任的代码，包括来自拉取请求分支或不受你控制的仓库的代码。 在 `workflow_run` 上触发的工作流应谨慎处理从其他工作流上传的项目。

* CodeQL 可以扫描并检测可能存在漏洞的 GitHub Actions 工作流。 你可以为仓库配置默认设置，并确保启用 GitHub Actions 扫描。 有关详细信息，请参阅“[配置代码扫描的默认设置](/zh/enterprise-cloud@latest/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning)”。

* OpenSSF Scorecards 可以帮助你在使用 GitHub Actions 时识别可能存在漏洞的工作流以及其他安全风险。 请参阅本文后面的[使用 OpenSSF Scorecards 保护工作流依赖项](#using-openssf-scorecards-to-secure-workflow-dependencies)。

## 使用第三方操作

工作流程中的个别作业可以与其他作业相互作用（和妥协）。 例如，查询以后作业使用的环境变量，将文件写入以后作业处理的共享目录，或者更直接地与 Docker 套接字接交互，以及检查其他正在运行的容器并执行其中的命令。

这意味着工作流中单一操作的泄露可能很严重，因为这个泄露的操作可以访问存储库中配置的所有机密，并且可以使用 `GITHUB_TOKEN` 写入存储库。 因此，从 GitHub 上的第三方仓库获取操作的风险很大。 若要了解攻击者可能采取的某些步骤，请参阅“[安全使用指南](/zh/enterprise-cloud@latest/actions/security-guides/security-hardening-for-github-actions#potential-impact-of-a-compromised-runner)”。

您可以遵循以下良好做法来帮助降低此风险：

* ```
          **将操作固定到全长提交 SHA**
  ```

  将操作固定到全长提交 SHA 是当前将操作用作不可变版本的唯一方法。 固定到特定 SHA 有助于降低恶意执行者向操作仓库添加后门的风险，因为他们需要为有效的 Git 对象负载生成 SHA-1 冲突。 选择 SHA 时，应验证它是否来自操作的存储库，而不是存储库分支。

  有关在工作流中使用全长提交 SHA 的示例，请参阅“[在工作流中使用预编写的构建基块](/zh/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-what-workflows-do/find-and-customize-actions#using-shas)”。

  GitHub 会在仓库、组织和企业级别提供相关策略，要求将操作固定到全长提交 SHA：

  * 如需在仓库级别配置策略，请参阅“[管理存储库的GitHub Actions设置](/zh/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository)”。
  * 如需在组织级别配置策略，请参阅“[禁用或限制组织的 GitHub Actions](/zh/enterprise-cloud@latest/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization)”。
  * 如需在企业级别配置策略，请参阅“[在企业中强制实施GitHub Actions策略](/zh/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#policies)”。

* 审核操作的源代码

  确保操作按照预期处理仓库和密码的内容。 例如，确认密码未发送到非预期主机，或者没有被无意中记录。

* ```
          **只有在信任创建者时，才将操作固定到标签**
  ```

  尽管将提交的 SHA 值固定是最安全的选项，但指定标签更为方便，而且被广泛使用。 如果要指定标记，请确保信任该操作的创建者。 GitHub Marketplace 上的“已验证创建者”徽章是一个有用的信号，因为它表示该操作是由其身份已被 GitHub 验证的团队编写的。 请注意，即使您信任作者，这种方法也存在风险，因为如果恶意执行者获得对存储操作的仓库的访问权限，便可移动或删除标记。

### 重新使用第三方工作流程

上述使用第三方操作的相同原则也适用于使用第三方工作流程。 通过遵循上述相同的良好做法，您可以帮助降低与重用工作流程相关的风险。 有关详细信息，请参阅“[重用工作流](/zh/enterprise-cloud@latest/actions/using-workflows/reusing-workflows)”。

## GitHub 的安全功能

GitHub 提供了许多功能，使代码更安全。 可以使用 GitHub 的内置功能来了解工作流所依赖的操作，确保收到有关所用操作中的漏洞的通知，或自动执行使工作流中的操作保持最新状态的过程。 如果发布和维护操作，则可以使用 GitHub 与社区就漏洞以及如何修复漏洞进行沟通。 有关 GitHub 提供的安全功能的详细信息，请参阅“[GitHub安全功能](/zh/enterprise-cloud@latest/code-security/getting-started/github-security-features#about-githubs-security-features)”。

### 使用 `CODEOWNERS` 监视更改

可以使用 `CODEOWNERS` 功能来控制更改工作流文件的方式。 例如，如果所有的工作流文件都存储在 `.github/workflows` 中，可以将此目录添加到代码所有者列表，这样对这些文件的任何提议的更改都首先需要得到指定审阅者的批准。

有关详细信息，请参阅“[关于代码所有者](/zh/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)”。

### 管理组织中 GitHub Actions 设置的权限

通过管理自定义组织角色，使用 GitHub Actions 来践行组织的 CI/CD 流水线的最低权限原则。 自定义组织角色是为组织中的个人或团队授予控制特定设置子集的方法，而不用授予组织及其存储库完整管理员控制。

对于 GitHub Actions，可以为组织中的个人或团队启用以下任何权限。

* **管理组织操作策略：** 访问以管理“操作常规”设置页上的所有设置，但自托管运行器设置除外。
* **管理组织运行器和运行器组：** 访问并创建和管理 GitHub 托管的运行器、自托管运行器和运行器组，并控制可以创建自托管运行器的位置。
* **管理组织操作机密**：访问并创建和管理操作组织机密。
* **管理组织操作变量**：访问并创建和管理操作组织变量。

有关详细信息，请参阅“[自定义组织角色的权限](/zh/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)”。

### 使用 OpenID Connect 访问云资源

如果 GitHub Actions 工作流需要访问支持 OpenID Connect (OIDC) 的云提供商提供的资源，则可以将工作流配置为直接向云提供商进行身份验证。 这样就可以停止将这些凭据存储为长期存在的机密，并提供其他安全优势。 有关详细信息，请参阅“[OpenID Connect](/zh/enterprise-cloud@latest/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)”。

> \[!NOTE]
> AWS 不支持 OIDC 的自定义声明。

### 使用 Dependabot version updates 使操作保持最新

可使用 Dependabot 来确保对存储库中使用的操作和可重用工作流的引用保持最新。 操作通常使用漏洞修复和新功能进行更新，以使自动化流程更快速、更安全、更可靠。 Dependabot 使你无需维护依赖项，因为其会自动执行此操作。 有关详细信息，请参阅 [使用 Dependabot 保持操作的最新状态](/zh/enterprise-cloud@latest/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot) 和 [关于 Dependabot 安全更新](/zh/enterprise-cloud@latest/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)。

### 允许工作流访问内部和专用存储库

如果使专用存储库可供其他存储库中的 GitHub Actions 工作流访问，则其他存储库中的外部协作者可以间接访问专用存储库，即使他们没有直接访问这些存储库的权限。 当使用来自专用存储库的操作或工作流时，外部协作者可以查看工作流运行的日志。 有关详细信息，请参阅“[与企业共享操作和工作流](/zh/enterprise-cloud@latest/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise)”。

为了允许运行器下载这些操作，GitHub 向运行器传递一个作用域内的安装令牌。 此令牌具有对存储库的读取访问权限，会在一小时后自动过期。

### 阻止 GitHub Actions 创建或批准拉取请求

可选择允许或阻止 GitHub Actions 工作流创建或审批拉取请求。 如果在没有适当监督的情况下合并拉取请求，允许工作流或任何其他自动化来创建或批准拉取请求都可能会带来安全风险。

有关如何配置此设置的更多信息，请参阅 “[在企业中强制实施GitHub Actions策略](/zh/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#preventing-github-actions-from-creating-or-approving-pull-requests)”、“[为组织禁用或限制 GitHub Actions](/zh/enterprise-cloud@latest/github/setting-up-and-managing-organizations-and-teams/disabling-or-limiting-github-actions-for-your-organization#preventing-github-actions-from-creating-or-approving-pull-requests)”和“[管理存储库的GitHub Actions设置](/zh/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests)”。

### 使用 code scanning 保护工作流

Code scanning 可自动检测 GitHub Actions 工作流中使用的常见易受攻击模式并建议相应的改进。
有关如何启用 code scanning 的详细信息，请参阅 [配置代码扫描的默认设置](/zh/enterprise-cloud@latest/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning)。

### 使用 OpenSSF 记分卡保护工作流依赖项

```
          [记分卡](https://github.com/ossf/scorecard)是一种自动化安全工具，可标记有风险的供应链做法。 可以使用[记分卡操作](https://github.com/marketplace/actions/ossf-scorecard-action)和[工作流模板](https://github.com/actions/starter-workflows)来遵循最佳安全做法。 配置完成后，记分卡操作将针对存储库更改自动运行，并使用内置的 code scanning 体验提醒开发人员有关有风险的供应链实践。 记分卡项目运行许多检查，包括脚本注入攻击、令牌权限和固定操作。
```

### GitHub 托管的运行器强化

GitHub 托管的运行器会采取措施，帮助降低安全风险。

#### 查看 GitHub 托管运行器的供应链

对于由 GitHub 维护的映像创建的 GitHub 托管的运行器，可以查看软件物料清单 (SBOM)，以查看运行器上预安装的软件。 你可为用户提供 SBOM，他们可通过漏洞扫描程序运行 SBOM 来验证产品是否存在任何漏洞。 如果要生成项目，可将此 SBOM 包含在物料清单中，以获取创建软件所需的所有内容的完整列表。

SBOM 适用于 GitHub 维护的 Ubuntu、Windows 和 macOS 运行器映像。 可在 <https://github.com/actions/runner-images/releases> 处的版本资产中找到适用于你的生成的 SBOM。 文件名格式为 `sbom.IMAGE-NAME.json.zip` 的 SBOM 可在每个版本的附件中找到。

对于第三方映像（例如 ARM 支持的运行器映像），可以找到在[`actions/partner-runner-images`存储库](https://github.com/actions/partner-runner-images)映像中包含的软件的详细信息。

#### 拒绝访问主机

GitHub 托管的运行器预配有 `etc/hosts` 文件，可阻止对各种加密货币挖掘池和恶意站点的网络访问。 MiningMadness.com 和 cpu-pool.com 等主机会重新路由到 localhost，因此它们不会带来重大安全风险。有关详细信息，请参阅“[GitHub 托管的运行程序](/zh/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners)”。

### 自托管运行器的强化

**GitHub 托管的**运行器在临时且干净的隔离虚拟机中执行代码，这意味着无法持久危害此环境，也无法获取比引导过程中放入此环境的更多信息。

**自托管** GitHub 运行器不保证在临时干净的虚拟机中运行，工作流中的不可信代码可能会对其造成持久危害。

因此，自托管的运行器几乎[永远不能用于 GitHub 上的公共仓库](/zh/enterprise-cloud@latest/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions)，因为任何用户都可以打开针对仓库的拉取请求并对环境造成损害。 同样，在专用或内部存储库上使用自托管运行器时要谨慎，因为任何可以创建存储库分支并打开拉取请求的人（通常是那些对存储库具有读取访问权限的人）都能够损害自托管运行器环境，包括获得对机密和 `GITHUB_TOKEN` 的访问权限，根据其设置，可以授予对存储库的写入权限。 尽管工作流程可以通过使用环境和必需的审查来控制对环境密钥的访问，但是这些工作流程不是在隔离的环境中运行，在自托管运行程器上运行时仍然容易遭受相同的风险。

企业所有者和组织所有者可以选择允许哪些存储库创建存储库级别的自托管运行器。 拥有“管理组织运行器和运行器组”权限的用户只能选择允许哪些存储库为组织中的存储库创建存储库级自托管运行器。

有关自定义组织角色的详细信息，请参阅“[自定义组织角色的权限](/zh/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)”。

有关详细信息，请参阅 [在企业中强制实施GitHub Actions策略](/zh/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#disabling-repository-level-self-hosted-runners) 和 [禁用或限制组织的 GitHub Actions](/zh/enterprise-cloud@latest/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners)。

在组织或企业级别定义自托管运行器时，GitHub 可将多个仓库中的工作流安排到同一个运行器中。 因此，这些环境的安全危害可能会导致广泛的影响。 为了帮助缩小损害范围，可以通过将自托管运行器组织到单独的组中来创建边界。 你可以限制工作流、组织和存储库对运行器组的访问权限。 有关详细信息，请参阅“[使用组管理对自托管运行程序的访问](/zh/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups)”。

你还应考虑自托管运行器机器的环境：

* 配置为自托管运行器的计算机上存储哪些敏感信息？ 例如，私有 SSH 密钥、API 访问令牌等。
* 计算机是否可通过网络访问敏感服务？ 例如，Azure或 AWS 元数据服务。 此环境中的敏感信息量应保持在最低水平，您应该始终注意，任何能够调用工作流程的用户都有权访问此环境。

某些客户可能会尝试通过实施在每次作业执行后自动销毁自托管运行器的系统来部分降低这些风险。 但是，此方法可能不如预期有效，因为无法保证自托管运行器只运行一个作业。 有些任务将使用机密作为命令行参数，可以在同一运行器上的另一个任务中看到，例如 `ps x -w`。 这可能导致机密泄露。

#### 使用实时运行器

要提高运行器注册安全性，可以使用 REST API 创建临时的实时 (JIT) 运行器。 这些自托管运行器在自动从存储库、组织或企业中删除之前，最多执行一项作业。 有关配置 JIT 运行器的详细信息，请参阅“[自托管运行器的 REST API 终结点](/zh/enterprise-cloud@latest/rest/actions/self-hosted-runners#create-configuration-for-a-just-in-time-runner-for-an-organization)”。

> \[!NOTE]
> 重新使用硬件托管 JIT 运行器可能会暴露来自环境的信息。 使用自动化来确保 JIT 运行器使用干净的环境。 有关详细信息，请参阅“[自托管运行程序参考](/zh/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#using-ephemeral-runners-for-autoscaling)”。

从 REST API 响应获取配置文件后，可以在启动时将其传递给运行器。

```shell
./run.sh --jitconfig ${encoded_jit_config}
```

#### 为自托管运行器规划管理策略

在 GitHub 的层次结构中，可以在不同级别添加自托管运行器：企业级别、组织级别或存储库级别。 此布置决定了谁将能够管理运行器：

集中式管理：

* 如果你计划让一个集中的团队拥有自托管的运行器，则建议在最高的相互组织或企业级别添加你的运行器。 这为您的团队提供了一个统一平台来查看和管理您的跑者。
* 如果你只有一个组织，那么在组织级别添加运行器实际上是相同的方法，但如果将来添加另一个组织，则可能会遇到困难。

分散管理：

* 如果每个团队将管理自己的自托管运行器，则建议将运行器添加到团队所有权的最高级别。 例如，如果每个团队都拥有自己的组织，那么在组织级别添加运行器是最简单的。
* 您还可以在存储库级别添加运行器，但这会增加管理开销，并且还会增加所需的运行器数量，因为您无法在存储库之间共享运行器。

#### 向云提供商进行身份验证

如果您使用 GitHub Actions 部署到云提供商，或者打算使用 HashiCorp Vault 进行机密管理，则建议您考虑使用 OpenID Connect 为工作流程运行创建短期、范围得当的访问令牌。 有关详细信息，请参阅“[OpenID Connect](/zh/enterprise-cloud@latest/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)”。

### 审核 GitHub Actions 事件

可以使用安全日志监视用户帐户活动，并使用审核日志监视组织或企业中的活动。 安全和审核日志记录操作类型、操作的运行时间以及执行操作的个人帐户。

例如，可使用审核日志跟踪 `org.update_actions_secret` 事件，这些事件跟踪组织机密的更改。

![显示在组织的审核日志中搜索“action:org.update\_actions\_secret”的屏幕截图。 显示了两个结果。](/assets/images/help/repository/audit-log-entries.png)

有关可在审核日志中找到的每种帐户类型的完整事件列表，请参阅以下文章：

* ```
          [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/security-log-events)
  ```
* ```
          [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)
  ```
* ```
          [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise)
  ```

### 了解工作流中的依赖项

可以使用依赖项关系图浏览存储库中工作流所使用的操作。 依赖项关系图是存储库中所存储之清单和锁文件的摘要。 它还将 `./github/workflows/` 中文件识别为清单，这意味着使用语法 `jobs[*].steps[*].uses` 或 `jobs.<job_id>.uses` 引用的任何操作或工作流都将解析为依赖项。

依赖项关系图显示了有关工作流中使用的操作的以下信息：

* 负责该操作的帐户或组织。
* 引用操作的工作流文件。
* 操作固定到的版本或 SHA。

在依赖项关系图中，依赖项按漏洞严重程度自动排序。 如果使用的任意操作有安全公告，它将显示在列表顶部。 可以从依赖项关系图导航到公告，并访问用于解决漏洞的说明。

依赖项关系图为公共存储库启用，你可以选择在专用存储库上启用它。 有关使用依赖项关系图的详细信息，请参阅“[探索仓库的依赖项](/zh/enterprise-cloud@latest/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository)”。

### 了解所使用的操作中的安全漏洞

有关市场上可用的操作，GitHub 会审查相关的安全公告，然后将这些公告添加到 GitHub Advisory Database 中。 可以搜索数据库来了解可用于查找现有漏洞信息的操作以及有关修复这些漏洞方式的说明。 若要简化搜索，请在 [GitHub Advisory Database](https://github.com/advisories?query=type%3Areviewed+ecosystem%3Aactions) 中使用 GitHub Actions 筛选器。

您可以设置存储库，以便您可以：

* 在工作流中使用的操作收到漏洞报告时接收警报。 有关详细信息，请参阅“[监视工作流中的操作](#monitoring-the-actions-in-your-workflows)”。
* 在工作流中添加或更新操作时，会收到关于现有警告的通知。 有关详细信息，请参阅“[筛选新工作流或更新工作流中的漏洞操作](#screening-actions-for-vulnerabilities-in-new-or-updated-workflows)”。

#### 监视工作流中的操作

可以使用 Dependabot 监视工作流中的操作，并启用 Dependabot alerts 以便在使用的操作有报告漏洞时通知你。 Dependabot 执行对启用存储库的默认分支扫描，以检测不安全的依赖项。 Dependabot 在向 GitHub Advisory Database 添加新公告或更新所使用的操作时，将生成 Dependabot alerts。

> \[!NOTE]
> Dependabot 仅针对使用语义化版本控制的有漏洞操作创建警报，且不会为固定到 SHA 值的操作创建警报。

可以为个人帐户、存储库或组织启用 Dependabot alerts。 有关更多信息，请参阅 [配置 Dependabot 警报](/zh/enterprise-cloud@latest/code-security/dependabot/dependabot-alerts/configuring-dependabot-alerts)。

可以在存储库的Dependabot标签页中查看所有打开和关闭的Dependabot alerts和相应的Dependabot security updates内容。 有关详细信息，请参阅“[查看和更新 Dependabot 警报](/zh/enterprise-cloud@latest/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts)”。

#### 筛选新工作流或更新工作流中的漏洞操作

开立拉取请求来更新工作流时，最好使用依赖项评审来了解对所用操作所做更改的安全影响。 依赖项审查帮助您了解依赖项变化以及这些变化在每个拉取请求中的安全影响。 它提供了一个易于理解的依赖项变化可视化效果，多差异显示在拉取请求的“更改的文件”选项卡上。 依赖项审查告知您：

* 与发行日期一起添加、删除或更新的依赖项有哪些
* 有多少项目使用这些组件
* 这些依赖项的漏洞数据

如果对工作流所做的任意更改标记为了易受攻击，则可以避免将其添加到项目或将其更新为安全版本。

有关依赖项评审的详细信息，请参阅“[关于依赖项评审](/zh/enterprise-cloud@latest/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review)”。

“依赖项审查操作”指的是可以在 GitHub Actions 上下文中报告拉取请求差异的具体操作。 请参阅 [`dependency-review-action`](https://github.com/actions/dependency-review-action)。 可使用存储库中的 依赖项审查操作 对拉取请求强制实施依赖项审查。 该操作会扫描拉取请求中包版本更改引入的易受攻击的依赖项版本，并警告你相关的安全漏洞。 这样可以更好地了解拉取请求中发生的变化，并帮助防止漏洞添加到存储库中。 有关详细信息，请参阅“[关于依赖项评审](/zh/enterprise-cloud@latest/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#about-the-dependency-review-action)”。

### 确保工作流中的操作安全且为最新版本

可使用 Dependabot 来确保对存储库中使用的操作和可重用工作流的引用保持最新。 操作通常使用漏洞修复和新功能进行更新，以使自动化流程更快速、更安全、更可靠。 Dependabot 使你无需维护依赖项，因为其会自动执行此操作。 有关详细信息，请参阅 [使用 Dependabot 保持操作的最新状态](/zh/enterprise-cloud@latest/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot) 和 [关于 Dependabot 安全更新](/zh/enterprise-cloud@latest/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)。

以下功能可以自动更新工作流中的操作。

* ```
          **Dependabot version updates** 打开拉取请求，以在新版本发布时将动作更新至最新版本。
  ```
* ```
          **Dependabot security updates** 打开拉取请求，将带有所报告漏洞的动作更新为最低修补版本。
  ```

> \[!NOTE]
>
> * Dependabot 仅支持通过使用 GitHub 的存储库语法（如 `actions/checkout@v5` 或 `actions/checkout@<commit>` ）来更新 GitHub Actions 。 Dependabot 将忽略本地引用的操作或可重用工作流（例如，`./.github/actions/foo.yml`）。
> * Dependabot 在注释与同一行的 `actions/checkout@<commit> #<tag or link>` 或 `actions/checkout@<tag> #<tag or link>` 相同时，更新 GitHub Actions 的版本文档。
> * 如果你使用的提交未与任何标签相关联，Dependabot 会将 GitHub Actions 更新至最新的提交（这可能与最新的发布版本不同）。
> * 目前不支持 Docker Hub 和 GitHub Packages Container registry URL。 例如，不支持使用 `docker://` 语法引用 Docker 容器操作。
> * Dependabot 支持 GitHub Actions 的公共存储库和专用存储库。 有关专用注册表配置选项，请参阅“`git`”中的“[](/zh/enterprise-cloud@latest/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#git)”。

有关如何配置 Dependabot version updates 的详细信息，请参阅“[配置 Dependabot 版本更新](/zh/enterprise-cloud@latest/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates)”。

有关如何配置 Dependabot security updates 的详细信息，请参阅“[配置 Dependabot 安全更新](/zh/enterprise-cloud@latest/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates)”。

### 保护已创建的操作

GitHub 可促成发布和维护操作的人员与漏洞报告人员之间的协作，以促进安全编码。 使用存储库安全公告，公共存储库的维护人员可私下讨论和修复项目中的安全漏洞。 协作得到修补程序后，存储库维护人员可发布安全通知，向项目社区公开安全漏洞。 通过发布安全通知，存储库维护人员可使其社区更轻松地更新包依赖项并对安全漏洞的影响进行调查。

如果你是维护其他项目中使用的操作的人，则可以使用以下 GitHub 功能来增强已发布的操作的安全性。

* 使用依赖项关系图中的依赖项视图查看哪些项目依赖于你的代码。 如果收到漏洞报告，这会让你了解需要与谁沟通漏洞以及漏洞修复方式的信息。 有关详细信息，请参阅“[探索仓库的依赖项](/zh/enterprise-cloud@latest/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository#dependents-view)”。
* 使用存储库安全公告创建安全公告，私人协作以修复临时专用分支中的漏洞，并发布安全公告，以便在修补程序发布后向社区提醒该漏洞。 有关详细信息，请参阅 [为存储库配置私人漏洞报告](/zh/enterprise-cloud@latest/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository) 和 [创建存储库安全公告](/zh/enterprise-cloud@latest/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory)。