2 构建管道
本节包含了组织开发应用程序时，管理构建管道的安全建议。
构建管道是一组指令，专门用于针对源代码的原始文件，并在其上运行一系列任务，以实现输出最终工件。该工件表示软件最新版本的最终形式，随后被打包以方便存储、处理和部署。构建管道是发生编译过程的环境、编排该过程的管道文件以及与之相关的所有指令集的总称。
2.1 构建环境
本节包含构建管道环境的安全建议。
构建环境是与组织构建工件的基础设施相关的所有东西——编排器、管道执行程序，构建工作人员的工作环境，而管道是在构建环境中运行的一组命令。大多数构建环境建议只与自管理（self-hosted）的构建平台相关，例如CircleCI，它是自管理的。
2.1.1 确保每个管道在构建过程中只承担单一职责
描述
确保每个管道在构建过程中承担单一职责。
说明
构建管道根据他们的目的，通常可以访问多个加密凭证，例如，有测试阶段的测试环境的加密凭证、代码库和构建阶段的工件凭证等等。因此，建议通过划分管道职责来限制对这些凭证/加密凭证的访问，以及为每个阶段设置一个具有最低特权的专用管道，而不是为所有阶段设置一个单一的管道。这将确保对工作流的攻击所造成的任何潜在损害都将受到限制。
审计
对于每个管道，确保它在构建过程中只有一个职责。
补救措施
将每个多责任管道划分为多个管道，每个管道具有最小权限的单一责任。此外，创建所有的新管道的唯一目的是向前。
2.1.2 确保管道基础设施和配置的所有方面都是不可变的
描述
确保管道编排器（orchestrator）及其配置不可变。
说明
不可变基础设施是在管道执行期间不能更改的基础设施。例如，这可以通过使用基础设施即代码来配置管道和管道环境来实现。利用这样的基础设施可以创建一个更可预测的环境，因为更新将需要重新部署，以防止影响任何以前的配置。因为它依赖于自动化，所以更容易恢复更改。测试代码也更简单，因为它基于虚拟化。最重要的是，一个不可变的管道基础设施确保了如果潜在攻击者入侵了构建环境，但无法更改编排器、它的配置和任何其他组件。可以使它们免受恶意篡改的威胁。
审计
验证管道编排器、它的配置和构建环境的所有其他方面都是不可变的。
补救措施
使用不可变的管道编排器，并确保其配置和构建环境的所有其他方面都是不可变的。
2.1.3 确保构建环境有日志记录
描述
保留构建环境的构建日志，详细描述了配置和其中的所有活动。另外，请考虑将它们集中存储。
说明
记录环境日志很重要，主要有两个原因：一是为了调试和调查环境，以防出现bug或安全事件；第二，在需要的时候可以很容易地重现环境。将这些日志集中存储，可以让组织生成有用的见解，并更快地识别构建过程中的异常。
审计
验证构建环境是否被记录日志并集中存储。
补救措施
维护构建环境的日志。例如，为Debian构建工作者使用.buildinfo文件。另外，将日志集中存储。
2.1.4 确保自动化生成构建环境
描述
自动化生成构建环境。
说明
自动化构建环境的部署降低了人为错误的风险，例如错误的配置或敏感数据的暴露，因为需要很少的人为交互和干预。它还简化了环境的重新部署。最好将基础设施作为代码进行自动化，因为它对创建环境配置和存储到版本控制平台的更改提供了更多控制。
审计
验证构建环境的部署是自动化的，并且可以很容易地重新部署。
补救措施
自动化构建环境的部署。
2.1.5 确保对构建环境的访问受到限制
描述
仅限可信和合格的用户访问构建环境(编排器、管道执行器、它们的环境等)。
说明
构建环境包含敏感数据，例如环境变量、加密凭证和源代码本身。任何能够访问此环境的用户都可以对构建过程进行更改，包括对其中的代码进行更改。将访问构建环境的权限限制为受信任和合格的用户，这将减少错误的风险，如暴露加密凭证或错误配置。限制访问还减少了潜在地损害构建环境而容易被劫持的帐户的数量。
注：减少能够访问构建过程的用户数量意味着这些用户将失去对该过程进行直接更改的能力。
审计
验证每个构建环境只有已知和授权的用户才能访问。
补救措施
只有可信和合格的用户才能访问构建环境。
2.1.6确保用户必须通过身份验证才能访问构建环境
描述
要求用户登录访问构建环境，如编排器、管道执行器、构建工作员正在运行的地方等等。
说明
要求用户进行身份验证，并禁用对构建环境的匿名访问，允许组织跟踪该环境上的每个人员的动作，无论好坏。这将有助于识别攻击及其攻击者，因为需要身份验证。
注：匿名用户将无法访问构建环境。
审计
访问构建环境需要保证身份验证。
补救措施
需要身份验证才能访问构建环境，并禁用匿名访问。
2.2构建工作员（build worker）
本节包含对构建工作员的管理和使用的安全建议。
构建工作员通常被称为“运行员（runner）”。它们是管道运行的基础设施。构建工作员很敏感，因为通常他们可以访问多个(如果不是全部的话)软件供应链组件。工作员可以运行具有源代码管理访问权限的代码签出，运行测试，并推送到需要访问它的注册中心。此外，在构建工作程序中运行的一些管道命令可能容易受到攻击，并增大攻击面。所有这些，都说明确保构建工作员受到保护特别重要。
2.2.1 确保构建工作员是单一用途
描述
为每个管道运行使用干净的构建工作员实例。
说明
为每个管道运行使用干净的构建工作员实例可以消除数据盗窃、数据完整性破坏和不可用风险。它限制了管道访问以前运行时存储在文件系统上的数据，而且缓存是不稳定的。这可以防止恶意更改影响其他管道或持续集成/持续交付(CI/CD)系统本身。
注：数据和缓存不会保存在不同的管道运行中。
审计
确保每个正在运行的管道都有自己的干净的、新的运行员。
补救措施
为正在运行的每个管道创建一个干净的构建工作员，或者使用自安装的构建平台运行员，因为它们通常为每次运行提供一个干净的实例。
2.2.2 确保构建员（build worker）环境和命令被传递，而不是被拉取
描述
一个工作员（worker）环境可以被传递(例如，Kubernetes集群中的一个pod，环境变量被传递给它)，它也可以被拉取，就像一个虚拟机正在安装一个包。确保将环境和命令传递给工作员（worker），而不是从中拉取。
说明
传递一个环境意味着额外的配置发生在构建阶段，而不是在运行时。它也会本地传递，而不是远程传递。传递工作员环境，而不是从外部源拉取它，减少了攻击者获得访问权和潜在地将恶意代码拉入其中的可能性。通过本地传递而不是从远程拉取，也减少了基于远程连接的攻击机会，例如中间人或可以从远程运行的恶意脚本。因此，这可以防止可能的感染构建工作员。
审计
对于每个构建工作员（worker），确保传递它的环境和命令，而不是拉取它。
补救措施
对每个构建工作员，传递环境和命令，而不是拉取。
2.2.3 确保隔离每个构建工作员的职责
描述
在构建工作流中隔离职责，如测试、编译、推送工件等，分配给不同的工作员，这样每个工作员只有单一职责。
说明
划分职责并将其分配给许多工作员可以更容易地验证构建过程中的每个步骤，并确保没有代码损坏。它还限制了攻击对构建工作员的影响，因为如果构建工作员的访问权限更少，容易受到伤害的职责更少，那么这种攻击就不那么严重。
审计
对于每个构建工作员，确保他们的职责尽可能少，最好只有一项职责。
补救措施
对于每个构建工作员，将其职责限制在一项工作上。
2.2.4 确保构建工作员具有最小的网络连接
描述
确保构建工作员具有最小的网络连接。
说明
限制构建工作员的网络连接降低了攻击者能够从外部进入组织的可能性。如果构建工作员不受任何限制地连接到公共互联网，攻击者就容易入侵他们。限制构建工作员之间的网络连接还可以保护组织，如果攻击者已经成功，还想将攻击扩散到环境的其他组件时。
注：开发人员将无法从外部连接到他们可能需要的所有资源。工作员（worker）也只能通过共享存储交换数据。
审计
验证构建工作员、环境和任何其他组件只具有所需的最低限度的网络连接。
补救措施
限制构建工作员、环境和任何其他组件的网络连接到必要的最低限度。
2.2.5 确保强制构建工作员的运行时安全性
描述
为构建工作员的操作系统和安装的应用程序添加跟踪，以便在运行时可以分析收集的事件，以检测可疑的行为特征和恶意软件。
说明
构建工作员在运行时容易受到数据泄露攻击、代码注入攻击，以及其他攻击。在构建工作员自身上强制运行时安全来保护它们免受此类攻击很重要。这将实时识别尝试攻击并加以预防。
审计
验证在每个活动的构建工作员（worker）上强制执行了运行时安全解决方案。
补救措施
在构建工作员上部署并强制执行运行时安全解决方案。
2.2.6 确保自动扫描构建工作员漏洞
描述
扫描构建工作员的漏洞。建议自动完成此操作。
说明
漏洞自动扫描检测使用中环境源的已知弱点，如docker镜像或内核版本。如果不尽快替换这些环境，这些漏洞可能会导致大规模的破坏，因为攻击者也知道这些漏洞，并经常试图利用它们。设置自动扫描环境源，确保如果任何新的漏洞被发现，它可以快速和容易地替换。这可以保护工作员不受攻击。
审计
对于每个构建工作员，确保对它使用的环境源做漏洞扫描。
补救措施
对于每个构建工作员，自动扫描环境源的漏洞，如docker镜像。
2.2.7 确保构建工作员（worker）的部署配置存储在版本控制平台中
描述
将构建工作员（worker）的部署配置存储在版本控制平台中，如Github。
说明
构建工作员是构建阶段的敏感部分。他们通常可以访问代码库、持续集成平台、部署平台等。这意味着获得构建工作员访问权的攻击者可能危及组织中的其他平台，并导致重大事件。可以保护工作员的一件事是确保他们的部署配置是安全和配置良好的。将部署配置存储在版本控制中可以使这些配置更具可观察性，因为所有内容都被编目到一个单独的位置。它增加了另一层安全性，每个更改都会被审查和注意到，因此理论上恶意更改发生的次数会减少。在出现错误、bug或安全事件时，它还提供了一种更简单的方法来“恢复”到安全版本或快速添加“热修复补丁”。
注：部署配置的更改只能通过在版本控制平台中声明的方式应用。这可能会减慢开发过程。
审计
验证构建工作者的部署配置是否存储在版本控制平台中。
补救措施
文档化并将构建工作者的每个部署配置存储在版本控制平台中。
2.2.8 确保监控构建工作员的资源消耗
描述
监控构建工作员的资源消耗，并对可能导致资源耗尽的高消耗设置警报。
说明
资源耗尽是指机器资源或服务被大量消耗直到耗尽。资源耗尽可能导致DOS (Denial of Service)。当这样的情况发生在构建工作员部分时，它会减慢甚至停止构建过程，这将损害工件的生产和组织按时交付软件的能力。为了防止这种情况，建议监视构建工作员中的资源消耗，并设置警报，以便在资源高度消耗时通知。这样，就可以在早期阶段发现资源枯竭并加以预防。
审计
验证是否对每个构建工作员的资源消耗进行了监视。
补救措施
设置监控每个构建工作员的资源消耗。
2.3 管道指令
本节包含关于管道指令和命令的安全建议。
管道指令专门用于获取源代码的原始文件，并在其上运行一系列任务，以实现作为输出的最终工件。它们大多是由第三方开发人员编写的，因此应该谨慎对待，在某些情况下也容易受到攻击。管道指令文件被认为是非常敏感的，保护它们的所有的指令、访问等很重要。
2.3.1 确保所有构建步骤都定义为代码
描述
为构建管道及其定义的步骤，使用管道即代码。
说明
在版本控制系统中存储管道指令作为代码，意味着构建步骤的自动化和减少可能会导致安全漏洞的人为错误，此外，它还创建了恢复到以前的管道配置的能力，以便在发生恶意事件时发现受影响的更改。
审计
验证所有构建步骤都定义为代码并存储在版本控制系统中。
补救措施
将管道指令转换为基于代码的语法，并将它们上传到组织的版本控制平台。
2.3.2确保每个步骤都明确定义了构建阶段的输入和输出
描述
为每个构建阶段定义了明确的预期输入和输出。
说明
为了对构建管道中的数据流有更多的控制，要清楚地定义管道步骤的输入和输出。如果在构建阶段发生了任何恶意的事情，它将更容易被识别出来，标为异常。
审计
对于每个构建阶段，验证预期的输入和输出是否被清楚地定义。
补救措施
对于每个构建阶段，明确定义预期的输入和输出。
2.3.3 确保输出被写入分开的、安全的代码库
描述
将管道输出工件写入安全的代码库。
说明
为了安全地维护输出工件并减少潜在的攻击面，将这些工件分开存储在安全代码库中。这种隔离强制单一责任原则，确保编排平台不会与工件存储在一起，这减少了攻击的潜在危害。使用与输入(例如，源代码)相同的安全考虑因素将保护存储的工件，并使恶意行为者更难成功地执行攻击。
审计
对于每个生产输出工件的管道，确保它们被写入一个安全的代码库。
补救措施
对于每个产生输出工件的管道，将它们写到一个安全的代码库中。
2.3.4 确保跟踪和审查对管道文件的更改
描述
跟踪和审查管道文件的更改。
说明
管道文件是敏感文件。他们有能力访问敏感数据并控制构建过程，因此审查管道文件的更改与验证源代码一样重要。恶意的参与者可以潜在地向这些文件添加有害的代码，这可能导致敏感数据暴露和劫持构建环境或工件。
审计
对于每个管道文件，确保它的更改被跟踪和审查。
补救措施
对于每个管道文件，跟踪它的更改并审查它们。
2.3.5 确保最小化对构建过程触发的访问
描述
限制对管道触发器的访问
说明
构建管道用于多种原因。有些是非常敏感的，比如部署到生产的管道。为了保护环境不受恶意行为或人为错误的影响，如开发人员将缺陷部署到生产环境中，对管道触发应用“最小特权原则”很重要。该原则要求对哪些用户可以运行哪些管道进行限制。它允许只由管理员运行敏感的管道，管理员通常是组织中最受信任和最熟练的成员。
审计
对于正在使用的每个管道，验证只有必要的用户有权限触发它。
补救措施
对于每个正在使用的管道，只授予必要的用户触发它的权限。
2.3.6 确保管道自动扫描错误配置
描述
扫描管道错误配置。建议自动执行此操作。
说明
自动扫描错误配置，检测人为错误和错误配置的任务。这可以保护环境不受此类错误造成的后门的影响，从而为攻击者创造了更容易访问的机会。例如，错误地将凭据配置为持久保存在磁盘上的任务使攻击者更容易窃取它们。这种类型的事件可以通过自动扫描来防止。
审计
对于每个管道，验证它是否自动扫描错误配置。
补救措施
针对每个管道，设置自动错误配置扫描。
2.3.7 确保自动扫描管道漏洞
描述
扫描管道漏洞。建议自动实现。
说明
漏洞自动扫描检测管道指令和组件中的已知漏洞，允许在发现漏洞的情况下更快地进行修补。如果不尽快处理这些漏洞，可能会导致潜在的大规模入侵，因为攻击者可能也知道这些漏洞。
审计
对于每个管道，验证它是否自动扫描漏洞。
补救措施
针对每条管道，设置漏洞自动扫描。
2.3.8 确保安装了扫描器以识别和阻止管道文件中的敏感数据(自动化)
描述
检测和阻止管道中的敏感数据，如机密身份证号、密码等。
说明
管道配置中的敏感数据，例如云提供商凭证或代码库凭证，如果恶意行为者获得了对管道的访问权，他们可以通过漏洞窃取这些信息。为了缓解这种情况，设置扫描器来识别和阻止管道中敏感数据的存在。
审计
对于正在使用的每个管道，验证设置扫描器识别和阻止其中存在敏感数据。
补救措施
对于正在使用的每条管道，设置扫描器，以识别和阻止敏感数据。
2.4 管道完整性
本节包括保持管道完整性的安全建议。
完整性意味着确保管道、它们使用的依赖项和它们的工件都是可信的，都是它们想要成为的样子。确保管道完整性是为了验证在构建管道运行期间运行的每次变更和流程都按照设想。例如，一种方法是将每个依赖项锁定到特定的安全版本。重要的是要持续保护，因为这是与客户建立信任的方式。
2.4.1 确保所有版本中的所有工件都有签名
描述
使用用户或组织的密钥为所有版本中的所有工件签名。
说明
签名工件用于验证它们的完整性和安全性。组织通过确保每个工件都正确签名来表明工件是可以信任的。这个签名的存在也使得潜在的恶意活动更加困难。
审计
确保每个版本中的每个工件都已签名。
补救措施
对于每个版本中的每个工件，验证所有工件都被正确签名。
2.4.2 确保所有在构建过程中使用的外部依赖都是锁定的
描述
外部依赖可能是管道中需要的公共包，或者可能是构建工作员（build worker）使用的公共镜像。在每个构建管道中锁定这些外部依赖项
说明
外部依赖是不受组织控制的代码源。它们可能有意或无意地感染了恶意代码，或存在已知的漏洞，这可能导致敏感数据暴露、数据收集或破坏组织中的信任。将每个外部依赖项锁定到特定的、安全的版本可以提供更多的控制和更少的风险机会。
审计
确保在管道中使用的每个外部依赖都被锁定。
补救措施
对于管道中使用的所有外部依赖项，验证它们是锁定的。
2.4.3 确保使用依赖之前进行了验证
描述
在使用之前验证管道的每个依赖项。
说明
要确保在管道中使用的依赖项是可信的，并且没有被恶意行为者感染(例如Codecov事件)，请在使用依赖项之前验证它们。这可以通过比较依赖项和其在可信源中的校验和来实现。如果出现了差异，表明一个未知的参与者进行了干扰，可能添加了恶意代码。如果使用了这个依赖，它将感染环境，这可能导致大规模的破坏，使组织暴露于数据泄漏等。
审计
对于每个管道中使用的每个依赖，确保它已经过验证。
补救措施
对于每个管道中使用的每个依赖，都进行验证。
2.4.4 确保构建管道创建了可复现的工件
描述
验证构建管道创建了可复现的工件，这意味着当给定相同的输入时，构建管道的工件在每次运行中都是相同的。
说明
可复现的构建是在给定相同的输入数据时生成相同工件的构建。确保构建管道在给定相同的输入时生成相同的工件，以验证没有对工件进行更改。这个操作允许组织相信它的工件仅仅是由经过评审和测试的安全代码构建的，并且没有被污染或贸然更改。
审计
确保构建管道创建可复现的工件。
修复措施
创建构建管道，在给定相同输入的情况下生成相同的工件(例如，不依赖于时间戳的工件)。
2.4.5 确保管道步骤产生软件物料清单(SBOM)
描述
SBOM是一个文件，它指定了软件的每个组件或构建过程。在管道的每次运行后生成一个SBOM。
说明
在管道的每次运行后生成一个SBOM将验证该管道的完整性和安全性。记录管道中的每个步骤或组件角色，可以确保在管道运行期间没有恶意行为。
审计
对于每个管道，确保它在每次运行时产生一个SBOM。
补救措施
对于每个管道，配置它在每次运行时产生一个SBOM。
2.4.6 确保管道步骤对所产生的SBOM签名
描述
SBOM是一个指定软件或构建过程的每个组件的文件。它应该在每次管道运行后生成。生成之后，必须对其进行签名。
说明
SBOM是一个用于验证构建管道的完整性和安全性的文件。签名可以确保文件在交付时没有人篡改。如果有人试图隐藏不寻常的活动，就会产生这种干扰。验证SBOM签名可以检测到这种活动并防止更大的事件。
审计
对于每个管道，确保它在每次运行时都对它产生的SBOM签名。
补救措施
对于每个管道，配置它在每次运行时对其生产的SBOM进行签名。
3 依赖项
本节包含了作为软件构建和发布过程的一部分而引入的各种依赖项的管理的安全建议。它们由进入到应用程序代码或构建管道本身使用的任何内容组成。
依赖项是软件供应链的重要组成部分，因为它们集成到许多重要的阶段中。它们 通常由第三方开发人员编写，可能容易受到某些攻击，例如“log4j”攻击。因此，确保它们及其在供应链中的使用的安全非常重要。
3.1 第三方包
本节包含了使用和管理第三方依赖和包的安全建议。作为各种第三方包的消费者，您需要确保存在一定的条件来信任它们并安全地使用它们。使用第三方包不仅会影响软件，还会影响它的客户，所以仔细检查每一个这些包很重要。
3.1.1 确保第三方工件和开源库是经过验证
描述
确保使用的第三方工件和开源库是可信的和经过验证的。
说明
验证代码中使用的第三方构件是受信任的，在使用之前没有被恶意程序感染。这可以通过将依赖项的校验和与可信源中的校验和进行比较来实现。如果出现差异，这可能是有人干涉并添加了恶意代码的迹象。如果使用这种依赖，它将感染环境，并可能导致大规模破坏，使组织暴露在数据泄漏和更多问题中。
审计
对于每个工件和开源库，确保在使用前进行验证。
补救措施
验证使用中的每个工件和开源库。
3.1.2 确保所有第三方供应商都需要SBOM
描述
SBOM是一个文件，指定软件的每个组件或构建过程。要求每个第三方供应商提供一个SBOM。
说明
每个第三方工件的SBOM有助于确保工件的安全使用和完全兼容。该文件列出了所有重要的元数据，特别是工件的所有依赖项，并允许对每个依赖项进行验证。如果某个依赖项/工件受到攻击或有新的漏洞(例如，“SolarWinds”或甚至“log4j”攻击)，就更容易检测出什么受此事件影响，因为使用中的依赖项都列在SBOM文件中。
审计
对于每个使用的第三方依赖，确保它有一个SBOM。
补救措施
对于每个使用的第三方依赖，要求供应商提供SBOM。
3.1.3 确保构建过程元数据签名是必需的，并经过验证
描述
对所有使用的依赖项，要求并验证构建过程的元数据具有签名。
说明
构建过程的元数据列出了在工件构建期间发生的每一个操作。它用于确保工件在构建过程中没有被破坏，没有恶意代码被注入其中，并且在构建阶段没有添加恶意的依赖项。这在用户和供应商之间建立了信任，即所提供的软件正是所承诺的软件。元数据签名会增加一个校验和，以确保自创建以来没有任何修改，因为当元数据被更改时，该校验和也会更改。使用证书颁发机构对正确的元数据签名进行验证，确认签名是由受信任的实体产生的。
审计
对于每个使用的工件，确保它提供了其构建过程中经过验证和签名的元数据。签名应该是组织签名，并且应该可以由公共证书颁发机构服务器进行验证。
补救措施
对于正在使用的每个工件，要求并验证构建过程的元数据签名。
3.1.4 确保监控开源组件之间的依赖关系
描述
监控，或要求软件供应商监控正在使用的开源组件之间的依赖关系。
说明
监视开源组件之间的依赖关系有助于检测软件是否成为开源组件攻击的受害者。快速检测有助于快速应用修复程序。它还有助于发现与组件使用相关的潜在合规问题。一些依赖可能与组织的策略不兼容，而其他依赖可能具有与组织使用此特定依赖的方式不兼容的软件许可。如果监控依赖项，就可以更快地发现和缓解这种情况，从而潜在地阻止恶意攻击。
审计
对于每个开源组件，确保它的依赖被监控。
补救措施
对于每个开源组件，监控它的依赖项。
3.1.5 确保定义了可信的包管理器和代码库，并对其进行了优先级划分
描述
当拉取一个包时，优先使用可信任的包。
说明
当按名称拉取包时，包管理器可能会在多个包注册中心中查找它，其中一些可能是不可信的或配置糟糕的。如果软件包是从这样一个注册中心拉取的，那么它被证明是恶意的可能性就会更高。为了避免这种情况，请将包配置为从受信任的包注册中心拉取。
审计
对于正在使用的每个包注册中心，确保它是可信的。
补救措施
对于每个要下载的包，配置它从一个可信的来源下载。
3.1.6 确保提供代码的SBOM具有签名
描述
SBOM是一个指定软件的每个组件或构建过程的文件。在使用依赖项时，要求它的SBOM，并确保为验证目的对其进行了签名。
说明
通过确保所提供的软件与所描述的软件一致，没有任何潜在的干扰，SBOM在它的提供者和用户之间建立了信任。一个SBOM签名会为它创建一个校验和，如果SBOM的内容被更改，该校验和将会更改。有了这个校验和，软件用户可以确定在供应链中没有发生任何事情，从而产生对软件的信任。当软件中没有这种信任时，风险面就增加了，因为人们无法知道软件是否有潜在的脆弱性。要求SBOM有签名并对其进行验证可以降低这种风险。
审计
对于提供的每个工件，确保它有一个经过验证的、签名的SBOM。
补救措施
对于所提供的每个工件，要求并验证其供应商签署的SBOM。
3.1.7确保依赖被固定到一个特定的、经过验证的版本
描述
将依赖固定到一个特定的版本。避免使用“最新”标签或宽泛版本。
说明
当使用通配符版本的包，或具有“最新”标签，遇到新的、潜在的恶意包的风险增加。“最新”标签拉取推送到注册中心的最后一个包。这意味着，如果攻击者成功地将一个新的恶意包推送到注册中心中，下一个获取“最新”包的用户将获取该包并面临攻击的风险。同样的规则也适用于通配符版本。假设其中一个使用版本v1.*，它将安装主要版本1的最新版本，这意味着如果攻击者可以推送带有相同版本的恶意包，使用该版本的人将可能受到攻击。通过使用安全的、经过验证的版本，并仅限于此版本，不能拉取其他版本，降低了任何恶意包的风险。
审计
对于使用的每个依赖项，确保某个特定的版本。
补救措施
对于使用的每个依赖项，要限于特定的版本。
3.1.8 确保所有使用的包超过60天
描述
使用超过60天的包。
说明
第三方包是一个主要的风险，因为一个组织不能控制他们的源代码，而且这些包总是有可能是恶意的。因此，对任何第三方或开源软件包，尤其是新软件包保持谨慎是一种很好的做法，直到它们可以被验证为安全使用为止。避免使用新包可以让组织充分检查它、它的维护者和它的行为，并有足够的时间来决定是否使用它。
注：开发者不能使用60天以下的包。
审计
对于每个使用的包，确保它的使用时间超过60天。
补救措施
如果一个包的使用时间少于60天，停止使用它，并寻找另一个解决方案。
3.2 验证包
本节包括管理包验证和检查的安全建议。第三方包和依赖可能会将组织置于危险之中，不仅因为容易受到攻击，而且因为被不恰当地使用和损害软件许可证条件。为了保护软件供应链免受这些危险，验证软件包并理解如何以及是否使用它们很重要。本节的建议涵盖了这个主题。
3.2.1 确保在组织范围内强制依赖使用策略
描述
在组织范围内强制依赖使用策略。例如，不允许使用60天以下的包。
说明
在组织中实施依赖使用策略有助于在整个组织内管理依赖，并确保所有使用都符合安全策略。例如，如果策略限制了可以使用的包管理器，那么执行它将确保每个依赖只从这些包管理器安装，并限制从任何不可信源安装的风险。
审计
验证在整个组织中强制执行依赖项使用策略。
补救措施
在整个组织中强制执行依赖项使用策略。
3.2.2 确保自动扫描包中已知的漏洞
描述
自动扫描每个包中的漏洞。
说明
自动扫描漏洞，检测包和使用中的依赖项中的已知漏洞，当发现一个漏洞时，允许更快的修复。如果不尽快处理这些漏洞，可能会导致大规模的攻击，因为攻击者也会知道这些漏洞，并迅速试图利用它们。定期扫描包的漏洞也可以验证是否符合组织的安全策略。
审计
确保启用了自动扫描包中的漏洞。
补救措施
设置自动扫描软件包漏洞。
3.2.3 确保自动扫描软件包许可证类型
描述
软件许可证是为软件的使用和分发提供法律条件和指导方针的文件，通常由作者定义。建议自动扫描任何法律上的牵连。
说明
当使用带有软件许可证的软件包时，特别是那些往往是最严格的商业软件包时，验证软件包的使用是否满足许可的条件是很重要的。如果软件包的使用违反了许可协议，它将使组织面临可能的诉讼。扫描使用的包以寻找此类许可的影响，可以更快地检测和修复此类违规行为，还可以减少诉讼的风险。
审计
确保已配置并自动扫描许可证影响规则。
补救措施
设置自动包扫描的许可证影响。
3.2.4 确保自动扫描每个包的所有权变更
描述
自动扫描每个包的所有权变更。
说明
包所有权的更改不是常规操作。在某些情况下，它会导致大量问题(例如“事件流”事件)。开源贡献者不是总被信任的，因为它的本质是每个人都可以贡献。这意味着恶意行为者也会成为贡献者。如果维护包的工作太繁重，包维护者可能会将他们的所有权转移到他不认识的其他人。在过去这已经导致了已知的安全漏洞。一旦发生此类活动，就应立即意识到，并仔细检查继续使用包装的情况，以确定其安全性。
审计
确保设置自动扫描包的所有权变更
补救措施
设置自动扫描包的所有权变更。
（完）
原文始发于微信公众号（安全行者老霍）：CIS 软件供应链安全指南v1.0（中）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论