Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

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

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

关于本指南

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

风险是什么?

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

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

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

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

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

  1. 创建依赖项清单。

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

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

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

自动生成清单

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

自动检测依赖项中的漏洞

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

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

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

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

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

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

保护通信令牌

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

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

注意: Secret scanning 可用于 GitHub Enterprise Server 中的组织拥有的存储库。 有关详细信息,请参阅“关于 GitHub Enterprise Server 上的 secret scanning”和“关于 GitHub Advanced Security”。

注意:站点管理员必须为 your GitHub Enterprise Server instance 启用 secret scanning,你才能使用这些功能。 有关详细信息,请参阅“为设备配置 secret scanning”。

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

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

除了代码,你可能还需要在其他地方使用机密。 例如,允许 GitHub Actions 工作流或 Dependabot 与其他系统通信。 有关如何安全地存储和使用机密的详细信息,请参阅“操作中的加密机密”和“管理 Dependabot 的加密机密

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

注意: Code scanning 可用于 GitHub Enterprise Server 中的组织拥有的存储库。 此功能需要 GitHub Advanced Security 的许可证。 有关详细信息,请参阅“关于 GitHub Advanced Security”。

注意:网站管理员必须为 your GitHub Enterprise Server instance 启用 code scanning,然后你才能使用此功能。 有关详细信息,请参阅“为设备配置 code scanning”。

创建拉取请求评审过程

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

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

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

后续步骤