vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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 

Despite the vulnerability that is present in your image, you are still able to deploy a container to your cluster by using this image, which you might not want. By using [Portieris](https://cloud.ibm.com/docs/Registry?topic=Registry-security_enforce_portieris), you can enforce security in several ways. For example, you can prevent vulnerable images from being used in deployments to your cluster.



1. [Install Portieris](https://cloud.ibm.com/docs/Registry?topic=Registry-security_enforce_portierissec_enforce_install_portieris).
2. The [Portieris default policies](https://cloud.ibm.com/docs/Registry?topic=Registry-security_enforce_portierispolicies_portieris) are too restrictive for this tutorial because they involve [image signing](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontent). Therefore, you must create custom policies. View the security.yaml file in the [GitHub repository](https://github.com/IBM/registry-va-workflow), and read about customizing [policies](https://cloud.ibm.com/docs/Registry?topic=Registry-security_enforce_portierispolicies_portieris) to understand this file's contents. In short, this policy requires all images in your namespace to have no issues reported by Vulnerability Advisor.
3. Update the following line in the security.yaml file by replacing <my_namespace> with your namespace:
--format FORMAT
: (Optional) Format the output elements by using a Go template. For more information, see [Formatting and filtering the Container Registry CLI output](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_cli_list).

--quiet, -q
: (Optional) Each image is listed in the format: repository:tag

--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-trunc
: (Optional) Returns the image digest in its long format.

--show-type
: (Optional) Displays the image manifest type.

--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-list 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 the images in the birds namespace in the format repository:tag, without truncating the image digests.

ibmcloud cr image-list --restrict birds --quiet --no-trunc







 ibmcloud cr image-prune-untagged 

Delete all [untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_untagged) images in your IBM Cloud Container Registry account.
Using DevSecOps to build a secure software supply chain 

With the

DevSecOpstools and services available through IBM Cloud®, you can take advantage of using a verified secure software supply chain for developing and deploying your application code. Your agile development practices require rapid application deployment, but at the same time, you need to ensure that your applications are secure. Learn more about the background of [agile, DevOps, and DevSecOps](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops_introdevsecops-background).

You can use the [DevSecOps Application Lifecycle Management](https://cloud.ibm.com/docs/devsecops-alm?topic=devsecops-alm-devsecops-alm-overview) deployable architecture, which is a solution available from the IBM Cloud catalog that uses Continuous Delivery and others tools to help you automate the integration of security at every phase of the application software development lifecycle, from development through integration, testing, deployment, and software delivery. Evidence is also collected so that you can easily demonstrate to auditors that necessary controls are being met. By using DevSecOps Application Lifecycle Management, you can implement a shift-left approach by preventing new vulnerabilities from reaching production, ensuring frequent updates to production with quality and control, and collecting evidence for handling security audits.

DevSecOps Application Lifecycle Management uses Continuous Delivery (Git Repos and Issue Tracking, Tekton Pipelines, DevOps Insights, and Code Risk Analyzer), Secrets Manager, Key Protect, Object Storage, Container Registry, and Vulnerability Advisor. Aligned with the requirements of the Financial Services industry, Continuous Delivery provides a reference implementation of [NIST Configuration Management](https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search!/controls?version=5.1&family=CM) controls as a service.

Out of the box, DevSecOps with Continuous Delivery also uses scanning tools such as SonarQube, Gosec, OWASP Zap (dynamic scan), any unit test framework, and GPG signing.
DevSecOps with Continuous Delivery 

[DevSecOps](https://www.ibm.com/cloud/learn/devsecops) is an evolution of Agile and DevOps, integrating secure development best practices as early as possible in the software delivery lifecycle (also known as "shift left"). This approach prevents security problems from reaching production systems and failing corporate audits.

DevSecOpsrequires automating security and compliance controls as part of continuous integration and continuous delivery processes. Evidence of these controls is also collected to demonstrate to auditors that every change in history meets the necessary controls.

Aligned with the requirements of the Financial Services industry, Continuous Delivery provides a reference implementation of [NIST Configuration Management](https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search!/controls?version=5.1&family=CM) controls as a service. You can configure this service in a few clicks by using templates.

DevSecOps uses Continuous Delivery (Git Repos and Issue Tracking, Tekton Pipelines, DevOps Insights, and Code Risk Analyzer), Secrets Manager, Key Protect, Cloud Object Storage, Container Registry and Vulnerability Advisor. Out of the box, DevSecOps also leverages popular scanning tools such as SonarQube, Gosec, OWASP Zap (dynamic scan), any unit test framework, and GPG signing. It can also be used with more tools such as external Git providers and artifact stores. DevSecOps supports hybrid deployments, in particular by using private pipeline workers, and can be interfaced with other deployment tools such as Satellite Config and ArgoCD.



 Background 

Agile and DevOps provide for automation and greater development velocity, software quality, and consistency and reliability in the delivery processes while they remove the potential for human error. DevSecOps integrates a set of security and compliance controls into the DevOps processes. This feature allows organizations to deliver rapidly and often while they maintain a strong security posture and continuous state of audit-readiness.

Like Agile and DevOps, DevSecOps introduces a culture change and removes the traditional barriers between Developers, Operations, and Security and Compliance officers.
Teams have a timeline to fix the issue, but new features or fixes can still be deployed.

Zoom

![Vulnerability found in the build that is also in production](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/vuln-uc-2.svg)

Figure 3. Vulnerability found in the build that is also in production





 Use case 2A: vulnerability that is found in production allows PRs 

The vulnerability in production does not prevent PRs from merging.

Zoom

![Vulnerability found in production allows PRs](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/vuln-uc-2a.svg)

Figure 4. Vulnerability found in production allows PRs





 Use case 3: false positives and PCEs 

If the team categorizes an issue as false positive, or the team gets a PCE for a vulnerability, the issue can be labeled as Exempted. The issue can then be handled as a nonblocking issue. To maintain an audit trail, change requests keep the issues visible.

Zoom

![False positives and PCEs](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/vuln-uc-3.svg)

Figure 5. False positives and PCEs





 Use case 4: automatically closing fixed issues 

Periodically running the CC pipeline can close issues that are open and have a due date set. Also, the relevant vulnerability cannot be found in scans.

Zoom

!
* New configuration panel allowing you to include or exclude a set of labels for a cluster or namespace.
* Adding the ability to label IPs not mapped to Kubernetes or OpenShift entities.
* Adding the ability to to configure internal subnets for clusters.
* Adding additional information when hovering over a network connection or network node.
* Adding unresolved IP filtering.
* Adding Network as an item in the navigation.







 1 June 2021 

PromQL library
: A library of PromQL queries now available.

Prometheus remote write
: Prometheus remote write support is now supported for ingesting metrics.

Improved dashboard templates
: Dashboard templates have been improved for better data display and improved results.





 27 May 2021 

Secure beta support for Falco policy tuner
: A managed version of the Falco policy tuner is new available.





 19 May 2021 

Secure compliance support
: New compliance features for ISO27001:2013 and HIPAA are available.

Secure support for Inline Scanner
: V2.4.1 is supported.





 18 May 2021 

Secure updates for new and improved host OS and container scanning tools
: Functional updates include:



* The ability to scan hosts in addition to container images.
* Host benchmarks have been updated with additional checks and cluster aggregation.
* Image scanning is updated to automatically scan images if they have not been scanned.







 10 May 2021 

Silencing alert notifications
: You can silence alert notifications for a given scope or period of time.

New Kubernetes labels
: The following labels have been added that can be used to scope dashboards and configure groups.



* kubernetes.workload.name
* kubernetes.workload.type



New Kubernetes dashboards
: A number of new Kubernetes dashboards are available in beta.





 29 April 2021 

Secure updates to scan results page
: The layout of the scan results page has been reorganize to clearly distinguish policy evaluation from vulnerability matching and better summarize the information.





 26 April 2021 

Extended label set
[IAM access policies are required from 5 July 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policyregistry_notices_iam_policy)



* [What are the changes?](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policynotices_iam_policy_change)
* [Check whether these changes affect you](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policynotices_iam_policy_affect)
* [Prepare for the changes](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policynotices_iam_policy_prepare)
* [What if I did not implement the changes in time?](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policynotices_iam_policy_unprepared)



[Minimum supported Docker version from 1 March 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_dockerregistry_notices_docker)





 Release notes 

[Release notes](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry_release_notes)



* [19 June 2023](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-19jun2023)



* [Vulnerability Advisor version 3 is deprecated from 19 June 2023](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-19jun2023_v3)



* [19 May 2023](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-19may2023)
If the configuration contains a profile that does not check the DevSecOps toolchain goals, it might incorrectly indicate the toolchain status as passed even though some of the DevSecOps scans failed. This parameter is relevant only when the trigger_scan parameter is enabled. 
 scope optional, updatable, deprecated String scope Deprecated. The name of a Security and Compliance Center scope that was previously created in that service. When the trigger_scan parameter is set to enabled, the Validation scan scans all of the resources in that scope. Select a scope that contains this toolchain so that the scan finds the evidence that was recently updated by the DevSecOps pipeline-run. This parameter is relevant only when the trigger_scan parameter is enabled. 
 trigger_scan optional, updatable, deprecated String trigger_scan Deprecated. Set to enabled to indicate that a DevSecOps pipeline task must trigger a Security and Compliance Center run of a hybrid cloud validation scan. Each scan might incur charges. When enabled, the api_key, scope, and profile parameters are required to trigger that scan. 







 Learn more about Security and Compliance Center 

To learn more about Security and Compliance Center, see [Getting started with Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).
* [12 August 2020](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-12aug2020)



* [Using UAA tokens is discontinued](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes12aug2020_tokens)



* [30 July 2020](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-30jul2020)



* [New access roles are required for Vulnerability Advisor exemption policies](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes30jul2020_exemption)



* [29 July 2020](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-29jul2020)



* [You can set permissions so that access to resources within a namespace can be configured at the resource group level](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes29jul2020_resource_group)



* [13 July 2020](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-13jul2020)



* [To work with namespaces, you must have the Manager role at the account level](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes13jul2020_manager)



* [24 June 2020](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notesregistry-24jun2020)



* [Restoring all tags for a digest in a repository is now an option](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_release_notes24jun2020_tags)
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 



* Migrate virtual machine images to container images that run in IBM Cloud Kubernetes Service in the public cloud.
* Provide standardized DevOps dashboards and practices through Kubernetes.
* Enable scaling compute resources for batch and other back-office workloads that run infrequently.
* Use IBM® Secure Gateway for IBM Cloud® to maintain secure connections to on-premises DBMS.
* Private data center / on-premises capital costs are greatly reduced and replaced with a utility computing model that scales based on workload demand.







 Step 3: Microservices and Garage Method 



* Reconfigure apps into a set of cooperative microservices. That set runs within IBM Cloud Kubernetes Service that is based on functional areas of the app with the most quality problems.
* Use IBM Cloudant with customer provided keys for caching data in the cloud.
* Adopt continuous integration and delivery (CI/CD) practices so that Developers version and release a microservice on its own schedule as needed. IBM Cloud® Continuous Delivery provides for workflow toolchains for CI/CD process along with image creation and vulnerability scanning of container images.
* Adopt the agile and iterative development practices from the IBM Garage Method to enable frequent releases of new functions, patches, and fixes without downtime.



Technical solution



* IBM Cloud Kubernetes Service
* IBM Cloudant
* IBM® Secure Gateway for IBM Cloud®
* App ID



For sensitive workloads, the clusters can be hosted in IBM Cloud Kubernetes Service for Bare Metal. By using industry-standard containers technology, apps can initially be re-hosted on IBM Cloud Kubernetes Service quickly without major architectural changes. This change provides the immediate benefit of scalability.
CC pipeline uses the [pipelinectl save_artifact](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectlsave_artifact) interface to register artifacts found in the inventory entries, then iterates over these artifacts, by using the [list_artifacts](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectllist_artifacts) and [load_artifact](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectlload_artifact) commands.

To get started with this stage, provide your artifacts for the pipeline by using the [pipelinectl](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectl) interface. You are not required to update the build scripts and the .pipeline-config.yaml configuration.

To use a different scan process or to process artifacts other than Docker images in icr.io, you can customize these stages by using the .pipeline-config.yaml configuration in your project.





 Collecting compliance data on build 

The CC pipeline attempts to process the results from checks and scans, breaking down results to individual issues per every found CVE, vulnerability, or alert. The issues that are found by the CC pipeline are marked with a continuous-compliance-check label that identifies issues that are discovered on the prod environment.

The pipeline collects [evidence](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-evidence) on all checks and scans and stores them in the evidence locker. The evidence collector also saves the pipeline log files, the pipeline data itself, containing the Tekton definitions. The issues that are created according to scan and check that results are also attached to the evidence.
Enforcing container image security by using Portieris 

You can use [Portieris](https://github.com/IBM/portieris) to enforce image security policies in IBM Cloud® Container Registry.

Portieris is a Kubernetes admission controller that verifies your container images before you deploy them to your cluster in IBM Cloud Kubernetes Service.

You can use Portieris to enforce policies on image signatures. If an image doesn't meet your policy requirements, the resource that contains the pod is not deployed to your cluster.

Using Portieris to block the deployment of images with issues that are found by Vulnerability Advisor is deprecated.

If Portieris is deployed and the cluster workers are showing as working correctly, but nothing is scheduled, see [Why don't my pods restart after my workers were down?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-pods) for assistance.

Portieris is supported on Red Hat® OpenShift®.



 Installing Portieris in your cluster 

Install Portieris in your cluster.

To install Portieris in your IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud cluster, see [Enabling image security enforcement in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-imagesportieris-image-sec). If you use this installation, it is deployed and maintained for you and it runs in the control plane, which gives higher availability.

If you prefer to install Portieris directly, or you aren't using IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud, see [Installing Portieris](https://github.com/IBM/portierisinstalling-portieris).





 Portieris policies 

Portieris has two types of policy. Image policy resources and cluster image policy resources. You can override the default Portieris policies.

For more information about Portieris policies, see [Portieris policies](https://github.com/IBM/portieris/blob/main/POLICIES.md).
Pull request pipeline 

Pull request pipeline runs set compliance status checks on a pull request for the specified application repository.

Attempts to merge a pull request into the master branch might be blocked because of failed compliance status checks. Opening or updating a pull request against the master branch triggers the pull request pipeline to run. You can run your own setup for the pipelines and tests in [Custom scripts](https://cloud.ibm.com/docs/devsecops?topic=devsecops-custom-scripts).



 Stages and tasks 



Table 1. Pipeline order

 Task or stage Short description Customizable in .pipeline-config.yaml 

 start Set up the pipeline environment. No 
 setup Set up your build and test environment. Yes 
 unit-tests Run unit tests and app tests on app code. Yes 
 compliance-checks Run Code Risk Analyzer scans and other compliance checks on app repos. Yes 
 finish Consolidate the pipeline status. Yes 



For more information about how to customize stages by using the .pipeline-config.yaml file, see [Custom scripts](https://cloud.ibm.com/docs/devsecops?topic=devsecops-custom-scripts) and [Pipeline parameters](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-pipeline-parm).





 Scans and checks in compliance checks 



Table 2. Compliance scans and checks

 Scan or check Description 

 Detect secrets The [IBM Detect Secrets](https://github.com/IBM/detect-secrets) tool identifies where secrets are visible in app code. 
 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.