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

关于本指南

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

风险是什么？

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

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

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

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

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

创建依赖项清单。
了解依赖项中何时存在安全漏洞。
对拉取请求强制实施依赖项审查。
评估该漏洞对代码的影响，并决定要执行的操作。

自动生成清单

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

自动检测依赖项中的漏洞

Dependabot 可以帮助你监视依赖项，并在它们包含已知漏洞时通知你。甚至可以启用 Dependabot 自动引发拉取请求，将依赖项更新到安全版本。有关更多信息，请参阅“关于 Dependabot 警报”和“关于 Dependabot 安全更新”。

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

依赖项审查操作对拉取请求强制实施依赖项审查，从而方便你查看拉取请求是否会将易受攻击的依赖项版本引入存储库。检测到漏洞时，依赖项审查操作可能会阻止拉取请求合并。有关详细信息，请参阅“关于依赖项评审”。

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

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

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

保护通信令牌

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

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

Note

Secret scanning 可用于以下存储库：

公共存储库（免费）
使用启用了 GitHub Advanced Security 的 GitHub Enterprise Cloud 的组织中的专用存储库和内部存储库
GitHub Enterprise Cloud 的用户拥有的存储库，包含 Enterprise Managed Users

GitHub 与许多提供商合作，自动检测何时将机密提交到你所依赖的公共存储库和公共 npm 包中或存储在其中，并将通知提供商，以便他们可以采取适当措施来确保帐户保持安全。有关详细信息，请参阅“关于机密扫描警报”。

如果组织使用 GitHub Advanced Security，则可以对组织拥有的任何存储库（包括专用存储库）启用用户的机密扫描警报。此外，用户的机密扫描警报可（在用户自有的存储库中为公共预览版）用于具有 Enterprise Managed Users 的 GitHub Enterprise Cloud。

还可以定义自定义模式来检测存储库、组织或企业级的其他机密。有关详细信息，请参阅“关于机密扫描警报”。

保护 GitHub Enterprise Cloud 中使用的机密存储

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

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