在DevSecOps CI/CD Pipelines中集成软件供应链安全战略

定义软件开发的安全要求（PO.1）：

确保始终了解软件开发的安全要求，以便在整个SDLC过程中考虑这些要求，并尽量减少重复工作。这包括来自内部来源（例如组织的政策、业务目标和风险管理策略）和外部来源（例如适用法律和法规）的要求。

DEPLOY-REQ-1：对于已在仓库中并准备部署的代码，应调用安全扫描子功能来检测代码中是否存在机密信息，例如密钥和访问令牌。在许多情况下，甚至在填充代码之前，就应该扫描仓库以检查机密是否存在，因为它们在仓库中的存在可能意味着凭据已被泄露，具体取决于仓库的可见性。

DEPLOY-REQ-2：在合并PULL请求之前，应该能够通过依赖关系审查的形式查看任何易受攻击的版本的详细信息。

DEPLOY-REQ-3：如果已经建立了安全的构建环境和相关流程，应该能够指定要部署的工件（即容器镜像）必须由该构建流程生成，才能批准部署。

DEPLOY-REQ-4：检查容器镜像是否已扫描漏洞并提供存在漏洞的证据。

漏洞扫描的一个重要因素是运行时间。由于用于扫描工件的工具会不断更新以检测新出现的漏洞，因此最近的扫描结果更准确，并且比过去的结果更有保证。

这种技术使DevOps团队能够实施主动的容器安全态势监控，确保只有经过验证的容器镜像才能进入环境并在运行时保持可信。具体来说，应该能够根据组织定义的策略允许或阻止镜像部署。

DEPLOY-REQ-5：定期检查发布构建脚本中是否存在恶意代码。要执行的任务包括：

• 容器在构建后应立即扫描漏洞，甚至在将其推送到注册表之前就要扫描。早期扫描功能也可以内置到本地工作流中。

• 用于与包含容器镜像和语言包的仓库交互的工具应该能够与CD工具集成，从而使所有活动成为自动化CD Pipelines中不可或缺的一部分。

定义软件开发的安全要求（PO.1）：

确保始终了解软件开发的安全要求，以便在整个SDLC过程中考虑这些要求，并尽量减少重复工作。这包括来自内部来源（例如组织的政策、业务目标和风险管理策略）和外部来源（例如适用法律和法规）的要求。

激活CI/CD Pipelines的先决条件：

• 为操作各种CI/CD Pipelines的参与者（例如，应用程序更新程序、包管理器、部署专家）定义角色。

• 确定执行各种任务的细粒度授权，例如生成代码并将其提交给SCM、生成构建和包以及将各种工件（例如，构建和包）签入和签出仓库。

实施角色和职责（PO.2）：

确保参与SDLC的组织内部和外部的每个人都准备好在整个SDLC过程中履行与SDLC相关的角色和职责。

整个CI/CD Pipeline必须通过部署适当的工具来实现自动化，这是激活CI/CD Pipelines的先决条件。

CI和CD Pipelines的驱动工具处于更高级别，并调用一系列特定于功能的工具，例如用于从存储库中检出代码、编辑和编译、代码提交和测试的工具（例如，静态应用程序安全测试 [SAST]、动态应用程序安全测试 [DAST] 和软件成分分析 [SCA]）。

通常，驱动工具或构建控制平面比单个功能步骤（例如构建）在更高的信任级别上执行。

实施支持工具链（PO.3）：

使用自动化减少人力投入，提高整个SDLC中安全实践的准确性、可重复性、可用性和全面性，并提供一种方法来记录和展示这些实践的使用情况。

工具链和工具可能在组织的不同级别使用，例如整个组织或特定于项目，并且可能针对SDLC的特定部分，例如构建Pipeline。

代码提交前应执行适当形式的测试，并满足以下要求：

• 应在CI/CD Pipelines中运行SAST和DAST工具（涵盖开发中使用的所有语言），并向开发人员和安全人员提供代码覆盖率报告。

• 如果使用开源模块和库，则必须枚举、理解和评估依赖关系以制定策略（可能使用适当的SCA工具），还必须测试它们应满足的安全条件。依赖文件检测器应检测所有依赖关系，包括传递依赖关系，最好对要分析的嵌套或传递依赖关系的深度没有限制。

定义和使用软件安全检查标准（PO.4）：

通过定义和使用在开发过程中检查软件安全的标准，帮助确保SDLC产生的软件符合组织的期望。

已涵盖在满足PO.1的要求中。

此外，环境认证涉及CI流程发生时的系统清单。它通常是指运行构建流程的平台。该平台必须经过加固、隔离和安全保护。

实施和维护软件开发的安全环境（PO.5）：

确保SDLC环境的所有组件都受到强有力的保护，免受内部和外部威胁，以防止环境或其中的软件受到损害。

SDLC组件的示例包括开发、构建、测试和部署。

SDLC中使用的所有形式的代码都位于仓库中。授权开发人员使用PULL操作从这些仓库中提取代码，进行修改，然后使用PUSH操作将其放回存储库。

要授权这些PULL-PUSH操作，需要进行两种形式的检查：

1. 授权执行PULL-PUSH操作的开发人员所需的身份验证类型。开发人员提出的请求必须与其角色一致（例如，应用程序更新程序、包管理器）。具有“合并批准”权限的开发人员不能批准自己的合并。

2. 存储库中代码的完整性是可信的，以便可以将其用于进一步的更新。

保护所有形式的代码免遭未经授权的访问和篡改（PS.1）：

帮助防止对代码进行未经授权的更改（无论是无意的还是有意的），这些更改可能会规避或否定软件的预期安全特性。

对于不打算公开访问的代码，这有助于防止盗窃，并可能使攻击者更难或更耗时地找到软件中的漏洞。

1. 该框架应提供保护，从而防止所有已知的攻击，这些攻击针对软件更新系统执行的任务，例如元数据（哈希）生成、签名过程、签名密钥管理、执行签名的机构的完整性、密钥验证和签名验证。

2. 该框架应提供一种方法来最小化密钥泄露的影响，即支持具有多个密钥和阈值或法定信任的角色（设计为使用单个密钥的最低信任角色除外）。使用高度易受攻击的密钥的角色的泄露应将影响降至最低。因此，在线密钥（即以自动化方式使用的密钥）不得用于客户端最终信任的任何可能安装文件的角色。当密钥在线时，应格外小心地保管它们，例如将它们存储在HSM中，并且只有在签名的工件满足上文中定义的策略时才允许使用它们。

3. 该框架必须足够灵活，以满足各种软件更新系统的需求。

4. 该框架必须易于与软件更新系统集成。

提供验证软件发布完整性的机制（PS.2）：

帮助软件采购方确保其采购的软件是合法的且未被篡改。

在部署前创建配置数据、捕获与特定版本相关的所有数据、在运行时修改软件以及执行监控操作时，应应用以下SSC安全任务：

• GitOps-REQ-2：促进 GitOps的包管理器应保留已发布的包的所有数据，包括所有模块的版本号、所有相关配置文件以及适用于软件操作环境的其他元数据。

存档和保护每个软件版本（PS.3）：

保留软件版本，以帮助识别、分析和消除发布后在软件中发现的漏洞。

• PULL-PUSH-REQ-1：项目维护者应对PULL请求中涵盖的所有工件运行自动检查，例如单元测试、完整性测试、安全检查等。

• PULL-PUSH-REQ-2：CI Pipelines应仅在对源代码来源的可信度建立信心时才使用外部工具（例如Jenkins）。

• PULL-PUSH-REQ-3：仓库或源代码管理系统（例如GitHub、GitLab）应具有内置保护功能，该保护功能会延迟CI工作流程运行，直到获得具有写访问权限的维护者批准。当外部贡献者向公共仓库提交PULL请求时，此内置保护应生效。此保护的设置应处于最严格的级别，例如“要求所有外部合作者都获得批准”。

• PULL-PUSH-REQ-4：如果源代码管理系统中没有可用的内置保护，则需要具有以下功能的外部安全工具： 

o 评估和增强SCM系统安全态势的功能，无论是否有策略（例如OPA）来评估SCM帐户的安全设置并生成包含可操作建议的状态报告

o 通过检测和修复错误配置、安全漏洞和合规性问题来增强源代码管理系统的安全性的功能

遵守安全编码实践创建源代码（PW.5）：

通过最大限度地减少源代码创建过程中引入的漏洞来减少软件中的安全漏洞数量并降低成本，这些漏洞符合或超过了组织定义的漏洞严重性标准。

环境认证：

环境认证涉及CI流程发生时的系统清单，通常指运行构建流程的平台。平台的组件（例如编译器、解释器）必须得到加固、隔离和安全保护。

配置编译、解释器和构建流程以提高可执行文件安全性（PW.6）：

通过在测试之前消除漏洞来减少软件中的安全漏洞数量并降低成本。

在代码提交之前应执行适当形式的测试，并且必须满足以下要求：

• CI/CD Pipelines中使用的SAST和DAST工具都必须覆盖云原生应用程序中使用的不同语言系统。

• 如果使用开源模块和库，则必须使用适当的SCA工具检测依赖项，并且还必须测试它们应满足的安全条件。

测试可执行代码以识别漏洞并验证是否符合安全要求（PW.8）：

识别漏洞，以便在软件发布之前对其进行纠正。

使用自动化方法可以减少检测漏洞所需的工作量和资源，并提高可追溯性和可重复性。

可执行代码包括二进制文件、直接执行的字节码和源代码以及组织认为可执行的任何其他形式的代码。

将软件配置为默认安全设置（PW.9）：

在安装时提高软件的安全性，以降低软件部署时安全设置较弱的可能性，从而避免其受到攻击的风险。