DevSecOps 应用程序生命周期管理的发布说明

使用这些发布说明可了解 DevSecOps 应用程序生命周期管理可部署架构的最新更新。条目按日期分组。

要查找本架构使用的 DevSecOps 合规性管道定义的发布说明，请参阅 DevSecOps 的发布说明。

2025 年 3 月 24 日

DevSecOps 应用程序生命周期管理 2.7.2 版本发布: DevSecOps 应用程序生命周期管理的 2.7.2 版本可在 IBM Cloud 目录中找到。

该版本扩展了之前发布的对资源库工具集成的 air gapped 支持，增加了对示例应用程序资源库工具的支持，可在 air gapped 配置中独立设置。

和以前一样，以下变量用于配置空气间隙设置。 repo_blind_connection, repo_git_id, repo_git_provider, repo_root_url, repo_title

注：repo_blind_connection 现在是 bool 类型，而以前是字符串类型。

支持三种配置：

完全气隙。所有资源库都配置了盲连接。要配置所有支持气隙的默认存储库，必须设置以下变量。将 compliance_pipeline_repo_use_group_settings 设为 true，将 repo_apply_settings_to_compliance_repos 设为 true，将 create_git_triggers 设为 false。详情请参见变量说明。
除符合要求的管道存放处外，完全气隙。将 compliance_pipeline_repo_use_group_settings 设为 false，将 repo_apply_settings_to_compliance_repos 设为 true，将 create_git_triggers 设为 false。
部分气隙。只有示例应用程序、配置 repos 和部署 repos 是空气间隙的。将 compliance_pipeline_repo_use_group_settings 设为 false，将 repo_apply_settings_to_compliance_repos 设为 false，将 create_git_triggers 设为 false。

创建服务应用程序接口密钥和应用程序接口密钥: ibmcloud-api-key 和 cos-api-key 现在可以以不同的方式进行配置。对于 ibmcloud-api-key，默认情况下将 create_ibmcloud_api_key 设置为 true，可创建一个具有相关权限的服务 api 密钥，以运行管道。作为副作用，资源库工具集成必须使用 Git 个人访问令牌进行配置。详情请见 repo_git_token_secret_name。另外，将 force_create_standard_api_key 设置为 true 将创建一个标准 apikey，其访问权限仅限于为用户分配的访问组。

同样，将 create_cos_api_key 设置为 true，并使用 cos_api_key_secret_name 为 cos-api-key 设置名称，就能创建一个具有相关权限的服务 api 密钥，以便运行管道与配置的 cos bucket 进行交互。 cos-api-key 还要求设置 cos_instance_crn 和 cos_bucket_name，以便将访问策略正确应用于 COS 服务 api 密钥。

最后，可使用 pipeline_ibmcloud_api_key_secret_value 和 cos_api_key_secret_value 分别指定 ibmcloud-api-key 和 cos-api-key api 密钥。详情请参见变量说明。

获取小组支持: 可通过将 create_access_group 设置为 true 来创建访问组。访问组的名称可通过 toolchain_access_group_name 设置。可将用户分配到该访问组，授予工具链操作的相关权限。

注意：create_code_engine_access_policy 或 create_kubernetes_access_policy 可设置为 true，以满足 Kubernetes 或 Code Engine 部署类型的政策要求。

秘密参考资料: 默认情况下，管道和工具集成使用的秘密引用使用传统格式，并以紫色标识。将 use_legacy_ref 设置为 false 将使用新的秘密参考格式，其颜色为茶色。今后的版本将默认使用新格式。

更多信息，请参阅变量。

2024 年 12 月 9 日

DevSecOps 应用程序生命周期管理 2.5.0 版发布: DevSecOps 应用程序生命周期管理 2.5.0 版可在 IBM Cloud 目录中找到。

升级到 2.5.0

从 2.4.3 升级: 从 2.4.3 版升级时，请将 compliance_pipeline_repo_name 变量设置为 compliance-pipelines，以防止强制替换合规管道工具集成。

如果从 2.0.3 升级到 2.5.0，请勿设置此变量。

从 2.0.3 升级

在升级过程中，会销毁一个未使用的 random_string 类型 Terraform 资源。

已修复的问题

启用 Slack 工具集成时，现在会正确计算 slack-notifications 管道属性。

新功能

现已支持私人工作者工具集成。以下变量用于配置私人工作者工具集成：

privateworker_name
privateworker_credentials_secret_name
privateworker_secret_value
create_privateworker_secret
enable_privateworker

其他信息

ALM 使用的各个 CI、CD 和 CC 模块都引入了一个新变量，用于指定合规管道资源库的名称。虽然默认配置中不使用该变量，但它可能会导致强制替换版本库集成。请注意，这不会影响版本库本身，只会影响工具集成。

私人工作者配置

要在您的工具链中添加私人工作者：

将 enable_privateworker 变量设置为 true，以便在工具链中添加 Worker 工具集成。
将 create_privateworker_secret 变量设为 true，以便在Secrets Manager实例中创建一个秘密。
在 privateworker_secret_value 变量中提供私有 Worker 的服务 API 密钥。
在 privateworker_credentials_secret_name 变量中指定存储服务 API 密钥的秘密名称。

需要现有的私有 Worker 服务 API 密钥。

更多信息，请参阅变量。

2024 年 11 月 6 日

DevSecOps 应用程序生命周期管理 2.4.3 版发布: DevSecOps 应用程序生命周期管理 2.4.3 版可在 IBM Cloud 目录中找到。

ALM 利用的各个 CI、CD 和 CC 模块都引入了一个新变量，指定 compliance-pipelines 资源库的名称。默认配置中不使用该变量，但会强制替换版本库集成。不会删除资源库本身，只会删除工具集成。

之前使用默认设置创建了一个未使用的 random_string 类型 Terraform 资源。您将在升级过程中看到它被摧毁。

使用盲连接配置合规存储库，以支持空气间隙环境。

以下组级变量针对默认合规性存储库应用设置： repo_blind_connection, repo_git_id, repo_git_provider, repo_root_url, repo_title

将 repo_blind_connection 设为 true 以启用盲连接，将 repo_git_id 设为合规版本库的 Git ID，将 repo_git_provider 设为 Git 提供商类型，如 GitHub 或 GitLab。repo_root_url 应设为服务器的根 URL，如 https://git.example.com.，repo_title 设为服务器的标题。还可以使用上述变量的特定版本对存储库进行单独配置。

支持在配置秘密Secrets Manager实例中提供秘密，特别是 git 标记和签名密钥。所需的变量如下

create_git_token repo_git_token_secret_name repo_git_token_secret_value create_signing_key rotate_signing_key ci_signing_key_secret_name cd_code_signing_cert_secret_name

将 create_git_token 设置为 true，将 repo_git_token_secret_name 设置为 my-git-token，并在 repo_git_token_secret_value 中指定 Git 个人访问令牌，将导致在Secrets Manager中创建一个名为 my-git-token 的秘密，其值在 repo_git_token_secret_value 中指定。值得注意的是，设置 repo_git_token_secret_value 会改变版本库工具使用的身份验证行为。现在，版本库将使用访问令牌和用户名/所有者。需要在 "repo_group 中设置所有者名称。可以使用与每个特定版本库相关联的 auth 类型变量来覆盖这一行为，并将其还原为 oauth 访问。这些变量以“_repo_auth_type 结尾，例如”issues_repo_auth_type

将 create_signing_key 设置为 true 会生成签名密钥和相应的签名验证证书。这些秘密的名称在“ci_signing_key_secret_name 和”cd_code_signing_cert_secret_name 中指定。

通过将 "rotate_signing_key 设置为 true，可以旋转生成的签名秘密。该密钥将轮流使用签名密钥和签名验证证书。如果有使用以前的签名密钥签名的待部署，则必须复制一份验证证书。

该版本还支持将GitLab用作源代码库，并简化了更改Git提供程序的方法。请参阅 repo_git_provider。将此变量设置为 "GitLab，以配置 DA 创建的所有合规性版本库工具使用GitLab。

要将GitLab用作提供程序，必须提供GitLab的访问令牌和用户/所有者名称。访问令牌的名称可以用“repo_git_token_secret_name 设置，它适用于所有合规存储库，存储库所有者的名称可以用”repo_group 设置。

可以使用以“_repo_git_token_secret_name 和”_group 结尾的变量对这些变量进行单独配置。例如“issues_repo_git_token_secret_name 和”issues_group

更多信息，请参阅变量。

2024 年 9 月 26 日

DevSecOps应用程序生命周期管理2.0.3版发布: DevSecOps应用程序生命周期管理2.0.3版已在IBM Cloud 目录中发布。

简化管道配置：现在可使用单个 JSON 变量为每种管道类型（CI、CD 和 CC）设置所有默认和自定义管道属性。

变化和改进

简化管道配置和管理
使用与管道属性名称相匹配的 JSON 变量名，提高了可用性
将所有管道属性集中在一处，降低复杂性

本次更新是一项重大变更。谨慎更新。为确保平稳过渡，请遵循以下步骤：

记录 CI、CD 和 CC 工具链的当前管道属性和值。
使用以下模板更新 JSON 变量：
- 对于 Kubernetes 风格的工具链，可使用 CI JSON、CD JSON 和 CC JSON。
- 另外，对于Code Engine口味，可使用 CI JSON、CD JSON 和 CC JSON。
将之前指定的自定义属性添加到更新的 JSON 变量中。

最常见的变量类型是文本属性，其形式为

  {
    "name": "opt-in-dynamic-scan",
    "type": "text",
    "value": "1"
  }

保密设置如下


  {
    "name": "git-token",
    "type": "secure",
    "value": "my-github-token"
  }

您可以通过以下三种方式之一将值设置为安全类型：

秘密名称：使用秘密提供程序中的秘密名称。密文的完整引用会根据创建 DA 时指定的密文Secrets Manager和密文组自动计算。 CRN：将云资源名称 (CRN) 设置为机密。这需要在 CRN 模式下配置 Secrets Manager 集成。 完整密文参考：设置完整的密文引用，例如 {vault::sm-compliance-secrets.Default.my-github-token}。这种方法允许您指定不同的秘密组。

现有的几个变量现在可以与 JSON 预属性协同工作。具体如下 app_repo_branch, cluster_name, cluster_namespace, cluster_region, code_engine_project, code_engine_region, code_engine_resource_group, code_signing_cert_secret_name, cos_api_key_secret_name, cos_bucket_name, cos_endpoint, dev_region, dev_resource_group, environment_tag, pipeline_doi_api_key_secret_name , doi_toolchain_id, doi_toolchain_id_pipeline_property, pipeline_ibmcloud_api_key_secret_name, region, registry_namespace, registry_region, signing_key_secret_name, pipeline_config_repo_branch

这些变量的目的是提供一种指定管道属性值的替代方法。它们是辅助变量。以以 "region 结尾的变量为例。这些将自动设置为与 "toolchain_region 变量匹配的区域。 cluster_region 可以明确设置，也可以继承 "toolchain_region 中设置的值。因此，JSON 中的等效管道属性可以留空，但仍需要指定管道属性才能创建。在 JSON 中设置值的优先级最高，设置后将覆盖上述变量中设置的任何值。

  {
    "name": "cluster-region",
    "type": "text",
    "value": ""
  }

另一个特例是 "doi_toolchain_id。除非您事先知道您希望DevOpInsights集成指向已经存在的特定工具链，否则请将此条目留空，DA 会自动为您提供 ID。

升级可能会失败，这很可能是由于通过用户界面而不是通过项目手动向管道添加了管道属性。在这种情况下，日志中可能出现的错误是 "duplicate property error。要解决这个问题，您必须在用户界面中删除有问题的属性，然后重新运行 DA 的项目部署步骤。如果属性不易识别，则删除除资源库工具集成属性之外的所有管道属性。

如果该属性没有出现在 JSON 中，那么部署后它也不会出现在管道属性中。只要属性的值设置为空，就可以根据需要使用上述变量。

2.0.3 版还有两项重大更改：

可用于设置的变量数量大幅减少。大约减少了 60%。这是使用管道属性 JSON 和添加更多组级变量并隐藏其相关变量的综合结果。例如，“cos_bucket_name 设置了所有三个工具链中的 cos 桶名，而”ci_cos_bucket_name、“cd_cos_bucket_name 和”cc_cos_bucket_name 等相关变量现在都不存在了。
锁定属性：这是一项新功能，旨在限制只有运行管道权限的用户的控制权。属性锁定后，运行管道时将无法对其进行编辑。若干属性现在默认为锁定。要解锁这些属性，请在属性 JSON 中确定所需的属性，并添加以下一行：

{
  "name": "doi-ibmcloud-api-key",
  "type": "secure",
  "value": "ibmcloud-api-key",
  "locked": "false"
}

微小改动

ci_signing_key_secret_name 的原始默认名称已更新为 signing-key。
CRA 自动修复功能现在已默认开启。
简化了自带示例应用程序的设置，对于示例应用程序位于Git或IBM托管的GitRepos 和问题跟踪中的情况，它将自动为您计算提供商设置。它们仍然可以明确设置。如果访问版本库需要 Git 令牌，则 require 变量现在只有 app_repo_existing_url、app_repo_branch 和 app_repo_git_token_secret_name。

2024 年 6 月 21 日

1.8.0 应用程序生命周期管理的 DevSecOps 版本已发布: 1.8.0 DevSecOps 应用程序生命周期管理的 IBM Cloud 目录中提供。

该版本包含 DevSecOps 管道的其他功能，包括修改 CRA 扫描行为的选项和 Event Notifications。 ci_cra_bom_generate, ci_cra_deploy_analysis, ci_cra_vulnerability_scan, pr_cra_bom_generate, pr_cra_deploy_analysis, pr_cra_vulnerability_scan, ci_enable_pipeline_notifications, ci_event_notifications, ci_pipeline_properties, ci_repository_properties, cd_enable_pipeline_notifications, cd_event_notifications, cd_pipeline_properties, cc_cra_bom_generate, cc_cra_deploy_analysis, cc_cra_vulnerability_scan, cc_enable_pipeline_notifications, cc_event_notifications, cc_pipeline_properties

有关更多信息，请参阅变量

该版本引入了新的自定义功能。 ci_pipeline_properties、cd_pipeline_properties 和 cc_pipeline_properties 变量允许用户使用相关前缀变量向 CI、CD 和 CC 管道添加自定义属性。

下面的示例使用 ci_pipeline_properties，其目标是 CI 工具链。请注意 JSON 中的 pipeline_id 行，其中有 ci 和 pr 值，表示 CI 和 PR 管道。在使用 cd_pipeline_properties 和 cc_pipeline_properties 变量时，使用 cd 和 cc 作为值将会针对各自的管道添加新变量。该示例突出显示了自定义文本、秘密和枚举管道属性的添加。请注意，对于安全类型属性，只需在默认 Secrets Manager 实例中指定秘密的名称即可。另外，还可以提供完整的秘密参考信息，例如 {vault::sm-compliance-secrets.custom-secret-group.secret-name}

[
  {
    "pipeline_id": "ci",
    "properties": [
      {
        "name": "custom-param1",
        "type": "text",
        "value": "example1"
      },
      {
        "name": "custom-param2",
        "type": "secure",
        "value": "grit-token"
      },
      {
        "name": "custom-param3",
        "type": "single_select",
        "value": "0",
        "enum": "[0,1,2]"
      }
    ]
  },
  {
    "pipeline_id": "pr",
    "properties": [
      {
        "name": "custom-param1",
        "type": "text",
        "value": "example1"
      }
    ]
  }
]

CI 工具链还有一个名为 ci_repository_properties 的变量，允许用户向 CI 工具链添加新的或现有的软件源。默认情况下，列出的版本库将被视为现有版本库，而不会尝试克隆这些版本库。

下面的示例重点介绍了如何在 CI 工具链中添加其他版本库。请注意，JSON 中的顶层条目由子元素继承，并可被子元素中具有相同键名的条目覆盖。示例中列出了两个存储库。第一个储存库是最基本的情况。它包含 repository_url 和 default_branch。 default_branch 用 main 覆盖 master 值。默认 mode 为 link。由于该版本库位于 GitHub, 因此需要 Git 标记。这在 JSON 的顶层中指定。该值必须在“秘密提供者”中。这样指定版本库将导致自动为版本库创建触发器，即 Git 触发器、手动触发器和 PR 触发器。

第二个列出的版本库处于 clone 模式，将尝试把版本库克隆到 GRIT 中。如果没有为版本库提供 name，它将使用与正在克隆的版本库相同的名称。

第二个示例还显示了自定义触发器的创建。需要注意的是，添加自定义触发器将阻止创建自动触发器。

[
  {
    "pipeline_id": "ci",
    "repository_owner": "owner_name",
    "default_branch": "master",
    "repositories": [
      {
        "repository_url": "https://github.com/open-toolchain/secure-kube-toolchain",
        "default_branch": "main",
         "git_token_secret_ref": "github-token",
      },
      {
        "repository_url": "https://github.com/open-toolchain/hello-containers",
        "mode": "clone",
        "name": "clone-of-hello-containers",
        "triggers": [
          {
            "type": "manual",
            "name": "Manual Trigger1",
            "properties": [
              {
                "type": "text",
                "name": "param1",
                "value": "example1"
              }
            ]
          }
        ]
      }
    ]
  }
]

2024 年 5 月 15 日

1.2.1 应用程序生命周期管理的 DevSecOps 版本已发布: 1.2.1 DevSecOps 应用程序生命周期管理的 IBM Cloud 目录中提供。

在 Code Engine 变体、code_engine_project, code_engine_project_prefix, ci_code_engine_project_prefix 和 cd_code_engine_project_prefix 中配置 Code Engine 项目名称的附加选项。

有关更多信息，请参阅变量

2024 年 3 月 22 日

1.1.0 应用程序生命周期管理的 DevSecOps 版本已发布: 1.1.0 DevSecOps 应用程序生命周期管理的 IBM Cloud 目录中提供。

为 Secrets Manager添加了 CRN 支持。使用 Secrets Manager 实例的 CRN 设置 sm_instance_crn。至少需要提供两个 CRN 密钥。使用运行管道的 API 密钥的 CRN 设置 pipeline_ibmcloud_api_key_secret_crn，并使用签名密钥的 CRN 设置 ci_signing_key_secret_crn。
添加了对 GoSec 扫描的支持。将 opt_in_gosec 设置为 1 以启用 GoSec 扫描。请参阅 DevsecOps 文档
支持使用 Git 标记在管道定义部分中选择合规性管道定义的版本。建议使用当前设置，这将自动使用最新版本的合规性管道。要指定标记，请使用 pipeline_git_tag。
支持启用工件验证。请参阅 DevsecOps Docs。期望的签名证书密钥名称为 signing-certificate。如果已在私钥提供程序中以其他私钥名称进行设置，那么可以通过设置 cd_code_signing_cert_secret_name 以与现有私钥条目名称匹配来对其进行更新。

如果要从 V 1.0.7 升级到 1.1.0，请选择与当前配置对应的变体。如果在 CI 管道属性中设置了 print-code-signing-certificate，请先删除该条目，然后再继续。同样适用于 CD 管道中的 code-signing-cert。这些将导致更新失败 (如果存在)。如果发生故障，请确保已除去这些管道属性，然后重试。

2023 年 12 月 11 日

1.0.7 应用程序生命周期管理的 DevSecOps 版本已发布: DevSecOps 应用程序生命周期管理的 IBM Cloud 目录中提供了 1.0.7 版本。

现在，您可以使用 IBM Cloud Code Engine来部署样本应用程序。
在 CC 工具链中添加了针对受支持的应用程序类型使用 CRA 自动修复漏洞的支持。
DevSecOps 应用程序生命周期管理现在使用 open-v10 版本的合规管道。在 IBM Cloud 项目中从 1.0.6 升级到 1.0.7 也会将版本更新为 open-v10。您可以使用 compliance_pipeline_branch 变量显式更改版本。
添加了对 SonarQube的支持。
已向 CD 管道添加验证触发器以验证 Git 促销。

如果要从 V 1.0.6 升级到 1.0.7，请选择 1.0.7 的 Deploy to Kubernetes 选项

2023 年 10 月 2 日

1.0.6 应用程序生命周期管理的 DevSecOps 版本已发布: 1.0.6 DevSecOps 应用程序生命周期管理的 IBM Cloud 目录中提供。

IBM 添加新的 Security and Compliance Center 概要文件支持。
使用 Secrets Manager时，IBM Cloud Event Notifications 支持多个密钥组。
有关更多信息，请参阅必需变量和可选变量。新的 SCC 变量以 scc_ 为前缀，私钥组变量以 _secret_group 为后缀。

2023 年 9 月 8 日

1.0.5 应用程序生命周期管理的 DevSecOps 版本已发布: 1.0.5 DevSecOps 应用程序生命周期管理的 IBM Cloud 目录中提供。

可以使用 compliance_pipeline_branch 跨所有管道设置 IBM 受管合规性管道定义，也可以使用 ci_compliance_pipeline_branch，ci_compliance_pipeline_pr_branch，cd_compliance_pipeline_branch 或 cc_compliance_pipeline_branch 基于管道设置。默认值为 open-v9。
IBM Cloud Event Notifications 工具可以通过将 event_notifications_crn 与现有 Event Notifications 服务的 CRN 配合使用，或者使用 ci_event_notifications_crn，cd_event_notifications_crn 或 cc_event_notifications_crn 将其添加到特定工具链。
更新了某些变量名称以实现一致性。evidence_repo_url 现在为 evidence_repo_existing_url。issues_repo_url 现在为 issues_repo_existing_url。inventory_repo_url 现在为 inventory_repo_existingurl。旧变量名和新变量名有效，但应更新代码以使用新变量名。
现在可以对触发器进行命名，启用和禁用。例如，ci_trigger_manual_name 和 ci_trigger_manual_enable。有关更多信息，请参阅必需变量和可选变量。

版本 1.0.5 解决了一个潜在问题，即缺省 Sonarqube 扫描无法运行，而是尝试连接到定制服务器。可以在 1.0.4 发行版中通过从 CI 和 CC 管道属性中删除文本参数 sonarqube 来解决此问题。先前已设置为 {}。

2023 年 5 月 26 日

1.0.4 应用程序生命周期管理的 DevSecOps 版本已发布: 新版本支持简化的设置。它引入了许多充当组变量的附加变量。有关更多信息，请参阅必需变量和可选变量。例如，toolchain_region 变量现在为 CI，CD，CC 工具链以及集群区域和容器注册表区域设置区域。

2023 年 4 月 20 日

DevSecOps 应用程序生命周期管理介绍: DevSecOps 应用程序生命周期管理已发布。您可以使用可部署体系结构来创建一组 DevOps 工具链和管道。可部署体系结构Cloud automation for deploying a common architectural pattern that combines one or more cloud resources that is designed for easy deployment, scalability, and modularity. 基于 IBM Cloud for Financial Services 参考体系结构。