# 安全使用指南

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

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

## 撰写工作流程

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

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

* **最低权限原则**
  * 对存储库具有写入访问权限的任何用户都有存储库中配置的所有机密的读取访问权限。 因此，应确保工作流中使用的凭据具有所需的最低权限。
  * Actions 可以从 `GITHUB_TOKEN` 上下文访问 `github.token` 来使用它。 有关详细信息，请参阅“[上下文参考](/zh/actions/reference/workflows-and-actions/contexts#github-context)”。 因此，应确保向 `GITHUB_TOKEN` 授予所需的最低权限。 将 `GITHUB_TOKEN` 的默认权限设置为只读取存储库内容是良好的安全做法。 然后可以根据需要增加工作流程文件中个别任务的权限。 有关详细信息，请参阅“[在工作流中使用 GITHUB\_TOKEN 进行身份验证](/zh/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token)”。
* **屏蔽敏感数据**
  * 敏感数据绝不能以明文存储在工作流文件中\*\*\*\*。 使用GitHub对所有不是机密的敏感信息进行掩码`::add-mask::VALUE`。 这会导致值被视为机密并从日志中隐藏。 有关屏蔽数据的详细信息，请参阅“[GitHub Actions 的工作流命令](/zh/actions/reference/workflows-and-actions/workflow-commands#masking-a-value-in-a-log)”。
* **删除和轮换公开的机密**
  * 工作流运行器执行机密的修订。 这意味着只有当密钥在作业中使用且可被运行器访问时，才会对其进行脱敏处理。 如果将未修订的机密发送到工作流运行日志，则应删除日志并轮换机密。 有关删除日志的信息，请参阅“[使用工作流运行日志](/zh/actions/how-tos/monitor-workflows/use-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/actions/how-tos/monitor-workflows/use-workflow-run-logs#deleting-logs)”。
* **审核并轮换已注册机密**
  * 定期查查已注册的密码，以确认它们仍是必需的。 删除不再需要的密码。
  * 定期轮换密码，以减小泄露的密码有效的时间窗。
* **考虑要求对访问机密进行审查**
  * 您可以使用所需的审查者来保护环境机密。 在审查者批准之前，工作流程作业无法访问环境机密。 有关在环境中存储机密或需要审查环境的详细信息，请参阅“[在 GitHub Actions 中使用机密](/zh/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)”和“[管理部署环境](/zh/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)”。

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

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

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

建议的方法是创建一个 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/code-security/concepts/code-scanning/code-scanning) 和 [配置代码扫描的高级设置](/zh/code-security/how-tos/find-and-fix-code-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions)。

#### 限制令牌权限

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

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

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

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

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

有关决定是否使用 `pull_request_target`、强化这些工作流并选择退出 `actions/checkout` 保护的详细指南，请参阅 [安全地使用 pull\_request\_target](/zh/actions/reference/security/securely-using-pull_request_target)。

### 较好做法

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

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

* CodeQL 可以扫描和检测可能易受攻击的 GitHub Actions 工作流。 可以为存储库配置默认设置，并确保已启用 GitHub Actions 扫描。 有关详细信息，请参阅“[配置代码扫描的默认设置](/zh/code-security/how-tos/find-and-fix-code-vulnerabilities/configure-code-scanning/configure-code-scanning)”。

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

## 使用第三方操作

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

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

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

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

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

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

GitHub 会在存储库和组织级别提供相关策略，要求将操作固定到全长提交 SHA：
\* 如需在仓库级别配置策略，请参阅“[管理存储库的GitHub Actions设置](/zh/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/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization)”。

* 审核操作的源代码

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

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

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

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

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

## GitHub 的安全功能

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

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

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

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

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

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

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

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

可用于 Dependabot 确保对存储库中使用的操作和可重用工作流的引用保持最新。 操作通常使用漏洞修复和新功能进行更新，以使自动化流程更快速、更安全、更可靠。
Dependabot 可自动为你完成这项工作，从而省去维护依赖项的麻烦。 有关详细信息，请参阅 [使用 Dependabot 保持操作的最新状态](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/auto-update-actions) 和 [Dependabot 安全更新](/zh/code-security/concepts/supply-chain-security/dependabot-security-updates)。

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

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

有关如何配置此设置的详细信息，请参阅 [为组织禁用或限制 GitHub Actions](/zh/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#preventing-github-actions-from-creating-or-approving-pull-requests)和 [管理存储库的GitHub Actions设置](/zh/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/code-security/how-tos/find-and-fix-code-vulnerabilities/configure-code-scanning/configure-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 运行程序映像，包括 ARM 提供支持的运行程序。 可在 <https://github.com/actions/runner-images/releases> 处的版本资产中找到适用于你的生成的 SBOM。 文件名格式为 `sbom.IMAGE-NAME.json.zip` 的 SBOM 可在每个版本的附件中找到。

#### 拒绝访问主机

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

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

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

**自托管**GitHub 运行程序不能保证在临时干净的虚拟机中运行，并且可能会持续受到工作流中不受信任的代码的损害。

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

所有者可以选择允许哪些存储库创建存储库级自承载运行程序。

有关详细信息，请参阅 [禁用或限制组织的 GitHub Actions](/zh/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners)。

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

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

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

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

#### 使用实时运行器

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

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

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

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

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

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

集中式管理：

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

分散管理：

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

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

如果使用 GitHub Actions 部署到云提供商，或打算使用 HashiCorp Vault 进行机密管理，建议考虑使用 OpenID Connect 为工作流运行创建生存期较短、范围良好的访问令牌。 有关详细信息，请参阅“[OpenID Connect](/zh/actions/concepts/security/openid-connect)”。

### 审核 GitHub Actions 事件

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

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

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

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

* [安全日志事件](/zh/authentication/keeping-your-account-and-data-secure/security-log-events)
* [组织的审核日志事件](/zh/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)

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

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

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

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

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

为公共存储库启用依赖项关系图，可以选择在专用存储库上启用它。 有关使用依赖关系图的详细信息，请参阅 [探索仓库的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/explore-dependencies)。

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

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

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

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

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

可用于 Dependabot 监视工作流中的操作，并在 Dependabot alerts 使用的操作有报告漏洞时通知你。
Dependabot 会扫描已启用该功能的存储库的默认分支，以检测不安全的依赖项。 当新的公告添加到 Dependabot 时，或者当您使用的某个操作已更新时，Dependabot alerts 会生成 GitHub Advisory Database。

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

可以为个人帐户、存储库或组织启用 Dependabot alerts 。 有关详细信息，请参阅 [配置 Dependabot 警报](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-dependabot-alerts)。

可以在存储库的Dependabot alerts标签页中查看所有打开和关闭的Dependabot security updates和相应的Dependabot内容。 有关详细信息，请参阅 [查看和更新 Dependabot 警报](/zh/code-security/how-tos/manage-security-alerts/manage-dependabot-alerts/view-dependabot-alerts)。

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

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

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

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

有关依赖项评审的详细信息，请参阅“[依赖项审查](/zh/code-security/concepts/supply-chain-security/dependency-review)”。

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

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

可用于 Dependabot 确保对存储库中使用的操作和可重用工作流的引用保持最新。 操作通常使用漏洞修复和新功能进行更新，以使自动化流程更快速、更安全、更可靠。
Dependabot 可自动为你完成这项工作，从而省去维护依赖项的麻烦。 有关详细信息，请参阅 [使用 Dependabot 保持操作的最新状态](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/auto-update-actions) 和 [Dependabot 安全更新](/zh/code-security/concepts/supply-chain-security/dependabot-security-updates)。

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

* **Dependabot version updates** 打开拉取请求，以在新版本发布时将操作更新到最新版本。
* **Dependabot security updates**发起拉取请求，将存在已报告漏洞的操作更新到最低已修复版本。

> \[!NOTE]
>
> * Dependabot 仅支持使用 GitHub Actions 仓库语法对 GitHub 进行更新，例如 `actions/checkout@v6` 或 `actions/checkout@<commit>`。
>   Dependabot 将忽略本地引用的操作或可重用工作流（例如， `./.github/actions/foo.yml`）。
> * Dependabot 会在注释与 GitHub Actions 位于同一行时更新其版本文档，例如 `actions/checkout@<commit> #<tag or link>` 或 `actions/checkout@<tag> #<tag or link>`。
> * 如果你使用的提交未关联任何标签，Dependabot 将把 GitHub Actions 更新为最新的提交（这可能与最新发布版本不同）。
> * Docker Hub 和 GitHub PackagesContainer registry URL 目前不受支持。 例如，不支持使用 `docker://` 语法引用 Docker 容器操作。
> * Dependabot 支持公共存储库和专用存储库 GitHub Actions。 有关私有注册表配置选项，请参阅 `git` 中的“[](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#git)”。

有关如何配置 Dependabot version updates的信息，请参阅 [配置 Dependabot 版本更新](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-version-updates)。

有关如何配置 Dependabot security updates的信息，请参阅 [配置 Dependabot 安全更新](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-security-updates)。

### 保护已创建的操作

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

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

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