保护供应链中的代码的最佳做法

有关如何保护供应链中心的指导 - 你编写的代码和所依赖的代码。

在本文中

关于本指南

本指南介绍为提高代码的安全性而做出的影响最大的更改。 每个部分都概述了可以对流程进行的更改，以提高安全性。 影响最大的更改列在前面。

风险是什么？

开发过程中的主要风险包括：

  • 使用存在安全漏洞的依赖项，攻击者可能利用该安全漏洞。
  • 身份验证凭据或令牌泄露，攻击者可利用它们来访问你的资源。
  • 在自己的代码中引入攻击者可能会利用的漏洞。

这些风险会使你的资源和项目受到攻击，并且这些风险直接传递给使用你创建的包的任何人。 以下部分介绍如何保护自己和用户免受这些风险的影响。

为依赖项创建漏洞管理程序

可以通过为依赖项创建漏洞管理程序来保护所依赖的代码。 概括而言，这应该包括确保执行以下操作的流程：

  1. 创建依赖项清单。

  2. 了解依赖项中何时存在安全漏洞。

  3. 对拉取请求强制实施依赖项审查。

  4. 评估该漏洞对代码的影响，并决定要执行的操作。

自动生成清单

首先需要创建依赖项的完整清单。 存储库的依赖项关系图显示受支持生态系统的依赖项。 如果签入依赖项或使用其他生态系统，则需要使用第三方工具的数据来补充，或手动列出依赖项。 如果至少具有对存储库的读取访问权限，则可以通过 GitHub UI 或 GitHub REST API，将存储库的依赖项关系图导出为与 SPDX 兼容的软件物料清单 (SBOM)。 有关详细信息，请参阅“导出存储库的软件物料清单”。

自动检测依赖项中的漏洞

          Dependabot 可以通过监视依赖项并在依赖项包含已知漏洞时通知你。 甚至可以启用 Dependabot 自动创建将依赖项更新为安全版本的拉取请求。 有关详细信息，请参阅 [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) 和 [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)。

自动检测拉取请求中的漏洞

这会对你的拉取请求强制进行依赖性审查，使你能够轻松查看拉取请求是否会向存储库引入易受攻击的依赖项版本。 检测到漏洞时， 依赖项审查操作 可以阻止拉取请求合并。 有关详细信息，请参阅“关于依赖项评审”。

评估易受攻击的依赖项的风险

当发现使用的是易受攻击的依赖项（例如库或框架）时，必须评估项目的暴露级别并确定要执行的操作。 漏洞报告通常带有严重性分数，以显示其影响的严重程度。 严重性分数是一个有用的指南，但无法告诉你漏洞对代码的全部影响。

要评估漏洞对代码的影响，还需要考虑如何使用库并确定该库实际对系统构成的风险。 也许漏洞是你不使用的功能的一部分，你可以更新受影响的库并继续使用正常的发布周期。 或者，你的代码可能暴露在风险中，你需要更新受影响的库并立即交付更新的生成。 此决定取决于你在系统中使用库的方式，并且只有你知晓如何做出这个决定。

保护通信令牌

代码通常需要通过网络与其他系统通信，并需要机密（如密码或 API 密钥）进行身份验证。 系统需要访问这些机密才能运行，但最佳做法是不要将它们包含在源代码中。 这对于许多用户都有权访问的存储库尤其重要，对公共存储库至关重要。

自动检测提交到存储库的机密

注意

Secret scanning 可用于以下存储库类型：

公共存储库：Secret scanning 自动且免费地运行。

  •           **组织拥有的私有和内部存储库**：在 GitHub Team 或 GitHub Enterprise Cloud 上启用 [GitHub Secret Protection](/get-started/learning-about-github/about-github-advanced-security) 后可用。

用户拥有的存储库：在 GitHub Enterprise Cloud 上可用，配合 Enterprise Managed Users。 当企业启用了 GitHub Secret Protection 时，可在 GitHub Enterprise Server 上使用。

          GitHub 与多个提供商合作，以自动检测机密信息何时被提交到或存储在你的公共存储库和你依赖的公共 npm 包中，并通知提供商，以便他们可以采取适当措施确保帐户安全。 有关详细信息，请参阅“[AUTOTITLE](/code-security/secret-scanning/managing-alerts-from-secret-scanning/about-alerts##about-partner-alerts)”。

可以启用和配置额外的扫描，以在您拥有GitHub时提醒您有关意外泄露的机密。

  • 公共仓库。
  • 一个使用 GitHub Team 或 GitHub Enterprise Cloud 并拥有 GitHub Secret Protection or GitHub Advanced Security 许可证的组织。 Secret scanning 将还分析您的私有存储库。

在GitHub上安全存储所使用的机密信息

除了代码，你可能还需要在其他位置使用机密。 例如，若要允许 GitHub Actions 工作流、Dependabot 或 GitHub Codespaces 开发环境与其他系统通信。 有关如何安全存储和使用机密的详细信息，请参阅 在 GitHub Actions 中使用机密、为 Dependabot 配置对专用注册表的访问权限 和 管理 GitHub Codespaces 的账户专属的机密。

将易受攻击的编码模式排除在存储库之外

注意

Code scanning 可用于以下存储库类型：

  • GitHub.com 上的公共存储库
  • GitHub Team、GitHub Enterprise Cloud 或 GitHub Enterprise Server 上的组织拥有的存储库，已启用 GitHub Code Security。

创建拉取请求评审过程

可以通过确保在合并拉取请求之前对其进行评审和测试，提高代码的质量和安全性。 GitHub 有许多可用于控制审阅和合并过程的功能。 要开始操作，请参阅 关于受保护分支。

扫描代码中易受攻击的模式

审阅者通常很难在没有辅助的情况下发现不安全的代码模式。 除了扫描代码中的机密之外，还可以检查它是否有与安全漏洞关联的模式。 例如，一个非内存安全的函数，或者无法转义用户输入，可能会导致注入漏洞。 GitHub 提供了多种不同的方法来决定扫描代码的方式和时间。 要开始操作，请参阅 关于代码扫描。

后续步骤

  •         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)

  •         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)

  •         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)