vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Automated change management 

Change management automation is an important part of the DevSecOps pipeline reference implementation. Developers, approvers, and auditors can monitor the compliance aspects of deployments. Every deployment must follow an organization's change management policy.

The pipelines collect [evidence](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-evidence) from every part of the build and deployment lifecycle. Every piece of evidence correlates to a specific build and deployment of the artifacts. So, for each deployed artifact, you can tell if its build or test deployment has incidents. This correlation is implemented through the [inventory model](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-inventory).



 The connection between evidence, inventory, and change management 

Figure 1 shows the data flow and connection between evidence, inventory, and change management.

Zoom

![Connection between evidence, inventory, and change management](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/change-management-data-flow.svg)

Figure 1. Connection between evidence, inventory, and change management



1. CI runs build artifacts and leaves evidence of what happened during the creation of those artifacts.
2. CI runs create entries about the created artifacts in the inventory.
3. Built artifacts in the Inventory are [promoted](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-inventory) to deployment environments, like staging or pre-production.
4. Change management automation uses data from the inventory, the evidence locker, and the promotion PR to create the change request deployments. Change management automaton also leaves evidence of acceptance tests, for example. Successfully deployed and tested artifacts are further promoted to production environments.
Managing secrets in your toolchains 

Many of the tool integrations in your CI and CD toolchains require secrets, for example passwords, API keys, certificates, or other tokens. For example, an IBM Cloud® API key performs basic pipeline tasks, such as logging in to IBM Cloud. Similarly, the service ID API key writes evidence to the bucket in Cloud Object Store instance.

For security reasons, these secrets must not belong to or be affiliated with a person's identity or account because people often have greater access permissions than the toolchain automation requires. Affiliation with a person's identity or account would also violate the security principle of [least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege). Also, people often change roles or even companies and their credentials must be removed which might break the toolchain automation. By using an identity that is affiliated specifically for automation purposes provides a separation of duties between automation and people who use the automation.

Instead, the secrets that are used for non-IBM Cloud resources (such as GitHub Enterprise) must be affiliated with a functional ID within your enterprise with only the appropriate access that is needed by the toolchains. Likewise, secrets for IBM Cloud resources must be affiliated with an [IAM service ID API key](https://cloud.ibm.com/docs/account?topic=account-serviceidapikeys) that is affiliated with an [IAM service ID](https://cloud.ibm.com/docs/account?topic=account-serviceids). The IAM service ID access permissions should be scoped to the least privilege required by the toolchains.

Managing credentials like these must be done securely and in compliance with secrets management best practices. In particular, this means vaulting the required secrets by using an approved in-boundary vault provider, such as IBM Cloud® Secrets Manager, IBM® Key Protect, or [HashiCorp Vault](https://www.vaultproject.io) and then linking your toolchain secrets to those resources.

The secrets management capabilities that are provided in the toolchain setup and pipeline user interfaces enable selection of vaulted secrets by using secrets integrations for IBM Cloud® Secrets Manager, IBM® Key Protect, or HashiCorp Vault.
* Customize caching with CIS [edge functions](https://cloud.ibm.com/docs/cis?topic=cis-edge-functions-use-casescaching-using-fetch) or the [API](https://cloud.ibm.com/docs/cis?topic=cis-edge-functions-use-casescache-api)
* Adjust caching level, cache TTL, and more via the [CIS CLI](https://cloud.ibm.com/docs/cis?topic=cis-cli-plugin-cis-clicache)



The maximum file size CIS caches is 512MB for Trial and Standard customers and 5GB for Enterprise customers. Enterprise customers can open a Support case to request caching of larger files.





 File extensions cached by default 

CIS uses file extensions to cache content. The following file extensions are cached automatically:



* bmp
* class
* css
* csv
* doc
* docx
* ejs
* eot
* eps
* gif
* ico
* jar
* jpg
* js
* mid
* midi
* otf
* pdf
* pict
* pls
* png
* ppt
* pptx
* ps
* svg
* svgz
* swf
* tif
* tiff
* ttf
* webp
* woff
* woff2
* xls
* xlsx



CIS does not cache by MIME type, and doesn't cache HTML by default. CIS does cache a website's robots.txt. You can cache additional content by creating page rules.





 Understanding CIS cache responses 

The output of the CF-Cache-Status header shows whether a resource is cached.



Table 2. Cache response codes and definitions

 Response code Definition 

 HIT The resource was found in the CIS cache. 
 MISS The resource was not found in the CIS cache and was served from the origin web server.
* Infrastructure management operators, which include Policies and Profiles (ibm-management-infra-grc), Provisioning virtual machines and Instances (ibm-management-infra-vm), Managed services (ibm-management-cam-install), and Creating and managing services (ibm-management-service-library).
* Operations operator, which is ChatOps (ibm-management-sre-chatops).
* Monitoring operator, which is Monitoring (ibm-management-monitoring).
* Security services operators, which include Notary service for image signing (ibm-management-notary), Image signing support for image policies (ibm-management-image-security-enforcement), Mutation Advisor (ibm-management-mutation-advisor), and Vulnerability Advisor (ibm-management-vulnerability-advisor).
* Runtime (ibm-management-manage-runtime) operator, which is a technology preview code.







 Self-service capabilities 

Additional self-service capabilities enable developers to provision infrastructure and application components from a predefined service flow. This means providing a full-service library feature for developers to access on-demand.





 SRE tools for hybrid applications 

The IBM Cloud Pak for Multicloud Management supports the implementation of an SRE operating model. Some of these tools are:



* Bastion control - A new single point of access terminal supports secure remote access to managed systems. This centralized bastion host simplifies the troubleshooting process across regions and deployment models with increased visualization and remediation tools, such as audit and replay.
* Session replay - Replay sessions for auditing, compliance, and SRE postmortem reviews, which allows SRE teams to have a consistent source of review and feedback for future incident response and resolution.
* ChatOps - A ChatOps interface that connects with your preferred tools, including PagerDuty and Slack. This further accelerates the SRE’s ability to receive and react to incidents immediately using the tools they use every day.







 Hybrid Policy Model 

The updates to Governance, Risk, and Compliance policies allow for a faster, more flexible solution for both VMs and containers. This hybrid approach to policy applications allows operators to apply a policy that is enforced, even as applications are edited and moved by development teams.
Step 9: Manage compliance 

Controls are safeguards that are used to meet security and compliance requirements. Only controls that are supported by Security and Compliance Center, formatted correctly, and validated by Code Risk Analysis and Security and Compliance Center scans appear in the catalog. For more information, see [Formatting controls in your readme file](https://cloud.ibm.com/docs/sell?topic=sell-sell-format-controls).



 Manage compliance controls 

You can review the controls that were added from your readme file and add additional controls.



1. Click Add controls.
2. Choose a profile.
3. Select the controls that you want to add to your version.
4. Click Add.







 Run Code Risk Analyzer scan 

Scan your source code with Code Risk Analyzer to identify any security vulnerabilities that you need to assess.



1. Click Run scan.
2. Wait for the scan to finish.







 Add Security and Compliance Center scan 

Add the scans that you previously ran in the Security and Compliance Center. Security and Compliance Center scans determine adherence to regulatory controls. For more information, see [Scheduling a scan](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-schedule-scan).



1. Select the profile that you scanned.
2. Select the Security and Compliance Center scan.
3. Click Add scan.
4. Click Next.









 Review requirements 

You must complete validation and any other requirements to publish your virtual server image.





 Next steps 

Go to the Partner Center and publish it to the catalog. For more information, see [Publishing a virtual server image to the IBM Cloud catalog](https://cloud.ibm.com/docs/sell?topic=sell-vsipower-publish).
Verify that the access policy is successfully assigned. For more information, see [Reviewing assigned access in the console](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesreview-your-access-console).







 Managing Resource Drift 

With Terraform, you can safely and predictably manage the lifecycle of your infrastructure by using declarative configuration files. One challenge that exists when you are managing infrastructure as code is drift. Drift occurs when resources are added, deleted, or modified outside of applying Terraform configuration changes. For example, when a secret expires or is rotated. To avoid drift, always use Terraform to manage resources initially created with Terraform.

The Terraform state file is a record of all resources that Terraform manages. You must not make manual changes to resources that are controlled by Terraform because by doing so, the state file becomes out of sync or "drift", from the real infrastructure. If your state and configuration do not match your infrastructure, Terraform attempts to reconcile your infrastructure, which might unintentionally destroy or re-create resources.

When you are using the Secrets Manager Terraform provider, a drift might occur in cases such as:



* Secret expiration
* Secret auto-rotation
* External changes to Secret Manager resources that are controlled by Terraform



When you are designing your Terraform project, follow Terraform best practices for managing drift and lifecycle changes to avoid unintentional destruction or recreation of Secrets Manager resources.





 What's next? 

Now that you successfully created your first Secrets Manager service instance with Terraform on IBM Cloud, You can review the Secrets Manager resources and data sources in the [Terraform registry](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/secrets_manager_secret). You can also review how to manage your Secrets Manager resources by following the Terraform steps that are included in the How to section. For example, you can follow the directions on how to create [arbitrary secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-arbitrary-secrets) by using Terraform.
The routing rules identify the queue of agents to which messages from the assistant are transferred by default.

The code that you add to the setup page when you configure the service desk integration shares the following required information with Watson Assistant:



* organization_id: Unique ID of the organization. A company can have more than one organization set up in Salesforce.
* chat_api_endpoint: Salesforce API endpoint that is used by the integration to communicate with Salesforce.
* deployment_id: Unique ID of the deployment. An organization can have multiple deployments.
* button_id: Unique ID of a button, which defines the specific routing rules for incoming messages. Each deployment can have multiple buttons associated with it.



To override the default routing rules, you must specify a new value for the button_id. Before you perform this procedure, find out the ID of the Salesforce button implementation with the alternative routing rules that you want to use.

To add custom routing logic, complete the following steps:



1. From the Dialog page, find the root dialog node for the branch of the conversation that you want to route to a specific group of Salesforce agents which is distinct from the default group.
2. Find the dialog node in the branch where you want the transfer to take place, and then add the Connect to human agent response type as the dialog node response type.

For more information, see [Adding a Connect to human agent response type](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-overviewdialog-overview-add-connect-to-human-agent).
3. After you add the response type and customize the transfer messages, select Salesforce from the Service desk routing field.
4. In the Button ID field, add the button_id value for the alternate routing destination that you want the assistant to use for conversations about only this topic. For example, 5733i0000008yGz.

Be sure to specify the exact right syntax for the button_id value. The value is not validated by the service as you add it to your dialog.
The [CI](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-ci-pipeline)/[CD](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cd-pipeline) pipelines ensure that the application code that your team develops is secure and free of vulnerabilities before code is pushed to production. Once your code reaches production, you can use the CC pipeline to continuously scan your production code for new vulnerabilities. The [CC pipeline](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-cc-pipeline) can be triggered manually or periodically by using triggers.

The CC pipeline scans existing deployed artifacts and their source repositories independent of your deployment schedule. It runs the static scans and dynamic scans on the Application Source Code, detect secrets in Git repos, Bill Of Materials (BOM) check, CIS check, and Vulnerability Advisor scan.





 Managing issues and collecting evidence to be audit-ready 

After scanning and running checks on artifacts and source repositories, the pipeline creates a new incident issue or updates the existing incident issues in the incident repository. Finally, using these issues and the results, the pipeline collects evidence and summarizes the evidence. The evidence is reported to the IBM Cloud Security and Compliance Center, and included in an automated change rquest document.

Two types of issues are reported from your CI and CC pipelines: incident issues and nonincident issues. Incident issues can arise due to vulnerabilities or CVEs found inside the code or the deployed artifacts, and nonincident issues do not arise from vulnerabilities, but rather represent a deviation from the compliance posture, for example, unit test failures and branch protection check failures.
For information about the actions that are mapped to each role, see [IAM roles and actions - Toolchain](https://cloud.ibm.com/docs/account?topic=account-iam-service-roles-actionstoolchain).

Platform roles

Service roles



Table 1. IAM platform roles

 Platform role Description of actions 

 Viewer View toolchains and delivery pipelines. 
 Operator Run toolchains and delivery pipelines. 
 Editor Manage the toolchains, which include creating and deleting toolchains along with performing all platform actions except for managing the account and assigning access policies. 
 Administrator Perform all platform actions based on the resource this role is being assigned, including assigning access policies to other users. 





 Assigning access to toolchains in the console 

Assign access in the console in one of the following ways:



* Access policies per user. You can manage access policies per user from the Manage > Access (IAM) > Users page in the console. For information about the steps to assign IAM access, see [Assigning access to resources in the console](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources&interface=uiaccess-resources-console).
* Access groups. Access groups are used to streamline access management by assigning access to a group once, then you can add or remove users as needed from the group to control their access. You manage access groups and their access from the Manage > Access (IAM) > Access groups page in the console. For more information, see [Assigning access to a group in the console](https://cloud.ibm.com/docs/account?topic=account-groups&interface=uiaccess_ag).
[Catalog management](https://cloud.ibm.com/docs/account?topic=account-create-private-catalog) Arbitrary secrets Centrally manage the credentials for software in your private catalogs. [Learn more about this integration](https://cloud.ibm.com/docs/account?topic=account-create-private-catalog). 
 [Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-secretsmanager) Arbitrary secrets <br>IAM credentials Centrally manage the credentials for your Continuous Delivery toolchain. Create an authorization between Toolchain and Secrets Manager to give a toolchain access to your secrets. [Learn more about this integration](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-secretsmanager). 
 [Data Engine](https://cloud.ibm.com/docs/sql-query?topic=sql-query-getting-started) Arbitrary secrets <br>IAM credentials Store API keys for transferring messages between Event Streams, Data Engine and Cloud Object Storage. [Learn more](https://cloud.ibm.com/docs/sql-query?topic=sql-query-event-streams-landingpermissions-event-streams). 
 [Event Notifications](https://cloud.ibm.com/docs/event-notifications) Arbitrary secrets <br>Certificates <br>IAM credentials <br>User credentials Send notifications of events in Secrets Manager to other users, or human destinations, by using email, SMS, or other supported delivery channels. [Learn more about this integration](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-event-notifications). 
 [Kubernetes Service](https://cloud.ibm.com/docs/containers) Arbitrary secrets <br>Certificates <br>IAM credentials <br>Key-value secrets <br>User credentials Centrally manage Ingress subdomain certificates and other secrets for your Kubernetes clusters.
Managing VLANs with a gateway appliance 

By using a gateway appliance and the IBM Cloud console, you can manage your [VLANs](https://cloud.ibm.com/networking/vlans) with the associate, disassociate, "route through", and "route around" actions.

While the "associate" and "disassociate" actions are administrative in nature and do not change the way traffic flows (unless you are disassociating a VLAN while it is in the "route through" state), the "route through" and "route around" actions do change the way traffic flows. The "Route through" action essentially means you will manage your own VLANs on your own gateway appliance, while "route around" means the the IBM Cloud network team manages your VLANs on your Front-end Customer Routers (FCR) and Back-end Customer Routers (BCR).

You can perform these actions from the [Gateway Appliance Details page](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-viewing-gateway-appliance-details) by selecting the VLANs tab.

Before setting a VLAN to "route through" on a gateway appliance, please make sure that the VLAN and subnet gateways of the subnets assigned to the VLAN are configured properly on the gateway appliance itself. You should also make sure to allow proper traffic flow using firewall rules or security policies. If you do not configure the VLAN(s), subnet gateway(s), and firewall rules or security policies properly before setting the VLAN to "route through", the traffic will be routed to your gateway appliance and may cause outages to your servers or services on that VLAN.
* UI
* CLI
* API
* Terraform







 Customizing the IBM Cloud catalog and private catalogs for users in your account 

Private catalogs provide a way to centrally manage access to products in the IBM Cloud® catalog and your own catalogs. You can customize the public catalog and your private catalogs to make specific solutions available to users in your account. By doing so, you can ensure that your catalogs are relevant to your business.

Let's say you're an account administrator for your team, and you require access to all products in the IBM Cloud catalog. A member of your team is tasked with a specific project, for example, building a voice-enabled chatbot by using Watson Assistant, Speech to Text, and Text to Speech. And, you want them to access only those products in the IBM Cloud catalog.

To achieve this, you create one catalog that includes all products in the IBM Cloud catalog. Then, you create another catalog that includes only the required products, and you give the team member viewer access to the catalog.

All private catalogs that are in an account inherit filters that are set by the account owner or administrator at the account level. In addition, if the account is a parent account in an IBM Cloud enterprise, the filters apply to all child account groups and accounts.



 Before you begin 



* Verify that you're using a Pay-As-You-Go or Subscription account. See [Viewing your account type](https://cloud.ibm.com/docs/account?topic=account-account_settingsview-acct-type) for more details.
* Make sure you have the [administrator role on the catalog management service](https://cloud.ibm.com/docs/account?topic=account-account-servicescatalog-management-account-management) to complete this task.







 Before you begin 



* Verify that you're using a Pay-As-You-Go or Subscription account. See [Viewing your account type](https://cloud.ibm.com/docs/account?topic=account-account_settingsview-acct-type) for more details.