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

关于本指南

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

风险是什么？

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

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

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

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

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

1. 创建依赖项清单。

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

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

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

自动生成清单

首先需要创建依赖项的完整清单。 存储库的依赖项关系图显示受支持生态系统的依赖项。 如果签入依赖项或使用其他生态系统，则需要使用来自第三方工具的数据或通过手动列出依赖项来作为补充。有关详细信息，请参阅“关于依赖关系图”。

自动检测依赖项中的漏洞

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

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

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

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

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

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

保护通信令牌

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

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

可以将 secret scanning 配置为检查许多服务提供商颁发的机密，并在检测到任何机密时通知你。 还可以定义自定义模式来检测存储库、组织或企业级的其他机密。 有关详细信息，请参阅“关于机密扫描”和“机密扫描模式”。

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

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

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

创建拉取请求评审过程

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

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

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

后续步骤

• "保护端到端供应链"

• "确保帐户安全的最佳做法"

• "保护生成系统的最佳做法"