IBM Cloud Docs
同行评审合规性

同行评审合规性

同级代码复审是交付安全且合规的软件的关键组件。 DevSecOps 参考实现有助于在合并代码变更并将其推广到生产之前对其进行审查。

管理 CI/CD 工具链中的同级复审检查

本文档提供了有关在 Continuous Integration (CI) 中启用和禁用同级复审检查的指示信息，以及在 Continuous Delivery (CD) 工具链中启用和禁用同级复审检查的指示信息。

持续集成 (CI) 工具链

缺省情况下，将在 CI 工具链中启用对等复审检查。 要修改此设置:

  • 要启用对等复审检查，请将 peer-review-compliance 环境变量的值设置为 1。
  • 要禁用对等复审检查，请将 peer-review-compliance 环境变量的值设置为 0。

Continuous Delivery (CD) 工具链

以下环境变量允许您在 CD 工具链中管理同级复审检查:

  • 要检索正在进行的部署的拉取请求及其关联标题的列表，请将 peer-review-collection 环境变量设置为 1。 请注意，缺省情况下此变量设置为 1。 要取消激活此列表，请将 peer-review-collection 设置为 0。

  • 要对与当前部署关联的所有拉取请求启用同级复审验证，请将 peer-review-compliance 环境变量设置为 1。 默认情况下，此变量设置为 0。 要绕过此验证，请将 peer-review-compliance 设置为 0。

要点

您必须仅对受保护 (基本) 分支 (在该分支中更新库存) 执行同级复审。 如果要在功能部件分支上运行 CI 管道，请针对该特定触发器将环境变量 peer-review-compliance 设置为 0，以防止对功能部件分支进行同级复审检查。

是否遵守同行评审合规性取决于持续集成 (CI) 管道成功运行以及随后的库存条目。 因此，CI 管道的初始运行将跳过同级复审合规性检查。

为确保符合同行评审标准，假定 ci-finish 阶段中的库存更新发生在 master 分支上。 但是，如果您的库存更新是在除主节点以外的其他分支上执行的，那么可以设置环境变量 inventory-repo-branch 以指示正在进行库存更新的分支。

预计在持续部署 (CD) 管道中，对清单版本库进行的所有清单更新都将被推广到正在部署的目标分支，以确保不遗漏任何提交。 默认情况下，在部署过程中，清单资源库将签出到目标分支。 不过，如果清单推广目标分支遗漏了基本分支和目标分支之间的一些提交，可以设置 inventory-repo-branch 环境变量来指定所有清单提交所在的基本分支。

缺省情况下，持续集成 (CI) 管道将在运行结束时自动执行对库存存储库的落实，并使用应用程序名称作为库存条目。 但是，如果您打算在发布阶段修改库存条目，那么建议将名为 inventory-entry-name 的环境属性合并到工具链中。 此属性应包含修改后的库存名称，以便用于同级复审过程。

如果您有一个直接向保护分支推送提交的自动化系统，并希望避免同行评审合规性检查的问题，请确保您的提交信息包含 ##AUTOMATED_COMMIT##。

引用实现将发现未经同级复审的代码实例，收集 证据，并创建突发事件问题以跟踪这些项。

在可以合并主 (受保护) 分支中的代码之前，代码必须由未上载已修改代码的人员进行复审。

代码存储库 (存储库) 必须至少有两个成员: 一个成员具有管理特权，另一个成员具有写特权。 如果在没有复审的情况下将代码合并到存储库中，那么该操作必须在代码存储库审计跟踪中可视。 定期扫描审计跟踪以识别和分析这些异常情况。

管道在构建和部署期间收集同级复审合规性数据，以创建从代码拉取/合并请求合并到变更请求的审计跟踪。

在此图中，PR1和 PR2 是在合并之前核准的拉取/合并请求。 同样，对于 PR4，PR5和 PR7。 但是，以红色突出显示的 PR3 和 PR6将在未经核准的情况下合并，这是同级复审合规性违例。 这是作为证据捕获的。

数据收集
图 1。 数据收集

缺省情况下，CI 工具链中的样本应用程序尝试将最小复审者数设置为 1。 如果要更改复审者的数量，请根据需要设置 peer_review_approvers envronment 属性。 有关设置拉取/合并请求所需的最小复审者数的更多信息，请参阅以下 GitHub 和 GitLab 资源:

在持续集成构建运行中收集的数据

此数据收集包含自上次构建以来在应用程序存储库中合并的拉取/合并请求的所有落实的列表。

直接从应用程序存储库收集拉取请求数据。 将收集与触发先前构建的存储库落实与当前可用落实之间的落实相关的每个拉取/合并请求的数据。

不包含拉取/合并请求的落实会在管道的以下发行版中创建合规性事件问题。 不能直接落实到主分支。

合规性事件通常包含以下信息:

  • 关联落实标识的拉取/合并请求 URL 的列表。
  • 应用程序存储库。
  • 落实标识。
  • 所需核准数。

拉取请求突发事件内容
图 2。 拉取请求突发事件内容

收集的数据将保存为 证据 工件，该工件将上载到证据锁定程序，然后在证据本身中进行引用。 最终证据结果由核准的拉取/合并请求确定。 未核准，但合并的拉取/合并请求未能通过此类型的证据。

在持续部署运行中收集的数据

此数据收集包含自上次部署以来在应用程序存储库中合并的所有拉取/合并请求的列表。

从证据锁定程序和事件问题存储库收集拉取请求数据。

  • 该清单收集自上次部署以来所有基于相关工件的构建的数据。
  • 证据锁定程序从构建中收集存储的同级复审数据。
  • 突发事件问题存储库收集有关打开的拉取/合并请求突发事件的信息。

在此数据收集期间，不会访问应用程序存储库。 由于假定连续部署管道位于隔离环境中，因此无法跨越这些边界。

变更请求内容

以下数据包含在自动生成的变更请求中:

  • 未补救的拉取/合并请求事件的列表。 此数据包含资产详细信息和事件 URL。

未修复的拉取/合并请求事件会影响变更请求的部署准备情况。 如果找到任何拉取/合并请求突发事件，那么这些突发事件将被视为漏洞，并且必须手动复审并核准 变更请求。

变更请求内容
图 3。 变更请求内容

拉取请求事件补救

拉取请求突发事件被视为漏洞，因为它们指示未检查的代码包含在已发布的工件中。 要补救这些事件，请完成以下步骤:

  1. 追溯复审合并的变更。
  2. 创建有关如何解决代码的任何现有问题的问题。
  3. 添加 exempt 标签或关闭拉取/合并请求事件问题。

拉取/合并请求的作者和关闭拉取/合并请求事件问题的人员不能是同一个人。

故障诊断

案例 1:

问题

CD 管道的 collect_peer_review_commits in prod-start 阶段中的故障会导致其他阶段失败并产生错误。 当 prod_start 阶段中发生以下错误时

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').
解决方案

拥有单管道不支持的库存条目的用户必须在库存中添加 忽略文件。 此操作可确保在任何计算中都不考虑这些文件。

已知问题

  • 同级复审合规性依赖于在连续集成 (CI) 管道的每个迭代之后的发布步骤中包含库存条目。 跳过以包含任何失败的 CI 管道运行的库存条目可能会导致在 Continuous Delivery (CD) 管道中忽略该特定 CI 管道运行的同级复审证据。