vania-janet/multiturn-rag-retrieval-data huggingface dataset:
RA-5 (3) - Breadth / Depth of Coverage 



  Control requirements 

RA-5 (3) - 0
:   The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked).





  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
Configuring Sysdig image scanning 

The Sysdig script runs the Sysdig inline scanner in your DevSecOps pipeline and collects evidence that is based on the scan results.

The Sysdig inline scanner scan runs for each image in the saved artifacts list_artifacts method. For more information, see [list_artifacts](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectllist_artifacts). This scan is run as a part of scan-artifact stage of CI and CC pipelines.

The script runs the Sysdig inline scanner image scan on the image and uploads the results to the given Sysdig URL instance.

To create an instance of IBM Cloud® Security and Compliance Center Workload Protection in IBM Cloud®, see [Provisioning an instance of Workload Protection](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-provision).



 Required Sysdig scan parameters 



Table 1. Required Sysdig scan parameters

 Parameter name Description 

 sysdig-scan Set this parameter to an enum value 0 or 1. If the value is set to 1, the sysdig scan is called. 
 sysdig-api-token Set this parameter to a secret value that needs to be set to the Sysdig API token. The token is visible from the Sysdig instance's User Profile page. 







 Optional Sysdig scan parameters 



Table 2. Optional Sysdig scan parameters

 Parameter name Default value Description 

 sysdig-url https://secure.sysdig.com (property is not set) The URL of the Sysdig instance to be used for the scan. This value needs to be provided if any other Sysdig instance is being used. 
 sysdig-inline-scanner-image quay.io/sysdig/secure-inline-scan:2 (property is not set) Enter the Sysdig inline scanner image to be used for the scan.
* Image tags: 1.21.0 110-9, 1.22.0 110-9, 1.23.0 110-9, 1.24.0 110-9, 1.25.0 110-9
* Resolves issues while reading secrets.







 Change log for patch update 1.1.0_1060, released 26 April 2023 



* Image tags: 1.19.1 110-8, 1.20.0 110-8, 1.21.0 110-8, 1.22.0 110-8, 1.23.0 110-8.
* Updates golang version to 1.19.8.
* Adds support for Satellite cluster versions 4.11 and 4.12.







 Change log for patch update 1.1.0_978, released 16 March 2023 



* Image tags: 1.19.1 110-6, 1.20.0 110-6, 1.21.0 110-6, 1.22.0 110-6, 1.23.0 110-6.
* Updates golang version to 1.19.6.







 Change log for patch update 1.1.0_897, released 9 January 2023 



* Image tags: 1.19.1 110-5, 1.20.0 110-5, 1.21.0 110-5, 1.22.0 110-5, 1.23.0 110-5.
* 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)
You can implement trust in your cluster in various ways, as shown in the following diagram.

Zoom

![Deploying containers with trusted content.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/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.
If vulnerabilities are found, instructions are provided to help fix the reported vulnerabilities.

To demonstrate these features, you must push an intentionally vulnerable image.

Images are continually updated and new CVEs are discovered. As a result, you might see more vulnerabilities present in your image. If so, fix those vulnerabilities by using the information that is provided by Vulnerability Advisor.



 View the vulnerability report for your image 

When a vulnerability is found in one of your images, a [report](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_reviewing) is produced that gives you more information about the vulnerability and the steps to resolve the vulnerability.



1. Build and push a vulnerable image:



1. Build a vulnerable image by running the following command:

docker build -t us.icr.io/<my_namespace>/hello-world:2 -f Dockerfile-vulnerable .
2. Push the vulnerable image by running the following command:

docker push us.icr.io/<my_namespace>/hello-world:2



You can read the Dockerfile to better understand how this image was made vulnerable. In short, a Debian base image is used, and the apt package is rolled back to a version that is vulnerable to CVE-2019-3462.
2. List your images, and take note of the SECURITY STATUS column by running the following command:

ibmcloud cr images --va

This column conveys the number of issues present in your image. Because the number isn't zero, this image is vulnerable.
3. Run the ibmcloud cr vulnerability-assessment (alias ibmcloud cr va) command to get more information about the vulnerability:

ibmcloud cr va us.icr.io/<my_namespace>/hello-world:1

Among other things, this output includes the ID of the vulnerability (if applicable), the affected package, and the steps to resolve the issue.







 Enforce security in your cluster
Glossary of Caveonix terms 

This glossary provides some descriptions for terms that are associated with the Caveonix RiskForesight™ solution:



* NIST Special Publication 800-53 - A Risk Management Framework that address security control.
* Security Content Automation Protocol (SCAP) - A method for using specific standards to enable the automated vulnerability management, measurement, and policy compliance evaluation of systems deployed in an organization. Checklists standardize and enable automation of the linkage between computer security configurations and the NIST Special Publication 800-53 controls framework.



* The National Vulnerability Database (NVD) is the US government content repository for SCAP.
* SCAP allows security administrators to scan computers, software, and other devices based on a predetermined security baseline. The scans determine whether the configuration and software patches are implemented to the standard that they are being compared to.





Review the following SCAP components:



* Common Vulnerabilities and Exposures (CVE) - A list of publicly known cybersecurity vulnerabilities.
* Common Configuration Enumeration (CCE) – A list of security-related system configuration issues.
* Common Platform Enumeration (CPE) - A structured naming scheme for information technology systems, software, and packages.
* Common Weakness Enumeration (CWE) – A list of common software security weaknesses.
* Common Vulnerability Scoring System (CVSS) - Provides a way to capture the main characteristics of a vulnerability and produce a numerical score that reflects its severity.



* Extensible Configuration Checklist Description Format (XCCDF) - A specification language for writing security checklists, benchmarks, and related kinds of documents. An XCCDF document represents a structured collection of security configuration rules for some set of target systems.
* Open Vulnerability and Assessment Language (OVAL) – A language that is used to encode system details, and an assortment of content repositories. The language standardizes the three main steps of the assessment process:



* Representing configuration information of systems for testing.
* Analyzing the system (vulnerability, configuration, and patch state)
* Reporting the results of this assessment.
Container Registry and Vulnerability Advisor workflow tutorial 

Use this tutorial to find out about the basic functions of both IBM Cloud® Container Registry and Vulnerability Advisor.

These two services are pre-integrated and work together seamlessly in IBM Cloud, and their features provide a robust but straightforward workflow for users of containers. You can use these services to store your container images, ensure the security of your images and Kubernetes clusters, control the images that you can use to deploy to your clusters, and more.

Much of the information that is provided in this tutorial is available in greater detail in the "How To" sections of the documentation. This tutorial combines all those tasks into a workflow that helps you to use IBM Cloud Container Registry and Vulnerability Advisor. To learn more about each task, click the relevant link.



 Objectives 

The tutorial has the following objectives.



* Understand the core features of IBM Cloud Container Registry and Vulnerability Advisor.
* Use the functions of these services to create a workflow.







 Services used 

This tutorial uses the following IBM Cloud services:



* [IBM Cloud Container Registry](https://cloud.ibm.com/registry/repos)
* [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/about)







 Before you begin 

Before you begin, complete the following tasks:



* [Install Git](https://git-scm.com/).
* [Install IBM Cloud Developer Tools](https://github.com/IBM-Cloud/ibm-cloud-developer-tools), a script to install docker, kubectl, helm, ibmcloud CLI, and required plug-ins by following the instructions in the README.md file in the repository.
* [Create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters).
* Ensure that you have the correct access permissions for adding and removing

namespaces, see [Access roles for configuring IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_configure).
Those pushes were automated with open toolchains and IBM Cloud® Continuous Delivery. Updates to the SaaS system no longer languished in slow, error-prone build processes. The Developers can deliver incremental updates to their users, daily or even more frequently. Also, logging and monitoring for the SaaS systems, especially how the patient front-end and back-end reports interact, rapidly integrate into the system. Developers don’t waste time building complex logging systems, just to be able to troubleshoot live systems.

Security first: With bare metal for IBM Cloud Kubernetes Service, the sensitive patient workloads now have familiar isolation but within the flexibility of public cloud. From that core, Vulnerability Advisor provides scanning:



* Image vulnerability scanning
* Policy scanning based on ISO 27k



Secure patient data leads to happier patients.



 Context 



* Technical debt, which is coupled with long release cycles, is hindering the provider’s business-critical patient management and reporting systems.
* Their back-office and front-office custom apps are delivered on-premises in monolithic virtual machine images.
* They need to overhaul their processes, methods, and tools but don’t know quite where to start.
* Their technical debt is growing, not shrinking, from an inability to release quality software to keep up with market demands.
* Security is a primary concern, and this issue is adding to the delivery burden, which causes even more delays.
* Capital expense budgets are under tight control, and IT feels they don't have the budget or staff to create the needed testing and staging landscapes with their in-house systems.







 Solution 

Compute, storage, and I/O services run in the public cloud with secure access to on-premises enterprise assets. Implement a CI/CD process and other parts of the IBM Garage Method to dramatically shorten delivery cycles.



 Step 1: Secure the compute platform 



* From that core, Vulnerability Advisor provides image, policy, container, and packaging scanning vulnerability scanning.
* Consistently enforce policy-driven authentication to your services and APIs with a simple Ingress annotation. With declarative security you can ensure user authentication and token validation by using App ID.







 Step 2: Lift and shift
Getting the severity for a vulnerability from IBM X-Force 

The DevSecOps pipeline uses the Vulnerability Advisor (VA) to identify vulnerabilities (CVEs) within Docker images. Because the VA does not supply a severity rating for the detected vulnerabilities, the pipeline assigns a HIGH rating to all CVEs that are found.

To get accurate severity ratings for vulnerabilities, pipelines can use IBM X-Force. To activate this feature, you need to get an IBM X-Force account and credentials. For more information, see [IBM X-Force Exchange API](https://api.xforce.ibmcloud.com/doc/)

When you have the necessary credentials, add the following environment variables to your CI and CC pipelines to receive vulnerability ratings.



Table 1. Vulnernability environment variables

 Name               Type    Description                                                                                                                   

 xforce-url         TEXT    The API URL for IBM X-Force, used to get vulnerability ratings. Example: https://api.xforce.ibmcloud.com/vulnerabilities/     
 xforce-api-key     TEXT    X-Force API key.                                                                                                              
 xforce-password    SECRET  X-Force Password.                                                                                                             





  Related links 



*  [IBM X-Force Exchange API](https://api.xforce.ibmcloud.com/doc/)
*  [X-Force usage charges tiers and price plan](https://exchange.xforce.ibmcloud.com/faqtiers_of_usage)
*  [Post Vulnerabilities](https://api.xforce.ibmcloud.com/doc//Vulnerabilities/post_vulnerabilities)
All IBM Maximo Application Suite SaaS customers use HTTPS (SSL) encryption (256 bit) at the browser level to access IBM hosted applications. Connections are SHA-2 and TLS v1.2 compatible

IBM obtains and implements externally facing SSL certificates from a trusted Certificate Authority (CA)

All databases use native AES-256 encryption (data is encrypted at rest)

Customers will not have direct access to the operating system, file system or web application server. Changes need to be requested through a Support ticket.

Customers will not have DBAdmin or update access to any database. Updates need to be requested through a support ticket.





 Single Sign On 

IBM Maximo Application Suite SaaS supports Single Sign On (SSO). Details can be found here:

[https://www.ibm.com/docs/en/mas-cd/continuous-delivery?topic=configuring-users-identity](https://www.ibm.com/docs/en/mas-cd/continuous-delivery?topic=configuring-users-identity)

LDAP and SAML (2.0) is supported.

IBM does not certify any specific tool a client has implemented within their environment. If the tool supports SAML 2.0 then it will work within the MAS-SaaS environment.

Customers will be responsible to ensure the appropriate user setup and mapping is correct and configured.





 Penetration and Vulnerability Testing 

IBM’s Product Transformation Center (PTC) conducts penetration testing on IBM Maximo Application Suite SaaS offering annually.

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.
Code Risk Analyzer scans 

Code Risk Analyzer (CRA) analyzes your code for vulnerabilities and compliance with certain rules.

Code Risk Analyzer is available in all IBM Cloud regions where toolchains are supported. For more information, see [Code Risk Analyzer plug-in for IBM Cloud](https://cloud.ibm.com/docs/code-risk-analyzer-cli-plugin?topic=code-risk-analyzer-cli-plugin-cra-cli-plugin).

CRA scans perform the following tasks:



1. Generates a Bill of Materials (BOM) file that lists the dependencies and available license information of all third-party OS packages and application packages. You can also generate this output in CycloneDX-specific format.
2. Discovers vulnerabilities in packages that are listed in the BOM file. You can also view the generated report in CycloneDX-specific format, or use vulnerability auto-remediation for Node.js, Maven, or Gradle applications.
3. Analyzes Kubernetes files for compliance with certain rules.
4. Analyzes Terraform plans for compliance with certain rules.





 Configuring CRA scans 

No specific pipeline environment variables are needed to generate the Bill of Materials and to discover vulnerabilities.

For generating the BOM file, the CRA scan command accesses artifacts in the specified directory path and performs deep discovery to identify all of the dependencies, including transitive dependencies. If the path contains Dockerfiles, it pulls down base images and build images for every build stage in each Dockerfile.

If your Dockerfile requires ARGS, set an individual ARG as an environment variable in a custom script and provide the location of the custom script as the pipeline environment variable.



Table 1. Docker script environment variables

 Pipeline environment variables Description Required or optional Purpose 

 cra-custom-script-path Path to the script in your repo. Optional Sets environment variables that are needed by the Docker script. 



Analyzing Terraform files is turned off by default. You can turn on Terraform analysis by using the following pipeline environment variables.
--restrict RESTRICTION
: (Optional) Limit the output to display only images in the specified namespace or repository.

--include-ibm
: (Optional) Includes IBM-provided public images in the output. By default only private images are listed. You can view IBM-provided images in the global registry only.

--no-va
: (Optional) Excludes the security status (Vulnerability Advisor) results from the output. If you don't need the security status results as part of your ibmcloud cr image-digests output, you can use this option to increase performance.

--va
: (Optional) Includes the Vulnerability Advisor security status results in the output. Use this option to ensure that you are ready for [IBM Cloud Container Registry CLI plug-in version 1.0.0](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_lists). You can use the --va option with the --restrict option to receive just the information that you require.





 Example 

Display all the images in the birds namespace, including untagged images, in the format repository@digest.

ibmcloud cr image-digests --restrict birds --quiet







 ibmcloud cr image-inspect 

Displays details about a specific image. You can reference the image that you want to inspect either by [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest), repository@digest, or by [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag),repository:tag.

ibmcloud cr image-inspect [--format FORMAT] IMAGE [IMAGE...]



 Prerequisites 

To find out about the required permissions, see [Access roles for using Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_using).





 Command options 

--format FORMAT
: (Optional) Format the output elements by using a Go template.
Hyper Protect Secure Build 

By using Hyper Protect Secure Build, you can build a trusted container image within a secure enclave that is provided by IBM Cloud Hyper Protect Virtual Servers for VPC. The enclave is highly isolated, where developers can access the container only by using a specific API and the cloud administrator cannot access the contents of the container. Therefore, the image that is built can be highly trusted. Specifically, the build server cryptographically signs the image, and a manifest (which is a collection of materials that are used during the build, for audits). Since the enclave protects the signing keys within the enclave, the signatures can be used to verify whether the image and manifest are from the build server, and not elsewhere.



 Configuring and using Hyper Protect Secure Build in Hyper Protect Virtual Servers for VPC 

Ensure that you use the latest Secure Build CLI code from [here](https://github.com/ibm-hyper-protect/secure-build-cli).



1. Complete the following steps to set up the Secure Build Server (SBS) client environment:



1. Follow these [instructions](https://github.com/ibm-hyper-protect/secure-build-cli/blob/master/SBS-VPC.mdinstall-the-secure-build-cli) to install the Secure Build CLI.
2. Follow these [instructions](https://github.com/ibm-hyper-protect/secure-build-cli/blob/master/SBS-VPC.mdpreparing-the-configuration) to prepare the sbs-config.json configuration file.



2. Complete the following steps to create the user-data.yamlfile that is used as the contract.



1. Copy the following workload section of the contract that is generated via an automated process, into the user-data.yamlfile. This workload section contains the encrypted details of the SBS image. Use the following workload section of the contract for the IBM Hyper Protect Container Runtime image version ibm-hyper-protect-container-runtime-1-0-s390x-9.