vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Click Validate.

To monitor the progress of the validation process, click View logs.







 Step 8: Manage compliance (optional) 

The Security and Compliance Center scans determine adherence to regulatory controls as defined in a profile. 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 [Adding compliance details](https://cloud.ibm.com/docs/account?topic=account-catalog-format-controls). After you share or publish your product, users can view your controls on the About page for your product, which proves that your product meets specific industry regulations. For more information, see [What is a profile?](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-profiles)



 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.









 Step 9: Review requirements 

You must complete validation and any other requirements to share your product to your account. When you're ready to share your product, click Ready to share.
Go to terminal 3 and repeat the same steps and create a DEST_AGENT :



* 10.1 This system needs to know the coordination queue manager it is getting conneted to



* execute command fteSetupCoordination -coordinationQMgr <queueManagerName> -coordinationQMgrHost <queueManagerHostname> -coordinationQMgrPort <queueManagerPort> -coordinationQMgrChannel <queueManagerChannel> -credentialsFile <filePath> -default



* e.g. :fteSetupCoordination -coordinationQMgr QMCOORD -coordinationQMgrHost qmcoord-749b.qm2.us-preprod.mqcloud.ibm.com -coordinationQMgrPort 31211 -coordinationQMgrChannel CLOUD.ADMIN.SVRCONN -credentialsFile "C:UsersAdministratorMQMFTCredentials.xml" -default -f





* 10.2 Configure QMDEST as command queue manager for agent



* execute command fteSetupCommands -p <configurationName> -connectionQMgr <DestinationAgentQueueManager> -connectionQMgrHost <agentQueueManagerHost> -connectionQMgrPort <agentQueueManagerPort> -connectionQMgrChannel <queueManagerChannel> -credentialsFile <filePath> -f



* agentQueueManagerHost - Required. this is the ‘hostname’ in the file connection_info.txt of DestinationAgentQueueManager.
* agentQueueManagerPort - Required. this is the ‘listenerPort’ in the file connection_info.txt of DestinationAgentQueueManager.
* agentQueueManagerChannel - Required. this is the ‘adminChannelName’ in the file connection_info.txt of DestinationAgentQueueManager.
* configurationOptions - by convention this is the name of a coordination queue manage
If no value is specified, only the kube-clusterID and the default VPC security group are applied. A maximum of five security groups can be applied to workers, including the default security groups. Note that the VPC security group is only applied if no other security groups are specified. For more information, see [Adding VPC security groups to clusters and worker pools during create time](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-sg-cluster).

The security groups applied to a cluster cannot be changed once the cluster is created. You can [change the rules of the security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupvpc-sg-create-rules) that are applied to the cluster, but you cannot add or remove security groups at the cluster level. If you apply the incorrect security groups at cluster create time, you must delete the cluster and create a new one. See [Adding VPC security groups to clusters and worker pools during create time](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-sg-cluster) for more details before adding security groups to your cluster.

--sm-group GROUP
: Optional. The secret group ID of the Secrets Manager instance where your secrets are persisted. To get a secret group ID, see the [Secrets Manager CLI reference](https://cloud.ibm.com/docs/secrets-manager-cli-plugin?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-secret-groups-cli). Use this option to specify a [secret group](https://cloud.ibm.com/docs/secrets-manager-cli-plugin?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-secret-groups-cli) that controls who on your team has access to cluster secrets.

--sm-instance INSTANCE
: Optional. The CRN of the Secrets Manager instance.
Continuous Delivery pipelines run the jobs and steps that you provide. The Continuous Delivery service securely manages the log output and build artifacts that are produced by your pipeline runs. However, Continuous Delivery does not limit or manage the function of your pipeline job or step scripts.

When you develop and configure your pipeline job and step scripts, ensure that your scripts do not run actions that might compromise the confidentiality, integrity, or availability of your resources, or otherwise violate regulatory controls.

To learn more about Delivery Pipelines, see and [Working with pipelines](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-deliverypipeline_about) and [Working with Tekton pipelines](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-tekton-pipelines).





 Deleting your data from Continuous Delivery 

When you delete a Continuous Delivery service instance, the related toolchains, tool integrations, tools, and data (including personal data) are not deleted. For more information about how to manage and delete data that is stored with toolchains, tool integrations, and tools, see [Modifying, exploring, and deleting personal data](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_personal_datamanaging_personal_data).
name = "tf-toolchain-secret-refs"
resource_group_id = data.ibm_resource_group.rg.id
}

resource "ibm_iam_authorization_policy" "s2s" {
source_service_name = "toolchain"
source_resource_instance_id = ibm_cd_toolchain.toolchain.id
target_service_name = "secrets-manager"
target_resource_instance_id = data.ibm_resource_instance.sm.guid
roles = ["Viewer", "SecretsReader"]
}

resource "ibm_cd_toolchain_tool_secretsmanager" "integration" {
toolchain_id = ibm_cd_toolchain.toolchain.id
parameters {
name = "my-sm-tool-integration"
instance_id_type = "instance-crn"
instance_crn = data.ibm_resource_instance.sm.resource_crn
}
depends_on = [
ibm_iam_authorization_policy.s2s
]
}

resource "ibm_cd_toolchain_tool_slack" "integration" {
toolchain_id = ibm_cd_toolchain.toolchain.id
parameters {
webhook = ibm_sm_arbitrary_secret.key.crn
channel_name = var.slack_channel
team_name = var.slack_team
}
depends_on = [
ibm_cd_toolchain_tool_secretsmanager.integration
]
}









 Protecting your data with customer-managed keys 

By default, Continuous Delivery encrypts your data by using keys that are internal to the Continuous Delivery service. For greater security and control, you can configure Continuous Delivery to encrypt your data by using keys that you manage. This option is available only under the Professional plan, and only at the time that you are provisioning an instance of the Continuous Delivery service.
IAM is used to control user access to the console UI as well as restricting the actions they can perform in the UI. See this topic for information on how to [add and remove users from the console](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-manage-consoleibp-console-manage-console-add-remove).





 3 April 2019 

Support for external CA

When you add a peer or orderer node, you have the option to use certificates from an external CA, one that is not hosted by IBM. See this topic on [Using certificates from an external CA with your peer or ordering node](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-third-party-ca) for more information.

Tuning orderer performance

New orderer tuning parameters are available in the console to give you more control over your orderer throughput and performance. See this topic on [Tuning your orderer](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-governibp-console-govern-orderer-tuning) for instructions on how to configure the parameters.
For more information about adding and removing vault integrations, including prerequisites and by using hints, see [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud).

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.

This tutorial uses the [IBM Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started) as the secrets vault.

Zoom

![VPC secure app secrets options](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds-vpc-setup-secrets.png)

Figure 5. VPC secure app secrets options

IBM Secrets Manager securely stores and applies secrets such as API keys, Image Signature, or HashiCorp credentials that are part of your toolchain.

Zoom

![Secrets Manager options](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds-vpc-setup-secrets-manager.png)

Figure 6. Secrets Manager options
* As a Key Custodian - Creator, you can create and manage keys in Unified Key Orchestrator. For a complete key lifecycle, both the Key Custodian - Creator and Key Custodian - Deployer roles are needed.
* As a Key Custodian - Deployer, you can deploy and manage keys in Unified Key Orchestrator. For a complete key lifecycle, both the Key Custodian - Creator and Key Custodian - Deployer roles are needed.



To implement separation of duties, assign Key Custodian - Creator and Key Custodian - Deployer roles to different people.

The following table shows how service access roles map to Hyper Protect Crypto Services permissions. IAM roles are the default roles provided. You can also [define and create service-level custom roles](https://cloud.ibm.com/docs/account?topic=account-custom-roles) according to the needs of your enterprise.



* Trusted Key Entry (TKE) uses either smart cards or software CLI plug-in with IAM authentication. Commands that deals with managing keys locally on the smart card or CLI are not included. Those commands do not interact with the HSM domain.
* Unified Key Orchestrator is used for multicloud key management and orchestration. Apart from setting default IAM roles, you can also [create custom Unified Key Orchestrator roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-role-best-practices) according to your needs.
* HSM APIs (the PKCS #11 API and the GREP11 API) are used for application-level encryption.
* Key Management Interoperability Protocol (KMIP) adapter is used to configure the KMIP for VMware service with Hyper Protect Crypto Services to enable vSphere encryption or vSAN encryption by using your own root keys.



Trusted Key Entry commands

Unified Key Orchestrator

Key management service



Table 3. Lists service access roles as they apply to Hyper Protect Crypto Services TKE commands

 Action Reader ReaderPlus Writer Manager
Identity and access management includes tasks such as authentication, authorization, access control policies, and approving, granting, and revoking access.



Table 3.Identity and access management

 Task IBM responsibilities Your responsibilities 

 Access control of the service instance through IAM Verify the user's permissions on the service instance before allowing access. Maintain responsibility for any service roles that you create for your instances. 







 Security and regulation compliance 

Security and regulation compliance includes tasks such as security controls implementation and compliance certification.



Table 4.Security and regulation compliance

 Task IBM responsibilities Your responsibilities 

 General <br><br> * Maintain controls commensurate to various industry compliance standards.<br> * Monitor, isolate, and recover instances.<br> * Monitor and report the health of instances in the various interfaces.<br> * Secure cluster access through TLS/SSH (data plane in the IBM Services account).<br> * Integrate watsonx.data with IBM Cloud Identity and Access Management (IAM).<br><br><br> Set up and maintain security and regulation compliance for the watsonx.data instances. 







 Disaster recovery 



Table 5.Disaster recovery

 Task IBM responsibilities Your responsibilities 

 General <br><br> * Restore or rebuild the provisioning environments in the affected regions.<br> * Restore existing watsonx.data instances, where possible.<br><br><br> <br><br> * Track instance state.<br> * Provision new watsonx.data instances in alternatively available regions.<br> * Ensure that the watsonx.data instance is stateless by making sure that all data, metadata and applications reside outside of the cluster. This activity must be completed before disaster recovery can be initiated.<br> * Provision a new service instance in an alternatively available region if the current instances can't be accessed.<br><br><br>
Managing incident issues 

From a compliance perspective, creating, storing, and updating incident issues (vulnerability, CVE) as part of the [Continuous Integration](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-ci-pipeline) and [Continuous Compliance](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-cc-pipeline) pipelines are essential for evidence collection.

During the execution of the CI and CC pipelines, the [collect-evidence script](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-collect-evidence) creates incident issues, attaches them to the collected evidence, and stores them in the incident issue repository.

The collect-evidence script uses the functions of the [cocoa incident process](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cliincident-process) command, which processes the provided scan results and either creates new incident issues in the provided repository per vulnerability or updates the existing incident issues based on the subject-incident pairs. Therefore, the incident issues are bound to assets and created according to the results of specific tools. For more information, see [Difference between issue processing in CI and CC pipelines](https://cloud.ibm.com/docs/devsecops?topic=devsecops-incident-issuesprocessing-results-issues).



 Incident issue processing 

Even though the CI and CC pipelines have common steps, the issue processing of these pipelines has some differences:



* Incident issues that are created during the CI pipeline do not carry a due date, while incident issues that are created during the CC pipeline do.
* Incident issues that are created during the CI pipeline are found during the build, while incident issues that are created during the CC pipeline are found in the production environment.



Figures 1 - 6 show the possible use cases that are based on these differences.



 DevSecOps/one pipeline lifecycle 

The DevSecOps/one pipeline lifecycle extends from code PRs to production scans.
},
{
"cve": "SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-31517",
"expiration": "2022-02-10T22:08:41+04:00",
"comment": "Additional security measures are in place"
}
]





 Example 

The following code snippets show how to use the vulnerability-scan command:

ibmcloud cra vulnerability-scan --bom BOM [--cveignore CVEIGNORE] [--report REPORT] [--excludedev] [--include-nofix app,os,all,none] [--region REGION] [--strict] [--toolchainid TOOLCHAINID] [--output OUTPUTFILE]

ibmcloud cra cve --bom ./bom-file.json --cveignore ./cveignore-example.json --report ./output-vulnerability-report.json --excludedev --include-nofix all --strict







 Deployment 

The deployment-analyze command runs configuration checks on Kubernetes deployment manifests.

ibmcloud cra deployment-analyze

This command provides prescriptive guidance for establishing a secure configuration posture for Docker containers. The Code Risk Analyzer uses these security configurations as a point of reference and identifies security controls to check in deployment artifacts, such as .yaml files, for Kubernetes applications. This command also provides risk assessments for each control failure.

The following table lists the controls that you can implement within DevSecOps, as identified from CIS Docker 1.13.0. More controls are added based on open source references of the [Kubernetes Common Configuration Scoring System (KCCSS)](https://github.com/octarinesec/kccss).



Table 4. Security controls

 ID Rule Risk 

 5.3 Ensure that containers do not have the CAP_SYS_ADMIN capability. High 
 5.3 Ensure that containers do not have the CAP_NET_RAW capability. High
Guidance on operations 

This section provides guidance on running MS SQL on IBM Cloud VPC before and after the initial deployment of the the Microsoft SQL deployment patterns.

For more information, see [Understanding your responsibilities when using Virtual Private Cloud](https://cloud.ibm.com/docs/vpc?topic=vpc-responsibilities-vpcsecurity-compliance).



 Identity and Access Management 

Identity and Access Management (IAM) enables the control of resources in your IBM Cloud account. Resources are organized into resource groups and given access to account users and service IDs via IAM access policies. The adoption of the separation of duties principle ensures that your IBM Cloud users and service IDs have only the access that is required to perform their roles. Refer to the following to get an initial understanding of IBM Cloud IAM and to configure your IBM Cloud account to enable segregation of duties.



* [Access management in IBM Cloud](https://cloud.ibm.com/docs/account?topic=account-cloudaccess)
* [Best practices for organizing resources and assigning access](https://cloud.ibm.com/docs/account?topic=account-account_setup)
* [What is IBM Cloud Identity and Access Management](https://cloud.ibm.com/docs/account?topic=account-iamoverview)







 Activity Tracker 

IBM Cloud Activity Tracker records activities that change the state of a service in IBM Cloud via the UI/CLI/API. You can use the Activity Tracker service to investigate abnormal activity and critical actions and to comply with regulatory audit requirements. In addition, you can be alerted about actions as they occur. The events that are collected comply with the Cloud Auditing Data Federation (CADF) standard. Refer to [Activity Tracker](https://cloud.ibm.com/docs/vpc?topic=vpc-at-eventsevents-network-security-group) for information on what events are tracked in VPC and [Getting Started with Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-started).





 Flow Logs
Queue Manager <br><br> * Maintain controls to meet industry compliance standards such as ISO27k<br> * Provide default queue manager resources that are TLS enabled<br> * Monitor, isolate, and recover the queue manager<br> * Automatically apply security patch updates<br> * Disable certain insecure actions such as channel exits<br> * Continuously monitor queue manager images to detect vulnerability and security compliance issue<br><br><br> <br><br> * Configure queue manager security such as TLS and AMS on queue manager resources<br> * Configure authority records for queue manager resources to limit access to only required users and applications<br><br><br> 







 Disaster recovery 

You and IBM share responsibilities for the set up and maintenance of your IBM MQ on IBM Cloud environment. You are responsible for disaster recovery of your application data.



Table 6. Responsibilities for disaster recovery
The rows are read from left to right. The resource area of comparing responsibilities is in the first column, with the responsibilities of IBM in the second column and your responsibilities in the third column.

 Resource IBM responsibilities Your responsibilities 

 Queue Manager <br><br> * Backup queue manager configuration daily<br> * Recover required infrastructure<br> * Provision new infrastructure in a backup availability zone, if recovery is not possible<br> * Redeploy queue managers to new availability zone<br> * Restore queue manager configuration from previous backup<br><br><br> <br><br> * [Register for disaster recovery notifications](https://cloud.ibm.com/docs/services/mqcloud?topic=mqcloud-mqoc_dr_notifications)<br> * Reset channel sequence numbers so that channels will successfully communicate<br><br><br> 







 Applications and data 

You are completely responsible for the applications and data that you use with IBM MQ on IBM Cloud . However, IBM provides various tools to help you set up, manage, secure, integrate and optimize your apps as described in the following table.



Table 7. Applications and data
The rows are read from left to right.
Managing access for toolchains in resource groups 

Toolchains that you create in your account might not be visible to other users by default. Access to toolchains in resource groups for users in your account is controlled by [IBM Cloud Identity and Access Management (IAM)](https://cloud.ibm.com/docs/services/account?topic=account-iamoverview). You can assign access to [new users](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-toolchains-iam-securitytoolchains-access-new-users) and [existing users](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-toolchains-iam-securitytoolchains-access-existing-users) in your account.

User access for Continuous Delivery service instances is managed separately. For more information about managing user access to Continuous Delivery service instances in resource groups, see [Managing user access to Continuous Delivery with Identity and Access Management](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-cd-iam-security).

Every user that accesses toolchains in your account must be assigned an IAM access policy. The policy determines which toolchains the user can access and what actions the user is allowed to take.

Policies enable access to be granted at different levels or scopes, including, but not limited to:



* Access across all toolchains in your account
* Access across all toolchains in a resource group in your account
* Access to a specific toolchain in your account



After you define the scope of the access policy, you assign a role. The role defines which actions the user is allowed to take. The following table lists the IAM platform access roles and the available toolchain actions for each role.



Table 1. IAM platform roles

 Platform Role Description of Actions Example Actions 

 Viewer View toolchains and delivery pipelines. <br><br> * Click a toolchain to open its Overview page.<br><br><br>