release: release notes for v0.13.0

Lots of nice updates in this release.

Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>

.lycheeignore

@@ -1 +1,2 @@
 https://sigs.centos.org/virt/tdx/
+https://www.intel.com/

ADOPTERS.md

@@ -15,6 +15,9 @@ See list of adopter types at the bottom of this page.
 |NanhuLab|Trusted Big Data Sharing System |Beta |Service Provider |The system uses confidential containers to ensure that data users can utilize the data without being able to view the raw data.(No official website yet. For details: yzc@nanhulab.ac.cn) |
 | [KubeArmor](https://www.kubearmor.io/) | Runtime Security | Beta | Another project | An open source project that leverages CoCo as part of their solution, integrates with for compatibility and interoperability, or is used in the supply chain of another project [(5GSEC)](https://github.com/5GSEC/nimbus/blob/main/examples/clusterscoped/coco-workload-si-sib.yaml). |
 | [Red Hat](https://www.redhat.com/en) | [OpenShift confidential containers](https://www.redhat.com/en/blog/learn-about-confidential-containers) | Beta | Service Provider | Confidential Containers are available from [OpenShift sandboxed containers release version 1.7.0](https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.7/) as a tech preview on Azure cloud for both Intel TDX and AMD SEV-SNP. The tech preview also includes support for confidential containers on IBM Z and LinuxONE using Secure Execution for Linux (IBM SEL).|
+| [ByteDance](https://www.bytedance.com/) | Jeddak Sandbox | Beta | End-User / Service Provider | Jeddak Sandbox leverages CoCo to protect the data privacy in the process of the company's business  (for details chendian.imtyrant@bytedance.com) |
+| [Intel](https://www.intel.com/) | [Enterprise-RAG](https://github.com/opea-project/Enterprise-RAG/blob/main/docs/tdx.md)<br>[OPEA](https://github.com/opea-project/GenAIInfra/tree/main/helm-charts/TDX.md) | Beta | End-User / Service Provider | Intel runs confidential container deployments on Kubernetes with Intel TDX |
+| [Switchboard](https://www.switchboard.xyz/) | [Decentralized Crypto Oracle](https://docs.switchboard.xyz/switchboard-protocol/running-a-switchboard-oracle) | Production | Service Provider | Running our Decentralized Oracles code in CoCo on AMD SEV SNP bare metal machines |
 |TBD| | | | |
 |TBD| | | | |
 

README.md

@@ -2,7 +2,7 @@
 
 # Confidential Containers
 
-[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/5719/badge)](https://bestpractices.coreinfrastructure.org/projects/5719)
+[![CII Best Practices](https://bestpractices.dev/projects/5719/badge)](https://bestpractices.dev/projects/5719)
 
 ## Welcome to confidential-containers
 

overview.md

@@ -31,9 +31,8 @@ Cloud Computing adoption continues to accelerate whether it be Public, Private o
 common a Hybrid approach and with it the trust boundaries change. Consideration of insider threats
 needs to now consider the cloud provider, infrastructure provider, and managed service provider.
 
-Certain industries are heavily focused on compliance to standards. Governments, too, are concerned
-both [collectively](https://www.un.org/counterterrorism/cybersecurity) and
-[individually](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/).
+Certain industries are heavily focused on compliance to standards. Governments are also
+[interested](https://www.un.org/counterterrorism/cybersecurity).
 The standards expected to protect software solutions continue to evolve towards a concept of
 Confidential Computing.
 

releases/v0.10.0.md

@@ -74,7 +74,7 @@ The following are known limitations of this release:
 * Platform support is rapidly changing
 * SELinux is not supported on the host and must be set to permissive if in use.
 * Complete integration with Kubernetes is still in progress.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
 * The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which remained at 75% at the time of this release.

releases/v0.11.0.md

@@ -71,7 +71,7 @@ The following are known limitations of this release:
 * Platform support is rapidly changing
 * SELinux is not supported on the host and must be set to permissive if in use.
 * Complete integration with Kubernetes is still in progress.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
 * The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
 * Container metadata such as environment variables are not measured.

releases/v0.12.0.md

@@ -0,0 +1,94 @@
+# Release Notes for v0.12.0
+
+Release Date: January 24th, 2025
+
+This release is based on [3.13.0](https://github.com/kata-containers/kata-containers/releases/tag/3.13.0) of Kata Containers
+and [v0.11.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.11.0) of enclave-cc.
+
+Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) for details on how to try out Confidential
+Containers.
+
+Note that there have been a few breaking changes in the configuration for Trustee.
+If you have been using a custom configuration based on a previous release,
+you may need to update it.
+
+Please refer to our [Acronyms](https://github.com/confidential-containers/documentation/wiki/Acronyms)
+and [Glossary](https://github.com/confidential-containers/documentation/wiki/Glossary) pages for
+definitions of the acronyms used in this document.
+
+## What's new
+
+* Trustee can produce EAR attestation tokens.
+* Plugin architecture added to Trustee including a PKCS11 plugin
+* Trustee can automatically pull VCEK from KDS when validating AMD SNP evidence.
+* Trustee ITA config allows users to select which policies are evaluated and will now always return a token by default.
+* Sealed secrets can be exposed as volumes more flexibly.
+* Confidential Containers documentation has moved to [website](https://confidentialcontainers.org).
+* The confidential guest kernel was updated to Linux 6.12 LTS adding efistub TDX RTMR measurements of the kernel command line and initrd.
+* For peer pods, fedora-based podvm images build with mkosi are now tested and published
+* CRI-O container runtime is tested for peer pods
+
+
+## Hardware Support
+
+Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SE.
+Not all feature have been tested on every platform, but those based on attestation
+are expected to work on the platforms above.
+
+Make sure your host platform is compatible with the hypervisor and guest kernel
+provisioned by coco.
+
+This release has been tested on the following stacks:
+
+### AMD SEV-SNP
+
+* Processor: AMD EPYC 7413
+* Kernel: [6.8.0-rc5-next-20240221-snp-host-cc2568386](https://github.com/confidential-containers/linux/tree/amd-snp-host-202402240000)
+* OS: Ubuntu 22.04.4 LTS
+* k8s: v1.30.1 (Kubeadm)
+* Kustomize: v4.5.4
+
+### Intel TDX
+
+* Kernel: [6.8.0-1004-intel](https://git.launchpad.net/~kobuk-team/ubuntu/+source/linux-intel/tree/?h=noble-main-next)
+* OS: Ubuntu 24.04 LTS
+* k8s: v1.30.2 (Kubeadm)
+* Kustomize: v5.0.4-0.20230601165947-6ce0bf390ce3
+
+### Secure Execution on IBM zSystems (s390x) running LinuxONE
+
+* Hardware: IBM Z16 LPAR
+* Kernel: 5.15.0-113-generic
+* OS: Ubuntu 22.04.1 LTS
+* k8s: v1.28.4 (Kubeadm)
+* Kustomize: v5.3.0
+
+## Limitations
+
+The following are limitations and known issues with this release.
+
+* SEV(-ES) does not support attestation.
+* Credentials for authenticated registries are exposed to the host.
+* Not all features are tested on all platforms.
+* Nydus snapshotter support is not mature.
+  * Nydus snapshotter sometimes fails to pull an image.
+  * Host pulling with Nydus snapshotter is not yet enabled.
+  * Nydus snapshotter is not supported with enclave-cc.
+* Image-rs fails to observe container whiteout files in some cases. [Issue](https://github.com/confidential-containers/guest-components/issues/876)
+* Pulling container images inside guest may have negative performance implications including greater resource usage and slower startup.
+* `crio` support is still evolving.
+* Platform support is rapidly changing
+* SELinux is not supported on the host and must be set to permissive if in use.
+* Complete integration with Kubernetes is still in progress.
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
+  * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
+* The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
+* Container metadata such as environment variables are not measured.
+* The Kata Agent allows the host to call several dangerous endpoints
+    * Kata Agent does not validate mount requests. A malicious host might be able to mount a shared filesystem into the PodVM.
+    * Policy can be used to block endpoints, but it is not yet tied to the hardware evidence.
+* Container logs may be visible to the host and blocking the logs agent endpoint can lead to container deadlocks. [Issue](https://github.com/kata-containers/kata-containers/issues/10680)
+
+## CVE Fixes
+
+None

releases/v0.13.0.md

@@ -0,0 +1,88 @@
+# Release Notes for v0.13.0
+
+Release Date: March 24th, 2025
+
+This release is based on [3.15.0](https://github.com/kata-containers/kata-containers/releases/tag/3.13.0) of Kata Containers
+and [v0.11.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.11.0) of enclave-cc.
+
+Kata and the CoCo components share an MSRV of 1.80.0.
+
+Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) or [project documentation](https://confidentialcontainers.org/docs) for more information.
+
+## What's new
+
+* AMD SEV(-ES) support has been deprecated and will be removed in the next release.
+* AMD SEV-SNP deployments are compatible with upstream (6.11+) host kernels.
+* Trustee uses ECDH keys by default for KBS protocol.
+* Reliabilty of image pulling has been improved (bug fixes below).
+* The repository field of the resource URI is no longer optional.
+* TDX Attestation uses configfs-tsm based reports only and disables the libtdx-attest fallback.
+* Trustee documentation added to project website.
+* Trustee attestation policy improved for TDX.
+* Blocking logs endpoint with policy can no longer cause deadlocks.
+
+## Bug Fixes
+* Fixed an issue where pulling images with many layers failed due to exceeding the 4KB length limit on mount parameters.
+* Fixed an issue where image whiteout files appeared in the unpacked container filesystem due to the guest's tmpfs not supporting xattr.
+* Fixed an issue where the RCAR handshake in the KBS protocol did not treat JWE protected header as AEAD.
+
+## Hardware Support
+
+Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SE.
+Not all features have been tested on every platform, but those based on attestation
+are expected to work on the platforms above.
+
+Make sure your host platform is compatible with the hypervisor and guest kernel
+provisioned by CoCo.
+
+This release has been tested on the following stacks:
+
+### AMD SEV-SNP
+
+* Processor: AMD EPYC 7413
+* Kernel: 6.12.0-snp-host-adc218676 (upstream 6.11+) 
+* OS: Ubuntu 22.04.4 LTS
+* k8s: v1.30.1 (Kubeadm)
+* Kustomize: v4.5.4
+
+### Intel TDX
+
+* Kernel: [6.8.0-1004-intel](https://git.launchpad.net/~kobuk-team/ubuntu/+source/linux-intel/tree/?h=noble-main-next)
+* OS: Ubuntu 24.04 LTS
+* k8s: v1.30.2 (Kubeadm)
+* Kustomize: v5.0.4-0.20230601165947-6ce0bf390ce3
+
+### Secure Execution on IBM zSystems (s390x) running LinuxONE
+
+* Hardware: IBM Z16 LPAR
+* Kernel: 5.15.0-113-generic
+* OS: Ubuntu 22.04.1 LTS
+* k8s: v1.28.4 (Kubeadm)
+* Kustomize: v5.3.0
+
+## Limitations
+
+The following are limitations and known issues with this release.
+
+* Credentials for authenticated registries are exposed to the host.
+* Not all features are tested on all platforms.
+* Nydus snapshotter support is not mature.
+  * Nydus snapshotter sometimes fails to pull an image.
+  * Host pulling with Nydus snapshotter is not yet enabled.
+  * Nydus snapshotter is not supported with enclave-cc.
+* Pulling container images inside guest may have negative performance implications including greater resource usage and slower startup.
+* `crio` support is still evolving.
+* Platform support is rapidly changing
+* SELinux is not supported on the host and must be set to permissive if in use.
+* Complete integration with Kubernetes is still in progress.
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
+  * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
+* The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
+* Container metadata such as environment variables are not measured.
+* The Kata Agent allows the host to call several dangerous endpoints
+    * Kata Agent does not validate mount requests. A malicious host might be able to mount a shared filesystem into the PodVM.
+    * Policy can be used to block endpoints, but it is not yet tied to the hardware evidence.
+
+## CVE Fixes
+
+None

releases/v0.2.0.md

@@ -60,11 +60,11 @@ The following are known limitations of this release:
   * `crio` is not supported
 - CoCo is not fully integrated with the orchestration ecosystem (Kubernetes, OpenShift)
   * OpenShift is a non-starter at the moment due to its dependency on [CRI-O](https://github.com/cri-o/cri-o)
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
   * Container image sharing is not possible in this release
   * Container images are downloaded by the guest (with encryption), not by the host
-  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/community/issues/66)
+  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/confidential-containers/issues/66)
 - The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which increased to 46% at the time of this release.
   * The main gaps are in test coverage, both general and security tests.

releases/v0.3.0.md

@@ -60,11 +60,11 @@ The following are known limitations of this release:
   * `crio` is not supported
 - CoCo is not fully integrated with the orchestration ecosystem (Kubernetes, OpenShift)
   * OpenShift is a non-starter at the moment due to its dependency on [CRI-O](https://github.com/cri-o/cri-o)
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
   * Container image sharing is not possible in this release
   * Container images are downloaded by the guest (with encryption), not by the host
-  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/community/issues/66)
+  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/confidential-containers/issues/66)
 - The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which increased to 49% at the time of this release.
   * The main gaps are in test coverage, both general and security tests.

releases/v0.4.0.md

@@ -58,11 +58,11 @@ The following are known limitations of this release:
   * `crio` is not supported
 - CoCo is not fully integrated with the orchestration ecosystem (Kubernetes, OpenShift)
   * OpenShift is a non-starter at the moment due to its dependency on [CRI-O](https://github.com/cri-o/cri-o)
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
   * Container image sharing is not possible in this release
   * Container images are downloaded by the guest (with encryption), not by the host
-  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/community/issues/66)
+  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/confidential-containers/issues/66)
 - The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which increased to 49% at the time of this release.
   * The main gaps are in test coverage, both general and security tests.

releases/v0.5.0.md

@@ -65,11 +65,11 @@ The following are known limitations of this release:
   * `crio` is not supported
 - CoCo is not fully integrated with the orchestration ecosystem (Kubernetes, OpenShift)
   * OpenShift support is not yet complete.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
   * Container image sharing is not possible in this release
   * Container images are downloaded by the guest (with encryption), not by the host
-  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/community/issues/66)
+  * As a result, the same image will be downloaded separately by every pod using it, not shared between pods on the same host. [More info](https://github.com/confidential-containers/confidential-containers/issues/66)
 - The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which increased from 49% to 64% at the time of this release.
   * All CoCo repos now have automated tests, including linting, incorporated into CI.

releases/v0.6.0.md

@@ -46,9 +46,9 @@ The following are known limitations of this release:
   * `crio` is only supported with `cloud-api-adaptor`.
 - Complete integration with Kubernetes is still in progress. 
   * OpenShift support is not yet complete.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
-  * Container images must be downloaded separately (inside guest) for each pod. [More info](https://github.com/confidential-containers/community/issues/66)
+  * Container images must be downloaded separately (inside guest) for each pod. [More info](https://github.com/confidential-containers/confidential-containers/issues/66)
 - The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which remained at 64% at the time of this release.
   * Vulnerability reporting mechanisms still need to be created. Public github issues are still appropriate for this release until private reporting is established.

releases/v0.7.0.md

@@ -46,9 +46,9 @@ The following are known limitations of this release:
   * `crio` is only supported with `cloud-api-adaptor`.
 - Complete integration with Kubernetes is still in progress. 
   * OpenShift support is not yet complete.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
-  * Container images must be downloaded separately (inside guest) for each pod. [More info](https://github.com/confidential-containers/community/issues/66)
+  * Container images must be downloaded separately (inside guest) for each pod. [More info](https://github.com/confidential-containers/confidential-containers/issues/66)
 - The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which remained at 64% at the time of this release.
   * Vulnerability reporting mechanisms still need to be created. Public github issues are still appropriate for this release until private reporting is established.

releases/v0.8.0.md

@@ -77,7 +77,7 @@ The following are known limitations of this release:
   * Not all image repositories support encrypted container images.
  Complete integration with Kubernetes is still in progress.
   * OpenShift support is not yet complete.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
 * The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which improved to 69% at the time of this release.

releases/v0.9.0-alpha0.md

@@ -65,7 +65,7 @@ The following are known limitations of this release:
   * Not all image repositories support encrypted container images.
 * Complete integration with Kubernetes is still in progress.
   * OpenShift support is not yet complete.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
 * The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which improved to 75% at the time of this release.

releases/v0.9.0-alpha1.md

@@ -52,7 +52,7 @@ The following are known limitations of this release:
 * SELinux is not supported on the host and must be set to permissive if in use.
 * Complete integration with Kubernetes is still in progress.
   * OpenShift support is not yet complete.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
 * The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which remained at 75% at the time of this release.

releases/v0.9.0.md

@@ -78,7 +78,7 @@ The following are known limitations of this release:
 * Platform support is rapidly changing
 * SELinux is not supported on the host and must be set to permissive if in use.
 * Complete integration with Kubernetes is still in progress.
-  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/community/issues/53)
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
   * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
 * The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
   * We track our status with the OpenSSF Best Practices Badge, which remained at 75% at the time of this release.

roadmap.md

@@ -23,5 +23,7 @@ We target the following use cases:
 - Trusted Pipeline (Supply Chain)
 - Confidential RAG LLMs
 
-A dedicated working group leads this effort. For additional details we recommend reviewing the working group's notes: [Confidential containers use cases driven development](https://docs.google.com/document/d/1LnGNeyUyPM61Iv4kBKFbfgmBr3RmxHYZ7Ev88obN0_E/edit?tab=t.0#heading=h.b0rnn2bw76n)
+These use cases are outlined within [Confidential Computing Use Case Slides](https://docs.google.com/presentation/d/1YSybvMRku1eoFjAmign9DzKGRpKW4REPYpJCNT0sxmc) created by a dedicated working group.
+
+For additional details we recommend reviewing the working group's notes: [Confidential containers use cases driven development](https://docs.google.com/document/d/1LnGNeyUyPM61Iv4kBKFbfgmBr3RmxHYZ7Ev88obN0_E/edit?tab=t.0#heading=h.b0rnn2bw76n)