vania-janet/multiturn-rag-retrieval-data huggingface dataset:
vulnerabilityadvisor Vulnerability Advisor results from IBM Vulnerability Advisor on Cloud 



Test records must provide data in one of the following supported formats:



Table 2. Supported formats

 Test Type Supported Formats 

 Unit test Mocha, xUnit, Karma/Mocha 
 Functional verification test Mocha, xUnit, Karma/Mocha 
 Code coverage Cobertura, lcov, JaCoCo 
 SonarQube Scan data that is provided by SonarQube scans 
 Static AppScan Static App Scans that are provided by IBM Application Security on Cloud 
 Dynamic AppScan Dynamic App Scans that are provided by IBM Application Security on Cloud 
 Vulnerability Advisor Results Vulnerability Advisor results from IBM Vulnerability Advisor on Cloud 







 Viewing test results 

When your pipeline runs, it publishes the test result data to DevOps Insights. You can view the test result data on the Quality Dashboard page.



1. From the IBM Cloud console, click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg), and select Resource List.
2. Select your toolchain.
3. From your toolchain's Overview page, on the IBM Cloud tools card, click DevOps Insights.
4. Click Quality Dashboard in the navigation to open the page.



For more information about the Quality Dashboard page, see [DevOps data aggregation](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-devops-data-aggregation).





 Next steps 

[Evaluate gates](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-evaluate-gates-cli).
For more information about how to update to version 4, see [Update Vulnerability Advisor to version 4 by 19 June 2023](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_va_v4&interface=ui).

For version 4, the image is indexed the first time that it is pushed. Thereafter, the vulnerability assessment is calculated every time Vulnerability Advisor is queried about that image.

The following tables show the supported Docker base images that Vulnerability Advisor checks for vulnerable packages.

Vulnerability Advisor supports only releases of platforms that are currently supported by the vendor of that platform.



Table 1. Supported Docker base images that Vulnerability Advisor 3 checks for vulnerable packages

 Docker base image Supported versions Source of security notices 

 Alpine All stable versions with vendor security support. [Git - Alpine Linux](https://gitlab.alpinelinux.org/) and [CVE](https://cve.mitre.org/data/downloads/index.html). 
 CentOS Version 7 [CentOS announce archives](https://lists.centos.org/pipermail/centos-announce/) and [CentOS CR announce archives](https://lists.centos.org/pipermail/centos-cr-announce/). 
 Debian All stable versions with vendor security support or long-term support. [Debian security announcements](https://lists.debian.org/debian-security-announce/) and [Debian LTS Security Information](https://www.debian.org/lts/security/). 
 GoogleContainerTools distroless All stable versions with vendor security support. [GoogleContainerTools distroless](https://github.com/GoogleContainerTools/distroless) 
 Red Hat® Enterprise Linux® (RHEL) RHEL/UBI 7, RHEL/UBI 8, and RHEL/UBI 9 [Red Hat Security Data API](https://access.redhat.com/labsinfo/securitydataapi). 
 Ubuntu All stable versions with vendor security support.
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. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan.
* IBM Cloud Container Registry provides a multi-tenant, highly available, scalable, and encrypted private image registry that is hosted and managed by IBM.
* The IBM Cloud Container Registry includes Vulnerability Advisor features that scan for potential security issues and vulnerabilities. Vulnerability Advisor checks for vulnerable packages in specific Docker base images, and known vulnerabilities in app configuration settings. When vulnerabilities are found, information about the vulnerability is provided. You can use this information to resolve security issues so that containers are not deployed from vulnerable images.



To get details about the logging agent images, see [Getting information about logging agent images](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-log_analysis_agent_image).



 Resource Limits for agents deployed on Kubernetes 

The agent is deployed as a Kubernetes DaemonSet, creating one pod for each node selected. The agent collects logs of all the pods in the node. The resource requirements of the agent are in direct relation to the number of pods for each node and the amount of logs produced for each pod.

The agent requires at least 128 MB and no more than 512 MB of memory. It requires at least twenty millicpu (20m).

Different features can also increase resource utilization. When line exclusion, inclusion or redaction rules are specified, you can expect additional CPU consumption for each line and regex rule defined. When Kubernetes event logging is enabled (disabled by default), additional CPU usage will occur on the oldest agent pod.

Placing traffic shaping or CPU limits on the agent is not recommended to ensure data can be sent to the log ingestion service.





 Understanding image tags 

The tag that is associated to a logging image indicates whether the logging agent is automatically updated.

A tag consists of multiple parts:

X.Y.Z-<date>.[hash]

Where



* X represents the major version of an image.
* Y represents the minor version of an image.
* Z represents an incremental ID that determines the latest patched minor version.
* <date> represents the date that the image is built and available. The format is YYYYMMDD.
For more information about the versions of Vulnerability Advisor, see [About Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiabout).

Vulnerability Advisor version 3 is deprecated from 19 June 2023. For more information about how to update to version 4, see [Update Vulnerability Advisor to version 4 by 19 June 2023](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_va_v4&interface=ui).

ibmcloud cr vulnerability-assessment [--extended | -e] [--vulnerabilities | -v] [--configuration-issues | -c] [--output FORMAT | -o 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 

IMAGE
: The name of the image for which you want to get a report. The report states whether the image has any known package vulnerabilities. You can request reports for multiple images at the same time by listing each image in the command with a space between each name.

To find the names of your images, run ibmcloud cr image-list. 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 report assesses the image that is tagged latest.

For information about supported Docker base images, see [Vulnerable packages](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uipackages).

For more information, see [Managing image security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=ui).

--extended, -e
: (Optional) The command output shows additional information about fixes for vulnerable packages.
Starting from version 1.0.0 of the Container Registry plug-in, you can choose whether to fetch results from either version 3, v3 (the default), or version 4, v4, of Vulnerability Advisor for the following commands:



* [ibmcloud cr va IMAGE](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_va), where IMAGE is the name of the image.
* [ibmcloud cr image-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list).
* [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_digests).



To retrieve results from version 4 instead of version 3, run the following [ibmcloud cr va-version-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_va_version_set) command.

ibmcloud cr va-version-set v4

Alternatively, you can set an environment variable, va_version, and specify the Vulnerability Advisor version that you want to use. Valid values are v3 and v4.





 Reviewing a vulnerability report 

Before you deploy an image, you can review its Vulnerability Advisor report for details about any vulnerable packages and nonsecure container or app settings.

You can also check whether the image is compliant with organizational policies.

If you don't address any discovered issues, those issues can impact the security of containers that are using that image. If you use enforcement in your container runtime environment, you might be prevented from deploying that image unless all issues are exempted by your policy.

If your image does not meet the requirements that are set by your organization's policy, you must configure the image to meet those requirements before you can deploy it. For more information about how to view and change the organization policy, see [Setting organizational exemption policies](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_managing_policy).
Starting from version 1.0.0 of the Container Registry plug-in, you can choose whether to fetch results from either version 3, v3 (the default), or version 4, v4, of Vulnerability Advisor for the following commands:



* [ibmcloud cr va IMAGE](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_va), where IMAGE is the name of the image.
* [ibmcloud cr image-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list).
* [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_digests).



To retrieve results from version 4 instead of version 3, run the following [ibmcloud cr va-version-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_va_version_set) command.

ibmcloud cr va-version-set v4

Alternatively, you can set an environment variable, va_version, and specify the Vulnerability Advisor version that you want to use. Valid values are v3 and v4.





 Reviewing a vulnerability report 

Before you deploy an image, you can review its Vulnerability Advisor report for details about any vulnerable packages and nonsecure container or app settings.

You can also check whether the image is compliant with organizational policies.

If you don't address any discovered issues, those issues can impact the security of containers that are using that image. If you use enforcement in your container runtime environment, you might be prevented from deploying that image unless all issues are exempted by your policy.

If your image does not meet the requirements that are set by your organization's policy, you must configure the image to meet those requirements before you can deploy it. For more information about how to view and change the organization policy, see [Setting organizational exemption policies](https://cloud.ibm.com/docs/Registry?topic=Registry-va_indexva_managing_policy).
For more information, see [Vulnerability Advisor for IBM Cloud Container Registry](https://cloud.ibm.com/apidocs/container-registry/va).





 31 May 2018 

Use Helm for Passport Advantage images
: Import IBM software that is downloaded from [IBM Passport Advantage Online for customers](https://www.ibm.com/software/passportadvantage/pao_customer.html) and packaged for use with Helm into your Container Registry namespace.





 21 March 2018 

Container Scanner
: Container Scanner enables Vulnerability Advisor to report any problems that are found in running containers that are not present in the container's base image.





 16 March 2018 

Container Image Security Enforcement beta
: Use Container Image Security Enforcement beta to verify your container images before you deploy them to your cluster in IBM Cloud Kubernetes Service. You can control where images are deployed from, enforce Vulnerability Advisor policies, and ensure that [content trust](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontent) is properly applied to the image.





 20 February 2018 

Trusted content
: Container Registry provides trusted content technology so that you can sign images to ensure the integrity of images in your registry namespace. By pulling and pushing signed images, you can verify that your images were pushed by the correct party, such as your continuous integration (CI) tools.

For more information, see [Signing images for trusted content](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent).





 6 November 2017 

Global registry
: A global registry is available. The global registry domain name doesn't include a region (icr.io). Only public images that are provided by IBM are hosted in this registry.

For more information, see [Global registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions_global).





 29 September 2017 

Build Docker images
: The ibmcloud cr build command is now available for running container builds.
To avoid that developers apply hot fixes to sensitive images, limit the number of people in your organization who have access to the build process.
2. Scan images before they deploy into production: Make sure to scan every image before you deploy a container from it. For example, if you use IBM Cloud Container Registry, all images are automatically scanned for vulnerabilities when you push the image to your namespace. If vulnerabilities are found, consider eliminating the vulnerabilities or block deployment for those images. Find a person or team in your organization who is responsible for monitoring and removing vulnerabilities. Depending on your organizational structure, this person might be part of a security, operations, or deployment team. Enable [content trust](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent) so that images must be approved by a trusted signer before they can be pushed to the container registry. Then, [install the open source Portieris project](https://github.com/IBM/portieris) admission controller to block container deployments from unsigned images.
3. Regularly scan running containers:. Even if you deployed a container from an image that passes the vulnerability check, the operating system or binaries that run in the container might get vulnerable over time. To protect your app, you must ensure that running containers are regularly scanned so that you can detect and remediate vulnerabilities. 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

!
Scanning software for vulnerabilities 

Before you install instances of software from the IBM Cloud® catalog, you might want to complete a vulnerability assessment on the contents of the software and its associated images. By doing so, you can reduce the probability of security threats and unauthorized access of systems.



1. Select the software from the catalog in the IBM Cloud console.
2. Copy the URL that's displayed in the Source URL section on the Create tab.
3. Generate an IAM access token. If you're working with OVA images, you can skip this step.

To generate an access token by using the IBM Cloud CLI, complete the following steps:



1. Log in to the CLI:



ibmcloud login

If you're logging in with a federated ID, run the ibmcloud login --sso command. For more information, see [Logging in with a federated ID](https://cloud.ibm.com/docs/account?topic=account-federated_id&interface=cli).



2. Specify the region and resource group in which to create an instance of the software:



ibmcloud target -r <region_name> -g <resource_group_name>



3. Retrieve your access token:



ibmcloud iam oauth-tokens

The following truncated example shows a retrieved token.

IAM token: Bearer eyJraWQiOiIyM...

To generate an access token by using an API, complete the following steps:



1. Log in to the IBM Cloud CLI:



ibmcloud login

If you're logging in with a federated ID, run the ibmcloud login --sso command. For more information, see [Logging in with a federated ID](https://cloud.ibm.com/docs/account?topic=account-federated_id&interface=cli).



2. Specify the region and resource group in which to create an instance of the software:



ibmcloud target -r <region_name> -g <resource_group_name>



3.
Code Risk Analyzer vulnerability scan Finds vulnerabilities for all of the app package dependencies, container base images, and operating system packages. Uses the Code Risk Analyzer tool. 
 Code Risk Analyzer CIS check Runs configuration checks on Kubernetes deployment manifests. Uses the Code Risk Analyzer tool. 
 Code Risk Analyzer Bill of Material (BOM) check The BOM for a specified repo that captures the pedigree of all of the dependencies. This BOM is collected at different granularities. For example, the BOM captures the list of base images that are used in the build, the list of packages from the base images, and the list of app packages that are installed over the base image. The BOM acts as a ground truth for the analytic results and can potentially be used to enforce policy gates. Uses the Code Risk Analyzer tool. 
 Mend Unified Agent vulnerability scan The [Mend Unified Agent scanning tool](https://docs.mend.io/bundle/unified_agent/page/overview_of_the_unified_agent.html) scans app repos' open source components for vulnerable libraries and source files. For more information, see [Configuring Mend Unified Agent scans](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-mend-scans). 



These scripts are run on all of the app repos that the pipeline is aware of. CC pipeline uses the [pipelinectl save_repo](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectlsave_repo) interface to register repos found in the inventory entries, then uses the [list_repos](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectllist_repos) and [load_repo](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectlload_repo) commands to iterate over repos and send them to scanners.
For example, you might pull an image from any private or public registry source, and then tag it for later use in IBM Cloud Container Registry. Or, you might push a Docker image that you work with to your namespace so that other users can access the image. To get started, see [Adding images to your namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_).





 Managing security of images in IBM Cloud Container Registry with Vulnerability Advisor 

Vulnerability Advisor checks the security status of container images that are provided by IBM, third parties, or added to your organization's IBM Cloud Container Registry namespace.

When you add an image to a namespace, the image is automatically scanned by Vulnerability Advisor to detect security issues and potential vulnerabilities. If security issues are found, instructions are provided to help fix the reported vulnerability. To get started, see [Managing image security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index).





 Setting up trusted content for container images 

You can build containers from trusted images that are signed and stored in IBM Cloud Container Registry, and prevent deployments from unsigned or vulnerable images.



1. [Sign images for trusted content](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent). After you set up trust for your images, you can manage trusted content and signers that can push images to your registry.
2. To enforce a policy so that only signed images can be used to build containers in your cluster, [install the open source Portieris project](https://cloud.ibm.com/docs/containers?topic=containers-imagesportieris-image-sec).
3. Cluster users can deploy apps that are built from trusted images.



1. [Deploy to the default Kubernetes namespace](https://cloud.ibm.com/docs/containers?topic=containers-imagesnamespace).
2.