Update: 05-02-2025

devsecops-basics-pipelines-customization.md

@@ -21,7 +21,7 @@ Learn the basics for adopting DevSecOps and onboard your first application or mi
 ## About DevSecops toolchains
 {: #devsecops-about}
 
-You discovered and tested {{site.data.keyword.cloud_notm}} [DevSecOps](https://www.ibm.com/topics/devsecops) Continuous Integration ([CI](/docs/devsecops?topic=devsecops-tutorial-ci-toolchain)), Continuous Deployment ([CD](/docs/devsecops?topic=devsecops-tutorial-cd-toolchain)), and Continuous Compliance ([CC](/docs/devsecops?topic=devsecops-tutorial-cc-toolchain)) toolchains that implement DevSecOps best practices and security tools.
+You discovered and tested {{site.data.keyword.cloud_notm}} [DevSecOps](https://www.ibm.com/think/topics/devsecops) Continuous Integration ([CI](/docs/devsecops?topic=devsecops-tutorial-ci-toolchain)), Continuous Deployment ([CD](/docs/devsecops?topic=devsecops-tutorial-cd-toolchain)), and Continuous Compliance ([CC](/docs/devsecops?topic=devsecops-tutorial-cc-toolchain)) toolchains that implement DevSecOps best practices and security tools.
 
 Now, you're ready to onboard your own application or microservice and adopt DevSecOps.
 
@@ -147,9 +147,9 @@ There are two major categories of scripts that are used by DevSecOps pipelines:
 Except for the start stage, each stage of a CI, CD, or CC pipeline can be customized with your own scripts to override the default implementation of the stage. The start stage can’t be customized with your own scripts.
 {: important}
 
-Though Bash scripts are provided as samples, you can build, test, and deploy your application by using other languages like Python or Go. Make sure you're using the correct `image` for each stage. Refer to the [Docker images in DevSecOps pipelines section](#docker-images-in-devsecops-pipelines).
+Though Bash scripts are provided as samples, you can build, test, and deploy your application by using other languages like Python or Go. Make sure you're using the correct `image` for each stage. Refer to the [Docker images in DevSecOps pipelines section](#docker-images-in-devsecops).
 
- Refer to the table [Stages and tasks](#devsecops-ci-pipeline-stages) that summarize various stages of the CI Pipeline. The table also provides a consolidated information about whether the stage has a default reference implementation, whether it can be customized or skipped, or whether there is explicit evidence collection that is required by the stage execution.
+ Refer to the table [Stages and tasks](/docs/devsecops?topic=devsecops-cd-devsecops-ci-pipeline#devsecops-ci-pipeline-stages) that summarize various stages of the CI Pipeline. The table also provides a consolidated information about whether the stage has a default reference implementation, whether it can be customized or skipped, or whether there is explicit evidence collection that is required by the stage execution.
 
 
 #### Migrating from Jenkins or Travis to DevSecOps
@@ -210,7 +210,7 @@ The DevSecOps pipeline provides the path to the root folder of [the commons libr
 source "${COMMONS_PATH}/<script folder in commons>/<script file name>
 ```
 
-Refer to the table [Stages and tasks](#devsecops-cd-pipeline-stages) that summarizes various stages of the CD Pipeline. The table also provide a consolidated information about whether the stage has a default reference implementation, whether it can be customized or skipped, or whether there is explicit evidence collection required by the stage execution.
+Refer to the table [Stages and tasks](/docs/devsecops?topic=devsecops-cd-devsecops-cd-pipeline#cd-devsecops-pipeline-stages) that summarizes various stages of the CD Pipeline. The table also provide a consolidated information about whether the stage has a default reference implementation, whether it can be customized or skipped, or whether there is explicit evidence collection required by the stage execution.
 
 ### Environment properties
 {: #pipeline-parameters}

devsecops-build-docker-images.md

@@ -128,4 +128,4 @@ For more information, check out the following documentation:
 
 * [Documentation on stages for user-defined scripts](/docs/devsecops?topic=devsecops-cd-devsecops-pipelines-custom-customize)
 * [API documentation for pipelinectl](/docs/devsecops?topic=devsecops-cd-devsecops-pipelinectl)
-* [The default built-in GPG Image sign script](https://us-south.git.cloud.ibm.com/open-toolchain/hello-compliance-app/-/blob/master/scripts/sign_image.sh){: external}
+* [The default built-in GPG Image sign script](https://us-south.git.cloud.ibm.com/open-toolchain/hello-compliance-app/-/tree/master){: external}

devsecops-ci-pipeline.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2021, 2024
-lastupdated: "2024-10-22"
+  years: 2021, 2025
+lastupdated: "2025-02-05"
 
 keywords: DevSecOps, scan, inventory, compliance, dynamic scan, zap,
 
@@ -169,7 +169,7 @@ To use a different scan or sign process, or to process artifacts other than Dock
 ## Deploy to dev
 {: #devsecops-ci-pipeline-devdeploy}
 
-The Deploy stage deploys built artifacts into a dev environment. You can provide your variables and credentials for this stage from [variables in the pipeline UI](/docs/devsecops?topic=devsecops-cd-devsecops-pipelines-custom-customize#cd-devsecops-scripts-secrets) and the [pipeline trigger webhook payload](/docs/devsecops?topic=devsecops-cd-devsecops-webhook-payloads).
+The Deploy stage deploys built artifacts into a dev environment. You can provide your variables and credentials for this stage from [variables in the pipeline UI](/docs/devsecops?topic=devsecops-cd-devsecops-pipelines-custom-customize) and the [pipeline trigger webhook payload](/docs/devsecops?topic=devsecops-cd-devsecops-webhook-payloads).
 
 ## Dynamic scan
 {: #devsecops-ci-pipeline-dynamic-codescan}

devsecops-cocoa-cli.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2024, 2025
-lastupdated: "2025-01-13"
+lastupdated: "2025-02-05"
 
 keywords: DevSecOps, cli, IBM Cloud
 
@@ -1502,7 +1502,7 @@ CLI options can be also set from environment variables except for `backend` and
 ## cocoa set-status
 {: #set-status}
 
-Sets a commit's status. The current implementation is tested on GitHub. See documentation about [GitHub statuses](https://docs.github.com/en/rest/reference/repos#statuses){: external}.
+Sets a commit's status. The current implementation is tested on GitHub. See documentation about [GitHub statuses](https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28){: external}.
 
 Required Environment Variables:
 
@@ -2325,7 +2325,7 @@ $ cocoa incident update-state \
 ## cocoa locker commands
 {: #locker-commands}
 
-To upload evidence and attachments to [Cloud Object Storage](https://www.ibm.com/cloud/object-storage){: external}as well for archiving purposes. It is done automatically when the following environment variables are present:
+To upload evidence and attachments to [Cloud Object Storage](https://www.ibm.com/products/cloud-object-storage){: external}as well for archiving purposes. It is done automatically when the following environment variables are present:
 
 - `COS_ENDPOINT`: The [endpoint](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpoints){: external}where the Cloud Object Storage bucket can be accessed.
 - `COS_BUCKET_NAME`: The name of the Cloud Object Storage bucket.
@@ -2679,7 +2679,7 @@ https://github.ibm.com/foo/bar.git#aaaaaaaabbbbbbbbccccccccddddddddeeeeeeee
 
 Adds evidence to the evidence locker.
 
-The evidence locker can be specified by using flags. For more information, see [cocoa locker commands](#cocoa-locker-commands).
+The evidence locker can be specified by using flags. For more information, see [cocoa locker commands](#locker-commands).
 
 The evidence can be configured by using the following flags:
 
@@ -2851,7 +2851,7 @@ Optional flags:
 - `--scope`: Considers evidence that has the specified scope only (see `evidence add --scope`), can be specified multiple times
 - `--linked-scope`: Considers evidence that has the specified linked-scope as scope. In addition, adds them to the linked-scopes property in the returned evidence summary. Can be specified multiple times.
 - `--check-immutable-storage`: Checks if every evidence is also present in a Cloud Object Storage bucket and is protected by a retention period of at least 365 days. Appends `com.ibm.immutable_storage` evidence to the summary.
-   - See [`cocoa locker`](#cocoa-locker) section on how to configure the Cloud Object Storage bucket.
+   - See [`cocoa locker`](#locker-commands) section on how to configure the Cloud Object Storage bucket.
 - `--dry-run`: Has an effect when combined with `--check-immutable-storage`. If used, `com.ibm.immutable_storage` evidence is only appended to the summary but it does not get uploaded to the evidence locker.
 - `--clone-dir`: An optional parameter to determine the clone path of Evidence Repository, by default it will clone the repo /tmp directory
 - `--initialized`: Optional flag which assume the evidence locker is already cloned in the provided location `--clone-dir` or `/tmp/`.
@@ -2939,7 +2939,7 @@ Checks the required configuration and settings of the locker.
 Currently, only the Cloud Object Storage based locker has a configuration requirement:
 - Because every evidence must be kept for at least one year, the Cloud Object Storage bucket must be protected by a retention policy. Default retention period must be greater or equal to 365 days.
 
-For more information, see [cocoa locker commands](#cocoa-locker-commands).
+For more information, see [cocoa locker commands](#locker-commands).
 
 Required Environment Variables:
 

devsecops-config-github.md

@@ -6,7 +6,7 @@ lastupdated: "2024-06-06"
 
 keywords: DevSecOps
 
-subcollection: devsecops-working
+subcollection: devsecops
 
 ---
 
@@ -83,7 +83,7 @@ Only when all the required status checks pass successfully will the pull request
 
 By leveraging status checks within DevSecOps, you can maintain code quality, adhere to coding standards, and ensure the absence of vulnerabilities or critical flaws before incorporating changes into your project's protected branch.
 
-For more information on configuring status checks, refer to the [Configuring Status Checks Only (Status Checks Configuration)](#configuring-status-checks-only-status-checks-configuration) section for a reference implementation.
+For more information on configuring status checks, refer to the [Configuring Status Checks Only (Status Checks Configuration)](#devsecops-config-github-checks-only) section for a reference implementation.
 
 1. Enable the `Require status checks to pass before merging` option.
 

devsecops-configuring-sonarqube-scan.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2015, 2024
-lastupdated: "2024-10-09"
+lastupdated: "2025-02-05"
 
 keywords: tool integrations, Sonarqube
 
@@ -91,7 +91,7 @@ If you add multiple SonarQube tool integrations to your pipeline, you can switch
 
 DevSecOps Pipelines uses SonarQube Version 10.0 by default.
 
-To know more about the list of preinstalled plug-ins, refer to [plug-ins](https://docs.sonarsource.com/sonarqube/latest/instance-administration/plugin-version-matrix/)
+To know more about the list of preinstalled plug-ins, refer to [plug-ins](https://docs.sonarsource.com/sonarqube-server/latest/setup-and-upgrade/plugins/plugin-version-matrix/)
 
 ### Issues reported from SonarQube
 {: #sonarqube-cipipeline-issues-reported}
@@ -115,12 +115,12 @@ If you use the SonarQube instance that the pipeline created, you can update the
 
 1. Specify which quality gate that you want to associate with the project. New scans are evaluated by this quality gate and evidence is created by the quality gate's results.
 
-To learn more about SonarQube, see [SonarQube Documentation](https://docs.sonarqube.org/latest/){: external}.
+To learn more about SonarQube, see [SonarQube Documentation](https://docs.sonarsource.com/sonarqube-server/latest/){: external}.
 
 ### Using your own configuration file
 {: #sonarqube-config-file}
 
-You can modify the default configuration without using your own SonarQube instance. Create a `sonar-project.properties` file in the repo that you want to create the configuration file in. If our script detects an existing `configuration sonar-project.properties` file in the repo, it uses that file instead of the default file. For more information about possible analysis parameters in the configuration file, see [Analysis Parameters](https://docs.sonarqube.org/latest/analysis/analysis-parameters/){: external} here.
+You can modify the default configuration without using your own SonarQube instance. Create a `sonar-project.properties` file in the repo that you want to create the configuration file in. If our script detects an existing `configuration sonar-project.properties` file in the repo, it uses that file instead of the default file. For more information about possible analysis parameters in the configuration file, see [Analysis Parameters](https://docs.sonarsource.com/sonarqube-server/latest/analyzing-source-code/analysis-parameters/){: external} here.
 
 Make sure that you add the correct login credentials and host URL to the configuration file.
 {: important}

devsecops-cos-configure.md

@@ -1,8 +1,8 @@
 ---
 
 copyright: 
-  years: 2021, 2024
-lastupdated: "2024-06-19"
+  years: 2021, 2025
+lastupdated: "2025-02-05"
 
 keywords: DevSecOps, COS, secure toolchain, compliance, bucket
 
@@ -21,7 +21,7 @@ Complete these steps to create an {{site.data.keyword.cos_full_notm}} instance a
 ## Create a Cloud {{site.data.keyword.cos_short}} instance
 {: #cd-devsecops-cos-instance-create}
 
-Create an [{{site.data.keyword.cos_full_notm}} instance](https://cloud.ibm.com/catalog/services/cloud-object-storage){: external}.
+Create an [{{site.data.keyword.cos_full_notm}} instance](https://cloud.ibm.com/objectstorage/create){: external}.
 
 ## Create a Cloud {{site.data.keyword.cos_short}} bucket
 {: #cd-devsecops-cos-bucket-create}

devsecops-custom-deployment.md

@@ -1,8 +1,8 @@
 ---
 
 copyright:
-  years: 2023, 2024
-lastupdated: "2024-03-21"
+  years: 2023, 2025
+lastupdated: "2025-02-05"
 
 keywords: DevSecOps, COS, secure toolchain, compliance, ibm cloud, cloud object storage, satellite , Push based deployment , Pull based deployment
 
@@ -49,25 +49,25 @@ deploy:
 
 DevSecOps provides an option to deploy your application using Pull-based deployment using {{site.data.keyword.satellitelong_notm}} Config.
 
-[{{site.data.keyword.satellitelong_notm}}](https://www.ibm.com/cloud/satellite){: external} is an extension of the {{site.data.keyword.cloud_notm}} Public that can run inside the customer's data center or out at the edge. Each {{site.data.keyword.satellitelong_notm}} location is connected by using {{site.data.keyword.satellitelong_notm}} Link, which provides the connection to the {{site.data.keyword.cloud}} control plane. It provides audit, packet capture, and visibility to the security team, while a configuration utility provides a global view of applications and services. {{site.data.keyword.satellitelong_notm}} Link provides a simple way to manage the connection between {{site.data.keyword.cloud_notm}} and the {{site.data.keyword.satelliteshort}} location with visibility into all the traffic that goes back and forth with control of the endpoints on both sides of the link.
+[{{site.data.keyword.satellitelong_notm}}](https://www.ibm.com/products/satellite){: external} is an extension of the {{site.data.keyword.cloud_notm}} Public that can run inside the customer's data center or out at the edge. Each {{site.data.keyword.satellitelong_notm}} location is connected by using {{site.data.keyword.satellitelong_notm}} Link, which provides the connection to the {{site.data.keyword.cloud}} control plane. It provides audit, packet capture, and visibility to the security team, while a configuration utility provides a global view of applications and services. {{site.data.keyword.satellitelong_notm}} Link provides a simple way to manage the connection between {{site.data.keyword.cloud_notm}} and the {{site.data.keyword.satelliteshort}} location with visibility into all the traffic that goes back and forth with control of the endpoints on both sides of the link.
 
 Users can have groups of Red Hat® OpenShift® clusters in a [{{site.data.keyword.satelliteshort}} cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig). You can use [{{site.data.keyword.satelliteshort}} Config](/docs/satellite?topic=satellite-cluster-config) to deploy the application into a [{{site.data.keyword.satelliteshort}} cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig).
 
 Follow a two-step process to enable your Red Hat® OpenShift® clusters to leverage {{site.data.keyword.satelliteshort}} Config to perform simultaneous deployments.
 
-1. [Create a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig#setup-clusters-satconfig-groups), which is a logical grouping of clusters that run on a {{site.data.keyword.satelliteshort}} location.
+1. [Create a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig-groups), which is a logical grouping of clusters that run on a {{site.data.keyword.satelliteshort}} location.
 
-2. [Attach a cluster to a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig#setup-clusters-satconfig-access), which grants {{site.data.keyword.satelliteshort}} Config access to manage the resources within the cluster.
+2. [Attach a cluster to a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig#auto-setup-clusters-satconfig), which grants {{site.data.keyword.satelliteshort}} Config access to manage the resources within the cluster.
 
 As an advanced configuration, you can also deploy the application to the compute infrastructure in your on-premises data center or other cloud providers by using [{{site.data.keyword.satellitelong_notm}}](/docs/satellite?topic=satellite-getting-started).
 
 1. [Create a {{site.data.keyword.satelliteshort}} location](/satellite/locations/create){: external} for the compute infrastructure in your on-premises data center or other cloud providers by using predefined templates.
 
 2. [Deploy a Red Hat® OpenShift® cluster](/kubernetes/catalog/create?platformType=openshift){: external} to the {{site.data.keyword.satelliteshort}} location by using setup.
 
-3. [Create a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig#setup-clusters-satconfig-groups), which is a logical grouping of clusters that run on a {{site.data.keyword.satelliteshort}} location.
+3. [Create a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig-groups), which is a logical grouping of clusters that run on a {{site.data.keyword.satelliteshort}} location.
 
-4. [Attach a cluster to a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig#setup-clusters-satconfig-access), which grants {{site.data.keyword.satelliteshort}} Config access to manage the resources within the cluster.
+4. [Attach a cluster to a cluster group](/docs/satellite?topic=satellite-setup-clusters-satconfig#auto-setup-clusters-satconfig), which grants {{site.data.keyword.satelliteshort}} Config access to manage the resources within the cluster.
 
 ### Prerequisites
 {: #custom-deployment-target-prereqs}

devsecops-data-security.md

@@ -46,7 +46,7 @@ To keep your credentials secure, make sure that you follow this guidance:
 * [{{site.data.keyword.keymanagementservicefull}}](/docs/key-protect?topic=key-protect-getting-started-tutorial)
 * [HashiCorp Vault](https://www.vaultproject.io/){: external}
 
-For more information about secure DevOps best practices, see [DevOps Security](https://www.ibm.com/cloud/learn/devops-a-complete-guide?mhsrc=ibmsearch_a&mhq=Secure%20DevOps#toc-security-j2-0639C){: external}.
+For more information about secure DevOps best practices, see [DevOps Security](https://www.ibm.com/think/topics/devops#toc-security-j2-0639C){: external}.
 
 ## Protecting your data when you use third-party tool integrations
 {: #secure-integrations}

devsecops-decoding-gpg-key.md

@@ -6,7 +6,7 @@ lastupdated: "2023-05-30"
 
 keywords: DevSecOps, CI toolchain with multiple apps, multiple apps toolchain
 
-subcollection: devsecops-working
+subcollection: devsecops
 
 ---