vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"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
"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
},
"expired_issues": 134,132,342], // link(s) to the issues for which the grace period expired
"issues": 234,343,342], // link(s) to the issue(s) created to track the bugs found during the test run. Should be populated only if the scan failed
"required": "yes" | "no" ] // yes: this is an auditable step; no: this is a non auditable step
}, {
// build input
// Partial: SI-7(12) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRITY VERIFICATION
// The organization requires that the integrity of Assignment: organization-defined user-installed software] be verified prior
// to execution.
// Control passed if:
// 1- the script is one of the blessed ones AND
// 2- the checksum is verified OR
// 3- the cheksum is not verified AND issues have been opened AND prod CR approved manually)
// Partial: RA-5(a) Scans for vulnerabilities in the information system and hosted applications Assignment: organization-defined
// frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting
// the system/applications are identified and reported;
// Partial: RA-5(b). Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts
RA-5 (2) - Update by Frequency / Prior to New Scan / When Identified 



  Control requirements 

RA-5 (2) - 0
:   The organization updates the information system vulnerabilities scanned [IBM Assignment: prior to a new scan].





  IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



*  Check whether DevSecOps Toolchain scans build artifacts to identify vulnerabilities
*  Check whether Container Registry Vulnerability Advisor scans for critical or high vulnerabilities in the system at least every # day(s)
*  Check whether DevSecOps Toolchain validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely
*  Check whether DevSecOps Toolchain passes dynamic code scan to identify vulnerabilities in deployed artifacts
*  Check whether DevSecOps Toolchain scans source code and their dependencies to identify vulnerabilities
*  Check whether DevSecOps Toolchain source code contains no secrets
*  Check whether DevSecOps Toolchain passes static code scan to identify vulnerabilities in source code
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 

 -b, --bom Required The file path of the BOM file that was generated by using the bom-generate command. This BOM file must be in standard format. 
 -a, --autofix Optional Fixes specific types of app vulnerabilities. This option is available only for Node.js, Maven, and Gradle apps. 
 -f, --commentfile Optional Specifies the file where the markdown report is created. This command is available only with autofix. 
 -c, --cveignore Optional The file path of the CVE Ignore file that contains the list of CVEs to ignore. 
 -e, --excludedev Optional Specifies that you do not want the command to report CVEs for development dependencies. 
 --force Optional Forces an update for top-level node packages, even when the major version is different. This command is available only with autofix. 
 --include-nofix Optional Include or exclude the reporting of CVEs that do not have known remediations. By default, this option is set to app. The app option is used to include only app package CVEs with no fixes. The os option is used to include only OS package CVEs with no fixes. 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.
RA-5 (c) <br><br> * Check whether DevSecOps Toolchain scans build artifacts to identify vulnerabilities<br> * Check whether DevSecOps Toolchain validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely<br> * Check whether DevSecOps Toolchain passes dynamic code scan to identify vulnerabilities in deployed artifacts<br> * Check whether DevSecOps Toolchain scans source code and their dependencies to identify vulnerabilities<br> * Check whether DevSecOps Toolchain source code contains no secrets<br> * Check whether DevSecOps Toolchain passes static code scan to identify vulnerabilities in source code<br> * Check whether DevSecOps Toolchain passes acceptance tests to validate every deployment<br><br><br> 
 RA-5 (d) <br><br> * Check whether DevSecOps Toolchain scans build artifacts to identify vulnerabilities<br> * Check whether DevSecOps Toolchain validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely<br> * Check whether DevSecOps Toolchain passes dynamic code scan to identify vulnerabilities in deployed artifacts<br> * Check whether DevSecOps Toolchain scans source code and their dependencies to identify vulnerabilities<br> * Check whether DevSecOps Toolchain source code contains no secrets<br> * Check whether DevSecOps Toolchain passes static code scan to identify vulnerabilities in source code<br> * Check whether DevSecOps Toolchain passes acceptance tests to validate every deployment<br><br><br> 







 NIST supplemental guidance 

Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches.
IBM performs external and internal vulnerability scanning and subsequent remediation in all IBM Maximo Application Suite SaaS environments on a quarterly basis per IBM IT Security Standards (ITSS). This includes Operating System, Middleware, Application and TCP/IP vulnerability scanning.

Vulnerabilities are assigned individual vulnerability ratings and exploitation categories (Critical, High, Medium or Low). These ratings are used to determine an IBM mandated time requirement to remediate and resolve the vulnerability.

Vulnerability scanning results and logs are considered IBM Confidential Information and are not disclosed to customers or prospects.

SQL Injection - please see FAQ link below regarding how Maximo protects against SQL injection: [https://www-01.ibm.com/support/docview.wss?uid=swg21419049](https://www-01.ibm.com/support/docview.wss?uid=swg21419049)





 Security Services 

The IBM Maximo Application Suite SaaS team provides the following security and system access services. These services are included as part of the IBM Maximo Application Suite as a Service:

Setup of SSL certificates and DNS registration. This is standard by default and allows for secure browser based HTTPS (encrypted) access IBM Maximo Application Suite SaaS end users.

Setup of IPsec Virtual Private Network (VPN) between client locations and IBM Cloud data center(s). VPN setup is optional, and is used to provide the following:



* Direct read-only access to IBM on Cloud databases
* LDAP authentication



Other uses are not currently available using VPN.

Setup and configuration of SSO including OIDC (default), SAML and LDAP user authentication for IBM Maximo Application Suite applications. SSO configuration is optional but is included as part of the IBM on Cloud subscription.





 Compliance - AWS (Infrastructure) 

All IBM Maximo Application Suite SaaS customer environments are managed to IBM IT Security Standards (ITSS) defined by IBM’s Chief Information Security Officer (CISO). This includes vulnerability scanning and subsequent remediation

AWS holds ISO-27001 certification and can provide SOC 1, 2 and 3 reports to customers

AWS (IaaS) ISO information:
(https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/trusted_story.svg)

Figure 1. Deploying containers with trusted content



1. Content Trust for your images: Ensure the integrity of your images by enabling content trust in your IBM Cloud Container Registry. With trusted content, you can control who can sign images as trusted. After trusted signers push an image to your registry, users can pull the signed content so that they can verify the source of the image. For more information, see [Signing images for trusted content](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent).
2. Container Image Security Enforcement: Use an admission controller with custom policies so that you can verify container images before you deploy them. With a container image security enforcement project like [Portieris](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec), you control where the images are deployed from and ensure that they meet [content trust](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent) requirements. If a deployment does not meet the policies that you set, security enforcement prevents modifications to your cluster.
3. Image Vulnerability Scanner: By default, Vulnerability Advisor scans images that are stored in IBM Cloud Container Registry to find potential security vulnerabilities. For more information, see [Managing image security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index).
4. IBM Cloud Security and Compliance Center: When you enable IBM Cloud Security and Compliance Center, you can view reports about suspicious incoming and outgoing network traffic. For more information, see [What is IBM Cloud Security and Compliance Center?]
[Secrets options](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/cd-only-satellite-secrets.png)

Figure 5. 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 details](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/cd-only-satellite-secrets-manager.png)

Figure 6. Secrets Manager details

For more information about managing your secrets in IBM Key Protect or HashiCorp, see [IBM Key Protect](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-tekton-ci-compliancecd-devsecops-key-protect-ci) or [HashiCorp](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-tekton-ci-compliancecd-devsecops-vault-ci).





 Step 4: Update the Satellite Config settings 

The IBM Cloud Satellite Config tool delivers deployment configurations to specified cluster groups. The directory path of the source repo identifies which files to deploy to the provided cluster group.



 Configure the target Red Hat OpenShift cluster to deploy the app to 

If the API key has the required access, the following fields automatically load by using the API key that is either created, retrieved from a vault, or manually specified. If the API key is valid, values for the Branch name and Cluster group are automatically populated. You can update any of these fields to match your configuration.
Update Vulnerability Advisor to version 4 by 19 June 2023 

The Vulnerability Advisor component of IBM Cloud® Container Registry is being updated. From 19 June 2023, Vulnerability Advisor version 3 will be replaced as the default by Vulnerability Advisor version 4.

Vulnerability Advisor version 3 is being deprecated as the default on 19 June 2023. From 19 June 2023, the default will be Vulnerability Advisor version 4. If you have version 3 set as the default, you can continue to use version 3 until the end of support date. An end of support date is not available yet.



 What you need to know about this change 

If you use the IBM Cloud console to access Vulnerability Advisor, no action is required. The IBM Cloud console is automatically updated to Vulnerability Advisor version 4.

If you use the IBM Cloud CLI and you want to use version 4 as the default, you must update the Container Registry CLI plug-in to version 1.0.0, or later, by 19 June 2023. Updating the Container Registry CLI plug-in to version 1.0.0, or later, enables the ibmcloud cr va command and the --va option on the ibmcloud cr images and ibmcloud cr digests commands to work with Vulnerability Advisor version 4.

On 19 June 2023, when the default changes to Vulnerability Advisor version 4, the Container Registry CLI automatically starts to use this version unless the ibmcloud cr va-version-set v3 command was run, in which case Vulnerability Advisor version 3 continues to be used. You can use the ibmcloud cr va-version command to determine which Vulnerability Advisor version is being used and the ibmcloud cr va-version-set v4 command to switch to Vulnerability Advisor version 4. When Vulnerability Advisor version 3 reaches its end of support date, any Container Registry CLI commands that access Vulnerability Advisor version 3 cease to work. An end of support date is not available yet.

If you use the Vulnerability Advisor REST API to access Vulnerability Advisor, you must update your client call from /va/api/v3 APIs to /va/api/v4 APIs.

If you use one of the Vulnerability Advisor version 3 SDKs to access Vulnerability Advisor, you must update to the Vulnerability Advisor version 4 SDK.

Any exemptions that you previously defined continue to work.
* To identify your image by tag, run the ibmcloud cr image-list command. Combine the content of the Repository column (repository) and Tag column (tag) separated by a colon (:) to create the image name in the format repository:tag. If a tag is not specified in the image name, the image that is tagged latest is deleted by default.







 Example 

Display details about the exposed ports for the image us.icr.io/birds/bluebird:1 by using the following formatting directive.

ibmcloud cr image-inspect --format "{{ .Config.ExposedPorts }}" us.icr.io/birds/bluebird:1







 ibmcloud cr image-list (ibmcloud cr images) 

Displays all tagged images in your IBM Cloud account. If you want to list all your images, including untagged images, run the [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_digests) command. By default, the ibmcloud cr image-list command returns the [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) for the images in a truncated format. The ibmcloud cr image-digests command returns the long format of the digest.

When you're using the digest to identify an image, always use the long format.

The image name is the combination of the content of the Repository and Tag columns in the format: repository:tag

From version 1.0.0 of the container-registry plug-in, you can choose whether to run the ibmcloud cr vulnerability-assessment command in either version 3 (the default) or version 4 of Vulnerability Advisor. If you want to run Vulnerability Advisor in a different version, see [Setting the Vulnerability Advisor version](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_set_version).
For more information about encrypted images, see [Using End to End (E2E) Encryption to provision an encrypted instance](https://cloud.ibm.com/docs/image-templates?topic=image-templates-using-end-to-end-e2e-encryption-to-provision-an-encrypted-instanceusing-end-to-end-e2e-encryption-to-provision-an-encrypted-instance).



Table 2. Values for importing an encrypted image from IBM Cloud Object Storage

 Field Value 

 Wrapped Data Encryption Key When you import an encrypted image, specify the ciphertext that is associated with the wrapped data encryption key (DEK) that is produced by wrapping the DEK you used to encrypt your image. For more information, see Wrapping keys using either the [IBM® Key Protect API](https://cloud.ibm.com/docs/key-protect?topic=key-protect-cli-referencekp-key-command) or the [IBM Cloud® Hyper Protect Crypto Services API](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-wrap-keyswrap-keys-api). 
 Key Management Service Instance Select a key management service instance in your account from the drop-down list (either the Key Protect service or the Hyper Protect Crypto service). The key management service instance must include the customer root key that you used to wrap your data encryption key. 
 Key Name Select the name of the root key within the key management service instance that you used to wrap your data encryption key. For more information, see [Viewing keys in Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keysview-keys) or [Viewing keys in Hyper Protect Crypto](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keysview-keys). 







 Next Steps 

After the import begins, the system locates the image file in the IBM Cloud Object Storage service instance in the specified bucket.
Depending on the app, to add extra security, you can establish a job that takes down vulnerable containers after they are detected.



You can use the built-in container registry to automate the container image build process from your source code in an external source repository to your internal registry. However, images are not automatically scanned for vulnerabilities when they are pushed to the internal registry. To set up image scanning, set up a registry namespace and push your images to the managed IBM Cloud Container Registry instead.

Zoom

![Deploying containers with trusted content](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/oc_image_security.png)

Figure 1. Deploying containers with trusted content

)



Security for images and deployments

 Security feature Description 

 Secured Docker private image repository in IBM Cloud Container Registry Set up your own Docker [image repository](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgetting-started) in a multi-tenant, highly available, and scalable private image registry that is hosted and managed by IBM. By using the registry, you can build, securely store, and share Docker images across cluster users. /n Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with container images. 
 Push images with trusted content only Ensure the integrity of your images by enabling [content trust](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent) in your image repository. With trusted content, you can control who can sign images as trusted and push images to a specific registry namespace. After trusted signers push an image to a registry namespace, users can pull the signed content so that they can verify the publisher and the integrity of the image.
When Vulnerability Advisor version 3 reaches its end of support date, any Container Registry CLI commands that access Vulnerability Advisor version 3 cease to work. An end of support date is not available yet.

If you use the Vulnerability Advisor REST API to access Vulnerability Advisor, you must update your client call from /va/api/v3 APIs to /va/api/v4 APIs.

If you use one of the Vulnerability Advisor version 3 SDKs to access Vulnerability Advisor, you must update to the Vulnerability Advisor version 4 SDK.

Any exemptions that you previously defined continue to work. However, the security notice value that comes back in Vulnerability Advisor version 4 might not be the same as for Vulnerability Advisor version 3 because different sources of data are used. Therefore, if the returned value isn't the same as for Vulnerability Advisor version 3, you might have to update any existing exemptions that specify a security notice. Red Hat® security notices are unaffected. Exemptions that are defined by CVE value are also unaffected.

Differences in Vulnerability Advisor version 4 behavior are documented in [About Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiabout).





 What actions you must take by 19 June 2023 

You can choose whether to update to use version 4, the default, or to continue to use version 3, which is deprecated.



* If you want to use Vulnerability Advisor version 4 as the default, update the following items as described in [What you need to know about this change](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_va_v4&interface=uinotices_va_v4_change):



* The Container Registry CLI plug-in and, if you have explicitly run the ibmcloud cr va-version-set v3 command previously, run the following command.

ibmcloud cr va-version-set v4
* Any code that calls Vulnerability Advisor version 3 either through the API or through the SDK.
* You might have to update any existing exemptions that specify a security notice.



* If you want to continue to use Vulnerability Advisor version 3, run the following command:

ibmcloud cr va-version-set v3