vania-janet/multiturn-rag-retrieval-data huggingface dataset:
kit_igsexe_file = "/storage/NW75HDB/igsexe_13-80003187.sar"
kit_igshelper_file = "/storage/NW75HDB/igshelper_17-10010245.sar"
kit_saphotagent_file = "/storage/NW75HDB/SAPHOSTAGENT51_51-20009394.SAR"
kit_hdbclient_file = "/storage/NW75HDB/IMDB_CLIENT20_009_28-80002082.SAR"
kit_nwhana_export = "/storage/NW75HDB/ABAPEXP"
5. Initialize the Terraform CLI.

terraform init
6. Create a Terraform execution plan. The Terraform execution plan summarizes all the actions that are done to create the virtual private cloud instance in your account. During the Terraform plan, you are prompted to enter your API key, and initial SAP and DB passwords.

terraform plan --out plan1

You must enter an SAP main password.

The SAP main password must be 10 - 14 characters long and contain at least one digit (0-9). It can contain only the following characters: a-z, A-Z, 0-9, @, #, $, _. This password cannot contain !. It must not start with a digit or an underscore ( _ ).
7. Verify that the plan shows all of the resources that you want to create and that the names and values are correct. If the plan needs to be adjusted, edit the input.auto.tfvars file to correct resources and run \terraform plan --out plan1 again.
8. Create the virtual private cloud for SAP instance and IAM access policy in IBM Cloud.

terraform apply "plan1"

The virtual private cloud and components are created and you see output similar to the terraform plan output.







 Next steps
The value of this property is either a CVE ID or a Snyk ID.
* alwaysOmit - If this property is set to true, the vulnerability is omitted until it is changed. This property takes precedence over other property values.
* untilRemediationAvailable - If this property is set to true, the vulnerability is omitted until a remediation path is available. If a remediation becomes available, the vulnerability is not omitted and a message is displayed. This property takes precedence over the expiration property value.
* expiration - If this property is set to true and the expiration date is not reached, the vulnerability is omitted. If the expiration date is reached, the vulnerability is not omitted and a message is displayed. Use the RFC3339 time format (yyyy-MM-ddTHH:mm:ss[+-]Z) to define this property.



The Code Risk Analyzer uses only these defined properties. You can add properties with no effect on functions. If a vulnerability that is defined in the .cveignore is not omitted, a log is generated that explains the reason. If a vulnerability that is defined in the .cveignore file is omitted, no individual logging is displayed. The number of omissions and a list of the vulnerability IDs, with the package name, that are omitted are logged after a report is completed.

The following code snippet shows a sample .cveignore file:

[
{
"cve": "CVE-2021-27290",
"alwaysOmit": true
},
{
"cve": "CVE-2020-8244",
"untilRemediationAvailable": true,
},
{
"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:
sha: b0fff29d715e0f9a33b3c84e649777cfb9d40738
- path: icr-va
repo: <REPO URL>
sha: de693814ba2bd992941b432fc71111efb54e2b27

Using the following defaults for stage "scan-artifact":

scan-artifact:
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
dind: false
abort_on_failure: false
image_pull_policy: IfNotPresent
script: 
!/bin/sh

"/opt/commons/scan-artifact/scan.sh"

Show more

This message has three parts:



1. The first line shows the exact script URL currently running, pointing to it on a commit level.
2. The second part is a list of paths, repos, and commit hashes that are imported to the pipeline base image during the build. They are not pulled from these repos in runtime. This information improves public traceability of what exactly is included in the pipeline.
3. The third part is the default configuration that is used as the config YAML. You can take this YAML snippet and include it in your DevSecOps config YAML file. This action overrides the default config with yours but still uses the default script from the base image. This method is helpful if you want to implement some other checks before the default ones.



This information is displayed to help adopters identify the scripts that are running in stages by default. Then, they can inspect the scripts, understand what they do, copy the script into their script collection, and update them to fit their use cases.
* Image tags: 1.19.1-105-3, 1.20.0-105-3, 1.21.0-105-3, 1.22.0-105-3, 1.23.0-105-3
* All non-deleting workers are considered while scaling up.
* Worker deletion is not retried while scaling down.







 Change log for patch update 1.0.5_728, released 19 July 2022 



* Image tags: 1.19.1-105-2, 1.20.0-105-2, 1.21.0-105-2, 1.22.0-105-2, 1.23.0-105-2
* Resolves [CVE-2022-29526](https://nvd.nist.gov/vuln/detail/CVE-2022-29526).







 Change log for patch update 1.0.5_694, released 30 June 2022 



* Image tags: 1.19.1 105-1, 1.20.0 105-1, 1.21.0 105-1, 1.22.0 105-1, 1.23.0 105-1
* Adds logging improvements.







 Change log for patch update 1.0.5_628, released 16 May 2022 



* Image tags: 1.19.1-105-0, 1.20.0-105-0, 1.21.0-105-0, 1.22.0-105-0, 1.23.0-105-0
* Resolves [CVE-2022-28327](https://nvd.nist.gov/vuln/detail/CVE-2022-28327), [CVE-2022-24675](https://nvd.nist.gov/vuln/detail/CVE-2022-24675), and [CVE-2022-27536](https://nvd.nist.gov/vuln/detail/CVE-2022-27536).
* Ignores label ibm-cloud.kubernetes.io/vpc-instance-id for zone balancing in satellite environments.
* Image tags: 1.19.1-106-1, 1.20.0-106-1, 1.21.0-106-2, 1.22.0-106-2, 1.23.0-106-2, 1.24.0-106-2
* All non-deleting workers are considered while scaling up.
* Worker deletion is not retried while scaling down.







 Change log for patch update 1.0.6_742, released 15 July 2022 



* Adds support for Kubernetes 1.24.
* Resolves [CVE-2022-29526](https://nvd.nist.gov/vuln/detail/CVE-2022-29526).
* Image tags: 1.19.1-106-2, 1.20.0-106-2, 1.21.0 106-1, 1.22.0 106-1, 1.23.0 106-1, 1.24.0 106-1









 Version 1.0.5 



 Change log for patch update 1.0.5_898, released 9 January 2023 



* Image tags: 1.19.1 105-6, 1.20.0 105-6, 1.21.0 105-6, 1.22.0 105-6, 1.23.0 105-6.
* Golang updated to 1.18.9
* Updates the storage-secret-sidecar image to v1.2.14
* Resolves the following CVEs: [CVE-2022-42898](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42898), [CVE-2022-41717](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41717), [CVE-2022-41720](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41720)
Complete list of scans to choose from: CRLF_Injection,Buffer_Overflow, Directory_Browsing, External_Redirect, Format_String_Error, Parameter_Tampering, Remote_File_Inclusion, Script_Active_Scan, Server_Side_Code_Injection, Server_Side_Include, SQL_Injection, Xpath_Injection, XXE_External_Entity, SOAP_Action_Spoofing, SOAP_XML_Injection, Relative_Path_Confusion, Remote_OS_Command_Injection, ElmahScanRule and, HtAccessScanRule. Optional 
 apisToScan Array List of APIs to scan along with required params. If "apisToScan": ["all"] is mentioned, then all APIs mentioned in the swagger definition are scanned with mock data for mandatory parameters/body. To customize this array to have selective APIs to be scanned, use this substructure apisToScan: [ { "path": "/path/to/endpoint", method: "get" } ]. Required 
 globalExcludeUrls Array Array of URL regexes to instruct ZAP not to scan for those routes. For example, "globalExcludeUrls": [ "^http://foo.bar$", "^http://john.doe$" ]. Optional 
 authenticationType String Authentication mechanism for request headers. Supported auth mechanisms are Bearer, Basic, or ApiKey. Optional 
 apiKey String If authenticationType is not sent, this API key is used for IAM authentication that is sent in Authorization header for all requests. If authenticationType is set to Bearer, the header that is formed is Authorization: Bearer <apiKey>. If authenticationType is set to ApiKey, the header that is formed is Authorization: <apiKey>. Field is ignored for authenticationType as Basic. Optional 
 username String Username to be used for authenticationTypeBasic. Required if authenticationType as Basic 
 password String Password to be used for authenticationTypeBasic. Required if authenticationType as Basic 



For sensitive information like credentials, you must read these values from a vault or a secret store.





 Configuring ZAP UI scans
This action means that you must unwrap them again by using IBM Key Protect and the valid root key.

For example, to wrap keys by using the CLI, run the command "ibmcloud kp key wrap <root_key_id> -p <base64 encoded image key>" and to unwrap keys, run the command "ibmcloud kp key unwrap <root_key_id> -p <base64 cyphertext>, where <root_key_id> is the ID of the root key that you are using.

For more information about how you can protect your keys in your own store by using an IBM Key Protect root key to wrap them, see [Wrapping keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-wrap-keys).

Encrypted images are not scanned by Vulnerability Advisor.





 Next steps 

Run your encrypted image in a Red Hat® OpenShift® on IBM Cloud® cluster by using the [Image Key Synchronizer cluster add-on](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesencrypted-images).
The all option is used to include both app and OS package CVEs with no fixes. The none option is used to exclude both app and OS package CVEs with no fixes. 
 --path Required if --autofix enabled The project directory path to scan. This command is available only with autofix. 
 --region Optional The ibmcloud region for the toolchain. 
 -r, --report Optional The path to the generated report. 
 -o, --output Optional Selects the CVE report format. You can generate the format output in either Standard CVE format (standard) or CycloneDX's VEX format (cyclonedx). The default value is standard. 
 -s, --strict Optional Results in command failure (exit status 2) when vulnerabilities are found. 
 --toolchainid Optional The ID of the target toolchain. 







 Ignoring vulnerabilities 

If the -c or --cveignore parameter is specified, the command looks for that file and does not report the CVEs that are specified in the file. You can configure the CVEs to omit them indefinitely until a remediation is available, or until a specified expiration date.

The following example shows a JSON schema for the .cveignore file:

[
{
"cve": "string",
"alwaysOmit": "bool",
"untilRemediationAvailable": "bool",
"expiration": "string"
}
]

The following properties are supported for each entry in the .cveignore file:



* cve - The vulnerability to omit. The value of this property is either a CVE ID or a Snyk ID.
* alwaysOmit - If this property is set to true, the vulnerability is omitted until it is changed. This property takes precedence over other property values.
* untilRemediationAvailable - If this property is set to true, the vulnerability is omitted until a remediation path is available. If a remediation becomes available, the vulnerability is not omitted and a message is displayed.
Omitting vulnerabilities found by the Code Risk Analyzer 

Under exceptional circumstances, you might need to deploy your application even though it uses vulnerable packages. The Code Risk Analyzer's (CRA) function is to find vulnerable packages before an advisory does.

Whenever possible, update vulnerable packages or remove them.

You can create the file .cra/.cveignore (formerly .cracveignore) in the scanned repository's root with the following schema:

[
{
"cve": "string",
"alwaysOmit": "bool",
"untilRemediationAvailable": "bool",
"expiration": "string"
},
]

The following code snippet shows a sample .cveignore file:

[
{
"cve": "CVE-2021-27290",
"alwaysOmit": true
},
{
"cve": "CVE-2020-8244",
"untilRemediationAvailable": true,
},
{
"cve": "SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-31517",
"expiration": "2022-02-10T22:08:41+04:00",
"comment": "Additional security measures are in place"
}
]

The previously used .cracveomit file is deprecated now and replaced by .cra/.cveignore.

You can learn more about the Code Risk Analyzer [plug-in's docs](https://cloud.ibm.com/docs/code-risk-analyzer-cli-plugin), or you can also check the [deprecated CRA docs](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd-configure-cra-repos).
The following example .fileignore file shows how to exclude bash scripts, node_modules, and the Dockerfile.

 Ignore nested functional_tests directory
/functional_tests

 Ignore bash scripts
/.sh

 This should allow this one file
!test/gatling_tests/loginTobx.sh

 Ignore node_modules
node_modules

 Exclude the dockerfile from scanning
Dockerfile





 Example 

The following code snippets show how to use the bom-generate command:

ibmcloud cra bom-generate --path PATH --report REPORT [--asset-type ASSET-TYPE] [--dockerbuildcontext] [--dockerbuildflags DOCKERBUILDFLAGS] [--dockerfilepattern DOCKERFILEPATTERN] [--gradle.excludeconfigurations GRADLE.EXCLUDECONFIGURATIONS] [--maven.excludescopes MAVEN.EXCLUDESCOPES] [--nodejs.createpackagelock] [--prev-report PREV-REPORT] [--region REGION] [--toolchainid TOOLCHAINID] [--verbose]

ibmcloud cra bom --path . --report bomreport.json







 Vulnerability scan 

The vulnerability-scan command expects a BOM file in standard format as input and detects vulnerabilities in application packages and OS packages that are listed in the BOM file. Based on rich threat intelligence from Snyk, targeted fix recommendations are provided. Code Risk Analyzer can also perform auto-remediation on vulnerable packages for Node.js based applications only. You can also generate this report in the standard format or in CycloneDX's Vulnerability Exploitability Exchange (VEX) format.

ibmcloud cra vulnerability-scan



 Vulnerability scan command options 

The following table lists the options for using the vulnerability-scan command.



Table 3. Command options for performing a vulnerability scan

 Command options Required or optional Description
"checksum": "2342342", // the digital signature of the image
"verified": "yes"|"no"], // checksum verified or not
"issues": 134, 132, 343], // link(s) to the issues representing missing or not matching checksums
"required": "yes"|"no"] // yes: this is an auditable step; no: this is a non auditable step
}, {
"evidence_type_id": "com.ibm.files_signature",
"version": "1.0.0",
"date": "2020-05-06T12:00:00Z", // date of task run
"origin": {
"url":"https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines/-/blob/master/definitions/mytask.yaml", // where the task is taken from
"version": "423792" // commit id representing the task version used to produce the evidence
}
"toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/190e0b4ce4cd013159917665213ddc51:7467a214-f404-4e23-acab-2e57e935d138::" // CRN of the toolchain
"pipeline_id": "b1cfb6a4-813d-4fec-bbf7-ce662e8ce4e0", // the id of the pipeline that generated this piece of evidence
"pipeline_run_id": 12345, // this is the id of the pipeline run that generated this piece of evidence
"name": "dhksd", // the name of the image
"checksum": "2342342", // the digital signature of the file
"verified": "yes"|"no"], // checksum verified or not
* Level 3: Provides a high probability of detecting and responding to attempts at physical access, use, or modification of the cryptographic module. The physical security mechanisms can include the use of strong enclosures and tamper-detection and response circuitry that zeroizes all plain text CSPs when the removable covers or doors of the cryptographic module are opened. Security Level 3 requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication mechanisms specified for Security Level 2.
* Level 4: The highest level of security. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a high probability of being detected, resulting in the immediate zeroization of all plain text CSPs.

Security Level 4 cryptographic modules are useful for operation in physically unprotected environments. Security Level 4 also protects a cryptographic module against a security compromise because of environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature. Intentional excursions beyond the normal operating ranges can be used by an attacker to prevent a cryptographic module's defenses.

A cryptographic module is required to either include special environmental protection features designed to detect fluctuations and delete CSPs, or to undergo environmental failure testing to ensure that the module will not be affected by fluctuations outside of the normal operating range in a manner that can compromise the security of the module. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.

Hyper Protect Crypto Services is the only cloud HSM in the public cloud market that is built on an HSM designed to meet FIPS 140-2 Level 4 certification requirements. The certification is listed on the [Cryptographic Module Validation Program (CVMP) Validated Modules List](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/Validated-Modules).







 How to understand the key hierarchy for Hyper Protect Crypto Services KYOK? 

The following table lists the keys that are needed for Hyper Protect Crypto Services Keep Your Own Key (KYOK) functionality.



Table 1.
Intel Software Guard Extensions (SGX) is a technology that can protect data-in-use through hardware-based server security. With Intel SGX, you can protect select code and data from disclosure or modification. Through the use of trusted execution environments (TEE), known as enclaves, you can encrypt the pieces of your app memory that contain sensitive data while the data or code is being used. To use Intel SGX, you must install the SGX drivers and platform software on SGX-capable worker nodes. Then, design your app to run in an SGX environment.

Zoom

![An example SGX application.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cc-iks.png)

Figure. Example SGX application set up

When you develop a confidential computing application, you must design it in a way that you can segment the information that needs to be encrypted. At runtime, the segmented information is kept confidential through attestation. When a request for information from the segmented code or app data is received, the enclave verifies that the request comes from the part of the application that exists outside of the enclave within the same application before sharing any information. Through the attestation process, information is kept confidential and data leakage is prevented.



 Installing with a script 

Before you begin, [create a worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersadd_pool) with SGX-capable worker nodes. To work with Intel SGX, you must use one of the following machine types: me4c.4x32 and me4c.4x32.1.9tb.ssd.



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2.
"required": "yes" | "no" ] // yes: this is an auditable step; no: this is a non auditable step
}, {
"evidence_type_id": "com.ibm.static_scan",
"version": "1.0.0",
"date": "2020-05-06T12:00:00Z", // date of task run
"origin": {
"url":"https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines/-/blob/master/definitions/mytask.yaml", // where the task is taken from
"version": "423792" // commit id representing the task version used to produce the evidence
}
"toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/190e0b4ce4cd013159917665213ddc51:7467a214-f404-4e23-acab-2e57e935d138::" // CRN of the toolchain
"pipeline_id": "b1cfb6a4-813d-4fec-bbf7-ce662e8ce4e0", // the id of the pipeline that generated this piece of evidence
"pipeline_run_id": 12345, // this is the id of the pipeline run that generated this piece of evidence
"last_scan_date": "24-03-2020 UTC", // the last time the scan was run
"result": "passed"|"failed"], // the result of the scan
"log": {
"url": "https://acme.org/log.txt", // the link to where the actual log of the test is
"hash": "abc123", // the hash of the log file
},
The ZAP API scans the application endpoints for possible data leakages, content-type errors, external redirects, code injection, SQL injection, remote OS command injection, and other vulnerabilities that are exposed by the application. The ZAP API scans help developers secure the application by detecting these vulnerabilities in a stage or test environment and fixing them before the application is deployed on a production environment.

ZAP API scans require the following inputs to scan your application:



* Swagger Definition File - Describing the HTTP APIs and their associated parameters as exposed by the app.
* API Key - Authentication token that is required to authenticate with the API endpoints.
* API Endpoint - Endpoints from the swagger definitions that you want ZAP to scan.
* Excluded URLs - The URLs to be ignored by ZAP scanner.



The ZAP API Scanner uses the inputs that are mentioned to run scan and produce a report.

Set opt-in-dynamic-api-scan to a nonempty value for ZAP API scans to run. To opt out, set this parameter to empty.





 ZAP UI Scan 

ZAP UI scans the application endpoints for vulnerabilities on the web pages themselves, like unsecure cookies that are being set, improper caching header settings, cross domain file inclusions, improper CORS settings, and other vulnerabilities that are exposed by the application.

UI scans work similarly to API scans, but they use a UI test script instead of a Swagger file. The UI test script starts a headless browser that is configured to proxy through the ZAP scanner's proxy, and it runs a UI test against the UI endpoint. The process to run ZAP UI tests is as follows:



* Copy the tests scripts to the ZAP Scanner containers.
* Run the ZAP Proxy.
* Run the zap test scripts.



The ZAP proxy records the traffic and discovers the endpoints to scan. After the scans are finished, the proxy produces a report and generates issues the same way as in the ZAP API scan.

Set opt-in-dynamic-ui-scan to a nonempty value for ZAP API scans to run. To opt out, set this parameter to empty.
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/) here.

Make sure that you add the correct login credentials and host URL to the configuration file.





 Using another static scan implementation 

You can modify your .pipeline-config.yaml file to add your own custom script to the static-scan stage to use your own static scan implementation.







 Learn more about SonarQube 

To learn more about SonarQube, see [Integrate your SonarQube analysis into your toolchain](https://www.ibm.com/blogs/cloud-archive/2017/06/integrate-sonarqube-analysis-into-your-toolchain/).