From a4abd30387cb8a97e003eb262b04f2886df9d2bc Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Wed, 18 Feb 2026 23:44:07 +0800 Subject: [PATCH 1/9] add CoCo incubation DD report, including governance section assessments Signed-off-by: Kevin Wang --- .../confidential-containers-incubation-dd.md | 287 ++++++++++++++++++ 1 file changed, 287 insertions(+) create mode 100644 projects/confidential-containers/confidential-containers-incubation-dd.md diff --git a/projects/confidential-containers/confidential-containers-incubation-dd.md b/projects/confidential-containers/confidential-containers-incubation-dd.md new file mode 100644 index 000000000..696673983 --- /dev/null +++ b/projects/confidential-containers/confidential-containers-incubation-dd.md @@ -0,0 +1,287 @@ +# Confidential Containers Incubation Due Diligence + +- Link to [Incubation application issue](https://github.com/cncf/toc/issues/1504) + + + +## Incubation Evaluation Summary for Confidential Containers + +### Criteria Evaluation + +_$TOCMEMBER conducted the due diligence of Confidential Containers who applied for $LEVEL. The project [has/has not] completed the criteria that show its maturity at $LEVEL. The following criteria implementations are noteworthy to call out... $NOTABLES. The following actions were provided to the project that were considered blocking but since resolved... $BLOCKERS. The following recommendations were provided to the project that are non-blocking in the TOC's assessment but should be completed by the project to ensure continued viability of the project... $RECOMMENDATIONS._ + +### Adoption Evaluation + +_The adopter interviews reflect a project [in use/too early] for the level which the project applied. They show ... $INTERVIEWSUMMARY._ + +### Final Assessment + +_[The TOC has found the project to have satisfied the criteria for $LEVEL/ The TOC's evaluation of the project shows a needed focus to complete the outstanding blockers and reapply when the following conditions are met ... $CONDITIONS]._ + +## Application Process Principles + +### Suggested + +N/A + +### Required + +- [x] **Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.** + + + - This was completed and occurred on 28-Aug-2024, and can be discovered at + +- [x] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + + + The CoCo project uses vendor neutral resources for project host, communication etc. + Some examples are: + - CoCo Github: + - CoCo Project Website: + - CoCo Slack: + +- [x] **Review and acknowledgement of expectations for [Sandbox](https://sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.** + + + - The project contacts and TOC Reviewers had a kick-off meeting on Jan. 16th, set expectations and discussed general steps & timelines. + +- [ ] **Due Diligence Review.** + +Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria. + +- [ ] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** + + + The project provides approriate documents for installation and configuration, e.g.: + +## Governance and Maintainers + +Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject. + +### Suggested + +- [x] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.** + + + The CoCo project has been continuously updating governance doc, some examples are: + - Update governance doc to include rules of removing inactive maintainers + - Add provisions to the governance document for members who move from one company to another or who become inactive or leave the project. + + +- [x] **Clear and discoverable project governance documentation.** + + + The [project governance doc](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md) is maintained in the main repository. + + **Suggestion by Kevin:** Since CoCo has 10+ active non-fork repos, TOC reviewers suggest to consider creating a community repository and maintain governance and community relavent docs there. + +- [x] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** + + + The project maintains an active and up-to-date governance framework that accurately reflects the current project state. The documentation is regularly updated to capture Steering Committee leadership transitions, organizational representation changes, and refinements to maintainer lifecycle processes. + + Some examples are: + - removed AMD rep Ryan Savino from SC and added to emeritus + - Intel maintainers update + - Update Microsoft representative maintainer + +- [x] **Governance clearly documents [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** + + + As outlined in [GOVERNANCE.md](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md), the CoCo project effectively operationalizes vendor neutrality through structural mechanisms, specifically the two-seat limit per organization on the Steering Committee. + + **Suggestion by Kevin:** It is noted that the documentation currently lacks an explicit definition of 'vendor neutrality' as a core principle. The TOC reviewers recommend explicitly codifying a Vendor Neutrality clause to align with CNCF best practices before the project advances to graduation. + +- [x] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** + + + [GOVERNANCE.md#decision-making](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md#decision-making) explicitly documents a consensus-driven framework. It establishes a clear voting protocol for critical decisions, specifically leadership changes and governance modifications, requiring a defined supermajority threshold (2/3rds of current SC members) when consensus is not achieved. + +- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** + + + +- [ ] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** + + + +- [ ] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** + + + +- [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** + + + +### Required + +- [ ] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** + + + +- [ ] **A number of active maintainers which is appropriate to the size and scope of the project.** + + + +- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** + + + +- [ ] **Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.** + + + +- [ ] **CNCF Code of Conduct is cross-linked from other governance documents.** + + + +- [ ] **All subprojects, if any, are listed.** + + + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject. + +### Suggested + +- [ ] **Contributor ladder with multiple roles for contributors.** + + + +### Required + +- [ ] **Clearly defined and discoverable process to submit issues or changes.** + + + +- [ ] **Project must have, and document, at least one public communications channel for users and/or contributors.** + + + +- [ ] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** + + + +- [ ] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** + + + +- [ ] **Documentation of how to contribute, with increasing detail as the project matures.** + + + +- [ ] **Demonstrate contributor activity and recruitment.** + + + +## Engineering Principles + +### Suggested + +- [ ] **Roadmap change process is documented.** + + + +- [ ] **History of regular, quality releases.** + + + +### Required + +- [ ] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. _This requirement may also be satisfied by completing a General Technical Review._** + - _If applicable_ a general Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK. + + + +- [ ] **Document what the project does, and why it does it - including viable cloud native use cases.** + + + +- [ ] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** + + + +- [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. _This requirement may also be satisfied by completing a General Technical Review._** + - _If applicable_ a general Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK. + + + +- [ ] **Document the project's release process.** + + + +## Security + +### Suggested + +N/A + +### Required + +Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance. + +- [ ] **Clearly defined and discoverable process to report security issues.** + + + +- [ ] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** + + + +- [ ] **Document assignment of security response roles and how reports are handled.** + + + +- [ ] **Document Security Self-Assessment.** + + + +- [ ] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** + + + +## Ecosystem + +### Suggested + +N/A + +### Required + +- [ ] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** + + + +- [ ] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** + + + +The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. + +- [ ] **TOC verification of adopters.** + + + +Refer to the Adoption portion of this document. + +- [ ] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** + + + +#### Adoption + +##### Adopter 1 - $COMPANY/$INDUSTRY + +_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ +MONTH YEAR + +##### Adopter 2 - $COMPANY/$INDUSTRY + +_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ +MONTH YEAR + +##### Adopter 3 - $COMPANY/$INDUSTRY + +_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ +MONTH YEAR From b91bae73f37a9c464bb0a01797c25f3caa30d6d3 Mon Sep 17 00:00:00 2001 From: Faseela K Date: Mon, 23 Feb 2026 12:28:24 +0100 Subject: [PATCH 2/9] Revise security assessment documentation and links Signed-off-by: Kevin Wang --- .../confidential-containers-incubation-dd.md | 50 ++++++++++++++++--- 1 file changed, 42 insertions(+), 8 deletions(-) diff --git a/projects/confidential-containers/confidential-containers-incubation-dd.md b/projects/confidential-containers/confidential-containers-incubation-dd.md index 696673983..b0b1616da 100644 --- a/projects/confidential-containers/confidential-containers-incubation-dd.md +++ b/projects/confidential-containers/confidential-containers-incubation-dd.md @@ -221,25 +221,59 @@ N/A Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance. -- [ ] **Clearly defined and discoverable process to report security issues.** +- [x] **Clearly defined and discoverable process to report security issues.** - + + The project has a published security policy via the GitHub org-wide security policy: + - Security policy (`SECURITY.md`): + + The policy instructs reporters to use GitHub’s “Report a vulnerability” (private reporting) mechanism rather than filing public issues. - [ ] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** - + + **Maintainers’ input (from application):** The incubation application references a maintainers list as evidence that maintainers use 2FA: + - Maintainers list: + + **TOC reviewer assessment / gap (from confidential-containers/confidential-containers#349):** + - A maintainer list does **not** by itself provide auditable evidence that 2FA is **required and enforced** for GitHub org members/maintainers. + - Reviewers need a **clear, stable, public** reference describing: + - how access is granted/revoked, + - what controls prevent unauthorized changes (e.g., CODEOWNERS / required reviews / branch protection expectations), + - whether 2FA is required/enforced for privileged roles. + + **Action / follow-up requested:** Project to document the access control model and explicitly document 2FA requirements and/or org enforcement: + - - [ ] **Document assignment of security response roles and how reports are handled.** - + + **Maintainers’ input (from application):** + - The project points to the org-level `SECURITY.md` as the place describing handling of reports: + - -- [ ] **Document Security Self-Assessment.** + **TOC reviewer assessment / gap (from confidential-containers/confidential-containers#350):** + - While `SECURITY.md` describes the reporting mechanism, it historically referenced “maintainers and security champions” without a clearly defined, discoverable role model elsewhere (e.g., in governance/community docs). + - Reviewers need more explicit documentation of: + - who the security responders are (org-wide vs per subproject), + - how membership/ownership is determined and maintained (onboarding/offboarding/continuity), + - high-level responsibilities (triage/coordination/communication), without duplicating the mechanics already in `SECURITY.md`. + - Also recommended: cross-link security reporting guidance from contributing documentation (and other relevant guides), so users can easily find the security reporting process. - + **Action / follow-up requested:** + - -- [ ] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** +- [x] **Document Security Self-Assessment.** - + + The project has published a Security Self-Assessment: + - + +- [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** + + + The project holds an OpenSSF Best Practices passing badge: + - ## Ecosystem From b7eaf752b10fda1de80a75e5342234cc09b393c2 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 24 Feb 2026 11:46:04 -0500 Subject: [PATCH 3/9] Add NVIDIA, TDC-DK, and AccuKnox adopter interview notes on CoCo Signed-off-by: Kevin Wang --- .../AccuKnox-interview.md | 92 +++++++++++++++++++ .../NVIDIA-interview.md | 84 +++++++++++++++++ .../TDC-DK-interview.md | 77 ++++++++++++++++ 3 files changed, 253 insertions(+) create mode 100644 projects/confidential-containers/AccuKnox-interview.md create mode 100644 projects/confidential-containers/NVIDIA-interview.md create mode 100644 projects/confidential-containers/TDC-DK-interview.md diff --git a/projects/confidential-containers/AccuKnox-interview.md b/projects/confidential-containers/AccuKnox-interview.md new file mode 100644 index 000000000..d3b70d872 --- /dev/null +++ b/projects/confidential-containers/AccuKnox-interview.md @@ -0,0 +1,92 @@ +Interviewee: Rahul Jadhav(nyrahul@gmail.com) + +Interviewer: Lin Sun + +Company: AccuKnox + +Date: 10th Feb 2026 + +## Questions + +#### 1. How long has your organization used the project? + +AccuKnox worked on 5G security solution that provided Intent based security for 5G ORAN and 5G Core deployments. +Here is the [sample policy](https://github.com/5GSEC/nimbus/blob/main/examples/clusterscoped/coco-workload-si-sib.yaml) created +that used CoCo for ensuring that the workload is installed on hardware enabled security module. + +#### 2. What were the main motivations to adopt the project and which key features do you use today? + +5G UDR (Unified Data Repository) is a network function that stores sensitive data such as users' subscription keys and has to be +secured intricately. 5G deployments now readily deploy on public cloud providers and towards this end, the security threat model +is completely changed i.e., we have to assume that the CSP has root/admin access to the virtual machines. +AccuKnox depends on CoCo based deployments to secure such workloads. + +#### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project? + +CoCo is the only project that has the full TEE framework towards containerized deployments, including cloud APIs adapter that +make deployment even in cloud hosted env easy. + +#### 4. What is the current level of usage (pre-production, production) and scale? + +Pre-Production + +#### 5. What version of the project is currently in use and what is your update cadence with the project? + +We are still using v0.13.0 release of CoCo which is roughly an year old. We haven’t diligently updated the [code base](https://github.com/5GSEC/5g-blueprint-controls). + +#### 6. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + +We initially struggled to integrate with the AWS version of the CoCo. However, the [Cloud-api-adapter tooling](https://github.com/confidential-containers/cloud-api-adaptor) made it simpler. + +#### 7. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful? + +The docs were useful, however, we had to reach out to slack for help. Pradeepta and a few other folks helped out earnestly. + +#### 8. Did you need to engage with the community members or maintainers? If so, what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome? + +I presented the work we did in 5Gsec to the CoCo community and that's when they advised us to inform as part of adopters list. + +#### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc. + +Measurable value is improved security posture. There is no alternative to TEE/CoCo based execution for certain threat models +wherein if one cannot trust the cloud platform provider than the only hope left is to deploy using CoCo the sensitive workloads. + +#### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else? + +Even though we do not have any hard-bound dependencies after the 5Gsec project, I believe that a certain threat model cannot +be handled without the use of CoCo. + +#### 11. Is there something you feel that holds the project back from reaching its ultimate potential? + +The hardware availability and stability around the interfaces. The cost of hardware is still prohibitively high to be deployed in general scenarios. + +#### 12. In your opinion, what could the project improve? + +Messaging. The project needs to create awareness around the use-cases. People get bogged down with the gory technical details. + +#### 13. What are the overall strengths of the project? + +It handles a security threat model that cannot be handled otherwise without the use of hardware enabled security and the project +does wonders for enabling it in the containerized deployment. + +#### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +Yes, we want to make it formally as part of AccuKnox Enterprise offerings. The gov/federal depts use-cases are great to be handled using this project. + +--- +### Maturity Level Survey + + +#### 1. Do you feel you have a good understanding on the meaning of each maturity level for CNCF projects? + +I believe so (but not very strongly). I have been part of a similar journey for another CNCF project (KubeArmor) for which I am the maintainer. + +#### 2. Is there information missing regarding the meaning of each different level? + +I have read through the information regarding what is required for changing from sandbox to incubation maturity. +Similarly for graduation phase. + +#### 3. Do you rely on those levels internally in any way, and if yes how? + +Yes, within AccuKnox we want to use Graduated projects only as far as possible. We leverage sandbox or incubation projects only +if we have enough competency inhouse to handle the issues. diff --git a/projects/confidential-containers/NVIDIA-interview.md b/projects/confidential-containers/NVIDIA-interview.md new file mode 100644 index 000000000..e571c63ba --- /dev/null +++ b/projects/confidential-containers/NVIDIA-interview.md @@ -0,0 +1,84 @@ +Interviewer: Lin Sun + +Interviewee: Dan Middleton (dmiddleton@nvidia.com) + +Date: Jan 23, 2026 + +## Questions + +#### 1. How long has your organization used the project? + +Been involved with the project for 2 years. We are maintainers on the project, we are a vendor for the project, along with internal adopters of the project. +[Confidential computing](https://en.wikipedia.org/wiki/Confidential_computing) is a feature for CPUs and GPUs (carve out a protected memory space, such as creating a virtual machine so you don’t trust other tenants on the same host) , and confidential container (CoCo) is a project which helps end users activate Confidential Computing. + +#### 2. What were the main motivations to adopt the project and which key features do you use today? + +We have 3 motivations: +- Contributor: We want the NVIDIA GPU to be enabled for this project, so anyone who wants to use AI can use this security feature provided by the project. +- Vendor: We are building products that are on top of the CoCo ecosystem. For example, Redhat openshift is a downstream provider for CoCo. +- Adopter: NVIDIA operates a number of internal and external datacenters. Each has security requirements that benefit from Confidential Computing and we like the cloud-native approach provided by CoCo. + +#### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project? + +This is really the main project for cloud-native confidential computing. There are a few other projects but project momentum/feature/contributors drew us. Contributors from major cloud providers, hardware vendors, and independent software vendors. + +#### 4. What is the current level of usage (pre-production, production) and scale? + +Internally pre-production. Externally for other companies to adopt the NVIDIA version, early access version. GA is planned for later this year (end of Q1). + +#### 5. What version of the project is currently in use and what is your update cadence with the project? + +We are on the latest version, 0.18. We try to update pretty close to each formal release of the project. For teams using downstreams like Openshift, they update according to the downstream cadence. + +#### 6. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + +Because NVIDIA employs some maintainers on the project, it was pretty straightforward. Some challenges involve other CNCF components… making sure we have an agreed version of containerd for example. These integration points have been improved since. + +#### 7. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful? + +Good docs throughout the repo. In the last year, there is a single website that pulls docs from multiple places. + +#### 8. Did you need to engage with the community members or maintainers? If so, what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome? + +Open community mtg on thurs and we interact live with people there. We also regularly make github issues and the project slack. + +#### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc. + +Fundamental security improvement, faster integrations, reducing manual / custom integrations. Without CoCo there isn’t a consistent cloud-native activation for Confidential Computing. An alternative is running kubelet inside a custom Confidential VM, but this doesn’t satisfy all the security objectives provided by CoCo. + +#### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else? +We’ll continue to maintain the project or fork since we are already maintainers of the project. Because all major hardware vendors support Confidential Computing it is difficult to imagine a future where we abandon the cloud-native stack for it. + +#### 11. Is there something you feel that holds the project back from reaching its ultimate potential? + +We want more end users feedback. More visibility always helps. + +#### 12. In your opinion, what could the project improve? + +Ease of use, almost nothing in k8s is easy to use :) When it comes to security, details matter. The user is supplied with reasonable security defaults but for their specific requirement they have to tweak the configuration. It would be great if the project can make the configuration much easier. + +#### 13. What are the overall strengths of the project? + +Security strength along with contribution diversity. In many projects security is an after thought. In CoCo security is a primary requirement. +Additionally, the variety of hardware, cloud, and software vendors participating as maintainers gives us confidence that the project is well balanced and thoughtfully built. + +#### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. +We’ll continue to add features to our upcoming products through CoCo, such as multiple GPU support for LLMs. + +--- +### Maturity Level Survey + +The following set of questions goes beyond the scope of the specific project adoption. +Their goal is to benefit from having access to CNCF project adopters and survey their understanding of the CNCF project maturity levels and any reliance on their meaning for decision making. This information should allow the TOC to better document maturity levels targeting adopters. + +#### 1. Do you feel you have a good understanding on the meaning of each maturity level for CNCF projects? + +Yes I understand and worked with other projects going through the maturity levels. + +#### 2. Is there information missing regarding the meaning of each different level? + +No. + +#### 3. Do you rely on those levels internally in any way, and if yes how? + +Indirectly. We are less likely to rely on a project that is early in the maturity level. Our primary decision is based on the project features and implicitly our awareness of alternatives. diff --git a/projects/confidential-containers/TDC-DK-interview.md b/projects/confidential-containers/TDC-DK-interview.md new file mode 100644 index 000000000..4a4f54257 --- /dev/null +++ b/projects/confidential-containers/TDC-DK-interview.md @@ -0,0 +1,77 @@ +Interviewees: Nino Wael(NMWA@tdc.dk), Lasse(nmwa@tdc.nuuway.dk), Martin Rasmussen(maras@tdc.dk) + +Interviewer: Lin Sun + +Date: Jan 29, 2026 + +## Questions + +#### 1. How long has your organization used the project? + +A small branch within the company focusing on IT security. We knew the project for a while, and began seriously checking it out at the beginning of 2025. + +#### 2. What were the main motivations to adopt the project and which key features do you use today? + +Interested in running AI workload securely, we think CoCo would be a good fit. And running confidential workloads in general following the initial AI workloads. + +#### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project? + +Evaluated the Gramine project prior to using CoCo, it was Intel SGX based. What drew us to CoCo is it supports flexible hardware options beyond Intel (Intel TDX). The project contributors/maintainers are from different hardware vendors which is a big plus. + +#### 4. What is the current level of usage (pre-production, production) and scale? + +Pre production/POC at the moment + +#### 5. What version of the project is currently in use and what is your update cadence with the project? + +Try to follow the latest release. Version 18 CoCo. We also try to upgrade following the upgrade path. + +#### 6. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + +The project has guides/tutorials on basic things. One of the problems is when combining tutorials/features, they don’t work (additional configurations are needed) and end up looking at source code. Docs are sometimes linking to 404 or stale info. + +#### 7. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful? + +We had to check source code to find info sometimes. People are helpful on slack but had to check source code for what I needed to do (small usability wrapper/web service that uses some endpoints in the project which lack docs.) + +#### 8. Did you need to engage with the community members or maintainers? If so what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome? + +Yes we did engage with the community. It is mandatory to be in the community to fully understand what is going on. It is an extremely complex area and has a steep learning curve. People are always very helpful. + +#### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc. + +Since it is only POC, the value isn’t measurable. But compared with Gramine, it is a lot easier to use. + +#### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else? + +Nino from the team is already a contributor to the project. Depending on if we have customers, there may not be a need to maintain it. We don’t usually have bandwidth for providing maintenance on projects. If we really need it, we could fork and maintain it, assuming the maintenance value is worth the effort compared with the value provided by the project. + +#### 11. Is there something you feel that holds the project back from reaching its ultimate potential? + +Docs as discussed earlier. + +The project seems to try to cover too many features, which could be covered by existing OpenSource products, like authentication/authorization where KeyCloak could do it. + +Some features divert from the core purpose (like web interface for Trustee administration)…. + +Could use help from/integrate with other projects in CNCF vs developing all features needed in the project + +#### 12. In your opinion, what could the project improve? + +The compatibility matrix would be really nice. +Documentations - we are not expecting production grade but it could be a lot better. +A lot of code in the project is removed but still in docs… have to research source code to find out. + +Another thing is that some features are “not” supported but still available in the source code, non supported features (Azure CSI wrapper) should be clearly marked as such (ref. compatibility matrix). + +#### 13. What are the overall strengths of the project? + +Flexible hardware support and diverse contributing companies and members of the project. A lot of big tech companies are involved in the project. + +Contributing was not too hard for new contributors. + +Single pane to access confidential container features without different vendor docs/downloading different docs and compose them yourself. + +#### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +We do have plans but we are also customer driven. If we can’t convince customers, we’ll be a passive engagement with the project. From 4e895894a40def19ca2af7a9353b18da75e2a7db Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Wed, 25 Mar 2026 11:54:47 +0100 Subject: [PATCH 4/9] update CoCo incubation DD, add more checklist item assessments Signed-off-by: Kevin Wang --- .../confidential-containers-incubation-dd.md | 43 +++++++++++++------ 1 file changed, 30 insertions(+), 13 deletions(-) diff --git a/projects/confidential-containers/confidential-containers-incubation-dd.md b/projects/confidential-containers/confidential-containers-incubation-dd.md index b0b1616da..0e823bd4b 100644 --- a/projects/confidential-containers/confidential-containers-incubation-dd.md +++ b/projects/confidential-containers/confidential-containers-incubation-dd.md @@ -179,33 +179,50 @@ Note: this section may be augmented by the completion of a Governance Review fro ### Suggested -- [ ] **Roadmap change process is documented.** +- [x] **Roadmap change process is documented.** - + + The project adopts a [use-case driven development approach](https://confidentialcontainers.org/blog/2024/02/16/introduction-to-confidential-containers-coco/#foundational-principles), focusing community efforts on key scenarios rather than feature-centric models. The roadmap and scope are determined via consensus in the [Steering Committee and weekly community meetings](https://docs.google.com/document/d/1E3GLCzNgrcigUlgWAZYlgqNTdVwiMwCRTJ0QnJhLZGA/edit), with changes documented in the public [roadmap.md](https://github.com/confidential-containers/confidential-containers/blob/main/roadmap.md). -- [ ] **History of regular, quality releases.** +- [x] **History of regular, quality releases.** - + + The project documents historical releases with change notes at: -### Required +### Required -- [ ] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. _This requirement may also be satisfied by completing a General Technical Review._** - - _If applicable_ a general Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK. +- [x] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. _This requirement may also be satisfied by completing a General Technical Review._** + - The general Technical Review was updated on 24-Feb-2026 (currently in Draft status), and can be discovered at . - + + The project's goals and differentiation are documented through its [website](https://confidentialcontainers.org): _"...enables cloud native data in use protection by leveraging hardware Trusted Execution Environments (TEEs)."_ The project's documentation and draft GTR also describe how it solves this problem differently by encapsulating unmodified Kubernetes pods inside confidential VMs, completely shielding workloads from host operating systems, cluster administrators, and cloud providers. -- [ ] **Document what the project does, and why it does it - including viable cloud native use cases.** +- [x] **Document what the project does, and why it does it - including viable cloud native use cases.** - + + The project clearly documents its core function, motivation, and practical applications: -- [ ] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** + - What the project does: + - Why it does it: + - Viable use cases include the following: (Ref: ) + - Confidential AI + - Switchboard Oracles: Securing Web3 Data with Confidential Containers + - Secure Supply Chain (Trusted Pipeline) - +- [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** + + + According to the [roadmap.md](https://github.com/confidential-containers/confidential-containers/blob/main/roadmap.md) the project maintains its： + - short-term roadmap at the GitHub boards (including the [Confidential containers github board](https://github.com/orgs/confidential-containers/projects/6) and [Trustee github board](https://github.com/orgs/confidential-containers/projects/10)), and + - its mid/long-term roadmap at the project's website based on use-case driven development. Ref: + + **TODO for maintainers**: the short-term roadmap Confidential containers github board link is unavailable with outdated "view", needs to be fixed. - [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. _This requirement may also be satisfied by completing a General Technical Review._** - _If applicable_ a general Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK. - + + The project maintains a detailed architectural overview on its [website](https://confidentialcontainers.org/docs/architecture/design-overview/), demonstrating a robust and viable cloud-native design. It effectively outlines key mechanisms such as Pod-Centric Virtualization, host deprivileging, and its sophisticated remote attestation (Trustee) architecture. - [ ] **Document the project's release process.** From 583f1077a2b07efe24264a80654459d78d8a2a79 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Fri, 10 Apr 2026 17:08:22 -0400 Subject: [PATCH 5/9] Add IBM adopter interview notes on CoCo Signed-off-by: Kevin Wang --- .../confidential-containers/IBM-interview.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 projects/confidential-containers/IBM-interview.md diff --git a/projects/confidential-containers/IBM-interview.md b/projects/confidential-containers/IBM-interview.md new file mode 100644 index 000000000..604813e94 --- /dev/null +++ b/projects/confidential-containers/IBM-interview.md @@ -0,0 +1,96 @@ +Interviewer: Lin Sun + +Interviewee: Nicolas Mäding (NMAEDING@de.ibm.com) + +Date: March 2, 2026 + +## Questions: + +#### 1. How long has your organization used the project? + +We started to actively contribute and participated in and promoted the project since it was formed in 2021. We had some internal PoTs and PoCs based on the Confidential Containers Project (https://github.com/confidential-containers) +since then. + +#### 2. What were the main motivations to adopt the project and which key features do you use today? + +From my point of view this is the most mature CNCF project in this area and has key industry participants contributing and collaborating. We primarly use the s390x and IBM Secure Execution for Linux versions of the project as well as the +Trustee component. + +#### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project? + +It has the most references and contributions by various partners and technologies providers, which makes it for me the reference project around Confidential Computing in the CNCF context. There are different products also +regarding non-CNCF based deployments - Kernel-based Virtual Machines (KVM) and Public Cloud (VSIs) - and I believe based on my experience and customer feedback that a community driven project is key for adoption of this technology +in production. + +#### 4. What is the current level of usage (pre-production, production) and scale? + +In my opinion, production adoptions depend on the availability of additional features like Baremetal support and an established common Trustee flow. This is +work in progress within the project; the TechPreview has been out since 4Q25 and we intend to harden and further improve its design to enable more usecases. + +https://www.ibm.com/docs/en/ccro/1.1.x?topic=platform-confidential-computing-linuxone +https://www.ibm.com/docs/en/rhocp-ibm-z?topic=hyper-protect-confidential-container-red-hat-openshift-container-platform-bare-metal-beta + +#### 5. What version of the project is currently in use and what is your update cadence with the project? + +We are using 0.16.0 and contributing to main. We intend to update the latest version as soon as it becomes available as it is the foundation for our Kubernetes +platform our product is built upon. + +#### 6. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + +As we intend to adopt the project for Linux on IBM Z and LinuxONE (s390x architecture), the key challenge from my point of view is the focus on Intel/AMD +(x86 architecture) and adoption by Public Cloud Providers rather than on Premises datacenter. + +So different adopting and enabling use cases on different platforms leads to different architectural decisions and adoption of changes. The project from my point of view is too focused on getting the Public Cloud adoption progress and +making decisions focused on this deployment model. I acknowledge that x86 is widespread, but a flexible architecture taking different approaches and deployments into account fosters in my opinion innovation and better solutions +for many use cases to come. + +#### 7. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful? + +The available documentation is sufficient and fine. High-level technology independent architectural pictures are useful in this context. +As this project matures further, thread model documentation will be an important value-add to be made available through the community. + +#### 8. Did you need to engage with the community members or maintainers? If so, what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome? + +We have several team members who are maintainers on the project, so we are in communication with the wider community on a near-daily basis via slack, github and the regular Confidential Containers zoom meetings. + +#### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc. + +Yes, this project provides a common approach and project across different hardware and system architectures, which has values in my opinion for many as they get an ease-of-use solution with this project across their hybrid cloud +datacenter. + +#### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else? + +The impact would be significant, and we would need to investigate options, if that would become a risk. + +#### 11. Is there something you feel that holds the project back from reaching its ultimate potential? + +Not at this point. + +#### 12. In your opinion, what could the project improve? + +Be more open to other technologies, processor architectures and deployment models. + +#### 13. What are the overall strengths of the project? + +As stated, the contributions from so many participants across the industry and technical community. + +#### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +We intend to contribute, request features for different solutions, improved user experience, and plan to continue our involvement as products depend on this project and the underlaying technology. + +--- +## Maturity Level Survey + +The following set of questions goes beyond the scope of the specific project adoption. Their goal is to benefit from having access to CNCF project adopters and survey their understanding of the CNCF project maturity levels and any reliance on their meaning for decision making. This information should allow the TOC to better document maturity levels targeting adopters. + +#### 1. Do you feel you have a good understanding on the meaning of each maturity level for CNCF projects? + +Yes. + +#### 2. Is there information missing regarding the meaning of each different level? + +Not at this point. + +#### 3. Do you rely on those levels internally in any way, and if yes how? + +Indirectly. The maturity of the projects used are foremost part of our internal risk assessment and are beneficial as this is proof that a given project and/or concept is accepted in the community and industry at large. From 0b5faef1659c0edd983d9825dfb17e098a507d66 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Mon, 27 Apr 2026 21:50:47 -0400 Subject: [PATCH 6/9] Fill out adoption section and refine interview details in CoCo incubation DD Signed-off-by: Kevin Wang --- .../confidential-containers-incubation-dd.md | 81 ++++++++++++++----- 1 file changed, 62 insertions(+), 19 deletions(-) diff --git a/projects/confidential-containers/confidential-containers-incubation-dd.md b/projects/confidential-containers/confidential-containers-incubation-dd.md index 0e823bd4b..9e58db85b 100644 --- a/projects/confidential-containers/confidential-containers-incubation-dd.md +++ b/projects/confidential-containers/confidential-containers-incubation-dd.md @@ -300,39 +300,82 @@ N/A ### Required -- [ ] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** +- [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** - - -- [ ] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** +The list of adopters can be found in the project repo: https://github.com/confidential-containers/confidential-containers/blob/main/ADOPTERS.md which includes the usage level. Most adopters are at the beta level. - +- [x] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** -The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. +The project provided the TOC with a list of adopters for verification of use of the project at the level expected, dev/test for incubation. The TOC was able to verify confirm at least dev/test use with all interviewed adopters. -- [ ] **TOC verification of adopters.** +- [x] **TOC verification of adopters.** - +The CoC maintainers provided the TOC with a list of 5-6 adopters who agreed to be interviewed for the Incubation Due Diligence process. 4 of these adopters were interviewed. The adoption portion of this document contains interview summaries from adopters who approved public attribution. All adopters are verified using CoC at the level appropriate for incubation. Refer to the Adoption portion of this document. -- [ ] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** +- [x] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** - +This is documented in the [alignment documentation](https://github.com/confidential-containers/confidential-containers/blob/main/alignment.md) in the project repo. This document contains the list of CNCF projects that are directly related to CoCo, list of non CNCF projects that are directly related to CoCo along with other potential related projects. #### Adoption -##### Adopter 1 - $COMPANY/$INDUSTRY +##### Adopter 1 - IBM/Technology + +In a March 2, 2026 interview, Nicolas Mäding explained that IBM has been contributing to and promoting Confidential Containers since 2021, including running internal trials. IBM considers it the most mature option within the Cloud Native Computing Foundation ecosystem, largely due to strong industry participation. Their work emphasizes s390x, IBM Secure Execution, and Trustee. + +Production adoption depends on two key factors: support for bare metal and a standardized Trustee model. Both are still evolving following a Q4 2025 tech preview that IBM plans to harden. The team currently runs version 0.16.0, contributes upstream, and intends to stay aligned with future releases since the project underpins their Kubernetes product. + +A key tension lies in roadmap priorities—particularly the emphasis on x86 and public cloud versus on-premises environments and IBM Z/LinuxONE systems. IBM advocates for a more balanced approach across architectures and deployment models. + +Documentation is considered solid, especially architecture diagrams, though improved threat modeling would be beneficial as the project matures. Maintainers are highly engaged via Slack, GitHub, and Zoom. IBM sees the project’s primary value as enabling a unified hybrid-cloud approach across diverse hardware. Archiving the project would have a significant negative impact. + +Improvement area: greater openness to non-x86 architectures and alternative deployment models. + +Refer to the full [interview report](IBM-interview.md) for more details. + +##### Adopter 2 - AccuKnox/Technology + +In a February 10, 2026 interview, AccuKnox (represented by Rahul Jadhav, interviewed by Lin Sun) described using Confidential Containers (CoCo) in 5G security—specifically for intent-based security in 5G ORAN and Core environments. + +A key use case is protecting the 5G UDR (Unified Data Repository), which stores highly sensitive data such as subscription keys. Because this data often resides in public cloud environments—where cloud service provider root access must be assumed as a threat—CoCo provides a mechanism to secure these workloads using hardware-backed isolation. + +AccuKnox views CoCo as uniquely capable of delivering a full Trusted Execution Environment (TEE) pathway for containerized workloads. Features such as cloud API adapters have been particularly valuable, especially after early integration challenges with AWS. + +Their current usage remains pre-production which matches the expected level for incubation. They are running version 0.13.0 (approximately one year behind) and have not kept related components like 5g-blueprint-controls fully updated. While documentation was helpful, they relied heavily on Slack support from community members such as Pradeepta. + +They presented their 5GSEC work to the community and were encouraged to list themselves as adopters. AccuKnox frames CoCo’s value in terms of improving security posture in untrusted cloud environments, where TEE-based solutions are often the only viable option. + +Gaps identified: Limited hardware availability, Interface instability and High cost. They recommend clearer messaging and better articulation of real-world use cases, rather than focusing solely on deep technical detail. Their enterprise future plan includes integrating CoCo into AccuKnox Enterprise, particularly for government and federal deployments. + +Refer to the full [interview report](AccuKnox-interview.md) for more details. + +##### Adopter 3 - NVIDIA/Technology + +In a January 23, 2026 interview, Dan Middleton from NVIDIA described roughly two years of involvement with Confidential Containers as maintainers, ecosystem contributors, and adopters. He explained confidential computing as leveraging CPU and GPU features to create protected memory regions—similar to VM-level isolation—shielded from other tenants. CoCo enables this capability in a Kubernetes-native way. + +NVIDIA’s motivations fall into three categories: +- Enabling GPU support so AI workloads can leverage confidential computing +- Building products on top of CoCo (e.g., integration with Red Hat OpenShift) +- Meeting internal and external datacenter security requirements with a cloud-native confidential stack + +NVIDIA views CoCo as the leading cloud-native confidential computing project due to its momentum, feature set, and broad ecosystem support across cloud providers, hardware vendors, and ISVs. Current status is pre-production which matches the expected level for incubation. They expect early access external offerings, with GA targeted for late Q1 2026. They are using version: 0.18, and tracking releases closely (downstream users follow OpenShift cadence). + +Adoption was relatively smooth due to internal expertise. Initial integration challenges—mainly around compatibility with other CNCF components like container runtimes—have largely been resolved. Documentation has improved significantly, especially with the introduction of a unified docs site. + +NVIDIA actively engages through community meetings, GitHub, and Slack. Key strengths of the project is strong security-first design, broad and diverse maintainer base and faster and less complex integration compared to alternatives (e.g., kubelet-in-confidential-VM). + +Key improvement areas are more end-user feedback and visibility, easier usability and simplified per-tenant security configuration. + +Refer to the full [interview report](NVIDIA-interview.md) for more details. -_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ -MONTH YEAR +##### Adopter 4 - TDC/Technology -##### Adopter 2 - $COMPANY/$INDUSTRY +In a January 29, 2026 interview, TDC (Denmark)—Nino Wael, Lasse, and Martin Rasmussen, interviewed by Lin Sun—describes a small IT-security-focused group that knew CoCo earlier but seriously evaluated it from early 2025. The main pull is running AI workloads securely, then broader confidential workloads. They previously looked at Gramine (Intel SGX-centric) and moved toward CoCo for broader hardware options (including Intel TDX) and multi-vendor contributors—seen as a major advantage. The current stage is pre-production / POC only, so no measurable business value yet; subjectively, CoCo is much easier than Gramine. They try to stay on the latest release (CoCo 0.18) and follow upgrade paths. -_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ -MONTH YEAR +Pain points is that basic tutorials exist, but combining features often breaks without extra config, pushing them to read source. Docs sometimes 404, go stale, or describe removed code; some endpoints lack documentation for their small integration layer. Slack is helpful but insufficient alone. They treat community engagement as mandatory given complexity and a steep learning curve. +Scope critique: they feel the project sometimes sprawls into areas better handled elsewhere (e.g. Keycloak for authz), including non-core items like a Trustee admin web UI—they’d prefer deeper CNCF integration over building everything in-tree. -##### Adopter 3 - $COMPANY/$INDUSTRY +Strengths of the project is its hardware flexibility, strong vendor participation, approachable contribution, and a single pane to confidential containers versus stitching per-vendor docs. Improvements areas are a compatibility matrix, clearer marking of unsupported paths (e.g. Azure CSI wrapper), and cleaner, truthful documentation. -_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ -MONTH YEAR +Refer to the full [interview report](TDC-DK-interview.md) for more details. From 592213571ec6c7d753b96de3ccbc4933a792d80e Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Tue, 16 Jun 2026 00:23:40 +0800 Subject: [PATCH 7/9] update CoCo incubation DD, finish all sections and add summary Signed-off-by: Kevin Wang --- .../confidential-containers-incubation-dd.md | 200 +++++++++++------- 1 file changed, 125 insertions(+), 75 deletions(-) diff --git a/projects/confidential-containers/confidential-containers-incubation-dd.md b/projects/confidential-containers/confidential-containers-incubation-dd.md index 9e58db85b..6f731a075 100644 --- a/projects/confidential-containers/confidential-containers-incubation-dd.md +++ b/projects/confidential-containers/confidential-containers-incubation-dd.md @@ -8,15 +8,47 @@ ### Criteria Evaluation -_$TOCMEMBER conducted the due diligence of Confidential Containers who applied for $LEVEL. The project [has/has not] completed the criteria that show its maturity at $LEVEL. The following criteria implementations are noteworthy to call out... $NOTABLES. The following actions were provided to the project that were considered blocking but since resolved... $BLOCKERS. The following recommendations were provided to the project that are non-blocking in the TOC's assessment but should be completed by the project to ensure continued viability of the project... $RECOMMENDATIONS._ +Kevin Wang, Faseela K, and Lin Sun conducted the due diligence of Confidential Containers, which applied for Incubation. This effort was also supported by a [General Technical Review from Matt Young](https://github.com/cncf/toc/pull/2051) and a [Governance Review from Josh Gavant](https://github.com/cncf/toc/pull/2081). The project has completed the criteria that show its maturity at Incubation. + +#### Noteworthy Implementations + +- **Vendor neutrality enforced on the Steering Committee**: The Steering Committee caps each organization at two seats and currently spans seven companies (Alibaba, IBM, Intel, AMD, Red Hat, NVIDIA, Microsoft), with a process to keep membership tracking the project's major contributors. +- **Governance iterated over time**: The governance document has changed as the project has run, with examples including inactive-maintainer removal rules and provisions for members who change employer or leave ([#235](https://github.com/confidential-containers/confidential-containers/pull/235), [#329](https://github.com/confidential-containers/confidential-containers/pull/329), [#348](https://github.com/confidential-containers/confidential-containers/pull/348), [#339](https://github.com/confidential-containers/confidential-containers/pull/339), [#338](https://github.com/confidential-containers/confidential-containers/pull/338)). +- **Alignment with its main dependency, Kata Containers**: Kata Containers contributors sit on the CoCo Steering Committee, and the 6-week release cadence follows the Kata lifecycle. +- **Subproject-to-repository mapping**: Each subproject lives in its own repository, and the mapping of components to subprojects is documented on the project [website](https://confidentialcontainers.org/docs/architecture/design-overview/#components). +- **Secure-by-default architecture**: The design denies the host access to container images (pulled inside the guest enclave via `image-rs`), releases secrets only after attestation through Trustee, and applies deny-by-default OPA policies on the Kata Agent API to block host interference. +- **Signed build provenance at SLSA Build Level 2**: The project generates signed `in-toto` provenance via GitHub Actions for components such as `kata-containers`, `guest-components`, and `cloud-api-adaptor`. +- **Consistent, well-documented release process**: The project releases on a 6-week cadence and runs each release against a standardized checklist. + +#### Blockers (Previously Raised, Now Resolved) + +- **Access Control and 2FA Enforcement**: The project was asked to document and enforce 2FA for privileged roles and make the access-control model publicly auditable. This was resolved in [confidential-containers/confidential-containers#351](https://github.com/confidential-containers/confidential-containers/pull/351), which updated `governance.md` to explicitly require 2FA for org members, maintainers, Steering Committee members, and Security Managers, and to describe how maintainer access is granted and revoked via GitHub teams. +- **Security Response Role Documentation**: The project was asked to formally define security response roles and document how vulnerability reports are handled. This was resolved through [confidential-containers/confidential-containers#351](https://github.com/confidential-containers/confidential-containers/pull/351) and [confidential-containers/.github#25](https://github.com/confidential-containers/.github/pull/25), which introduced the Security Manager role in `governance.md`, aligned `SECURITY.md` with the governance language, and added a link from `CONTRIBUTING.md` to the security reporting guidance. + +#### Recommended Enhancements (Non-Blocking) + +- **Publish a public maintainer and team-membership list**: Maintainer and functional-role assignments are managed through private GitHub teams referenced in `CODEOWNERS`, so they are not publicly readable. The TOC reviewers recommend publishing this membership through declarative configuration using a tool such as [cilium/team-manager](https://github.com/cilium/team-manager) or [CLOWarden](https://github.com/cncf/clowarden). +- **State vendor neutrality explicitly in governance**: Vendor neutrality is enforced through the two-seat-per-organization Steering Committee limit, but the governance documents do not state it as a principle. The reviewers recommend adding a vendor-neutrality clause before graduation. +- **Move governance and community docs into a community repository**: With 10+ active non-fork repositories, the reviewers suggest a dedicated community repository to hold governance and community documentation. +- **Document subproject governance details**: The subproject removal process, per-subproject maturity status, and a public per-subproject maintainer list are not yet documented and should be completed before graduation. +- **Integrate with the official CNCF calendar**: Weekly community meetings are documented in a public Google Doc; adding them to the official CNCF calendar would make them easier to find. +- **Keep the contributing guide current**: The contributing guide has not been updated since 2024 and should be reviewed periodically to match the current state of the project. +- **Fix the short-term roadmap board link**: The short-term roadmap link to the Confidential Containers GitHub board in `roadmap.md` is broken (outdated "view") and should be corrected. +- **Recruit more adopters and case studies**: Adopter verification was met through interviews; the project should keep recruiting adopters and encouraging public case studies. ### Adoption Evaluation -_The adopter interviews reflect a project [in use/too early] for the level which the project applied. They show ... $INTERVIEWSUMMARY._ +The TOC interviewed four adopters of Confidential Containers — IBM, NVIDIA, AccuKnox, and TDC — spanning hardware vendors, cloud and security vendors, telecom, and enterprise IT across multiple geographies. All four reported pre-production or dev/test usage on recent releases (versions 0.13 through 0.18), which matches the level of adoption expected for Incubation. Several adopters also contribute upstream or hold maintainer roles, and most track the project closely as the foundation for downstream products. + +Adopters consistently described Confidential Containers as the primary cloud-native project offering a full Trusted Execution Environment pathway for containerized workloads. The most commonly cited strengths were its multi-vendor maintainer base and hardware flexibility — covering Intel TDX, IBM Secure Execution, and NVIDIA GPUs — which drew adopters away from single-vendor alternatives such as Intel SGX-based Gramine. Adopters also valued the security-first design and the active maintainer engagement through Slack, GitHub, and the weekly community meeting. + +Reported value centered on securing sensitive workloads in untrusted environments, a unified hybrid-cloud approach across diverse hardware, and faster integration compared with building a confidential stack in-house. Because the interviewees are still pre-production, few could quantify business value yet, though several noted that archiving the project would have a significant negative impact on their products. + +Common areas for improvement were documentation (stale or broken links, a missing threat model, and the lack of a compatibility matrix), ease of configuration, clearer use-case messaging over deep technical detail, and concern that the project's scope is expanding into areas already served by other CNCF projects. Overall, Confidential Containers is in active use at a level appropriate for Incubation, with a diverse and engaged adopter base and a clear path to deeper production adoption as hardware availability and documentation mature. ### Final Assessment -_[The TOC has found the project to have satisfied the criteria for $LEVEL/ The TOC's evaluation of the project shows a needed focus to complete the outstanding blockers and reapply when the following conditions are met ... $CONDITIONS]._ +The TOC has found the project to have satisfied the criteria for Incubation. ## Application Process Principles @@ -45,14 +77,14 @@ N/A - The project contacts and TOC Reviewers had a kick-off meeting on Jan. 16th, set expectations and discussed general steps & timelines. -- [ ] **Due Diligence Review.** +- [x] **Due Diligence Review.** Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria. -- [ ] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** +- [x] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** - The project provides approriate documents for installation and configuration, e.g.: + The project provides appropriate documents for installation and configuration, e.g.: ## Governance and Maintainers @@ -67,18 +99,17 @@ Note: this section may be augmented by the completion of a Governance Review fro - Update governance doc to include rules of removing inactive maintainers - Add provisions to the governance document for members who move from one company to another or who become inactive or leave the project. - - [x] **Clear and discoverable project governance documentation.** The [project governance doc](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md) is maintained in the main repository. - **Suggestion by Kevin:** Since CoCo has 10+ active non-fork repos, TOC reviewers suggest to consider creating a community repository and maintain governance and community relavent docs there. + Since CoCo has 10+ active non-fork repos, TOC reviewers suggest to consider creating a community repository and maintain governance and community relavent docs there. - [x] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** - The project maintains an active and up-to-date governance framework that accurately reflects the current project state. The documentation is regularly updated to capture Steering Committee leadership transitions, organizational representation changes, and refinements to maintainer lifecycle processes. + The governance documentation is kept up to date with the current project state, including Steering Committee leadership transitions, organizational representation changes, and changes to maintainer lifecycle processes. Some examples are: - removed AMD rep Ryan Savino from SC and added to emeritus @@ -90,54 +121,73 @@ Note: this section may be augmented by the completion of a Governance Review fro As outlined in [GOVERNANCE.md](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md), the CoCo project effectively operationalizes vendor neutrality through structural mechanisms, specifically the two-seat limit per organization on the Steering Committee. - **Suggestion by Kevin:** It is noted that the documentation currently lacks an explicit definition of 'vendor neutrality' as a core principle. The TOC reviewers recommend explicitly codifying a Vendor Neutrality clause to align with CNCF best practices before the project advances to graduation. + The TOC reviewers note that the governance documents do not state 'vendor neutrality' as an explicit principle, and recommend adding a vendor-neutrality clause before the project advances to graduation. - [x] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** [GOVERNANCE.md#decision-making](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md#decision-making) explicitly documents a consensus-driven framework. It establishes a clear voting protocol for critical decisions, specifically leadership changes and governance modifications, requiring a defined supermajority threshold (2/3rds of current SC members) when consensus is not achieved. -- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** +- [x] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** + + + The project's [GOVERNANCE.md](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md#becoming-a-project-maintainer) defines how maintainer roles are assigned via GitHub teams. Functional roles like "security managers" are also documented. However, the TOC reviewers noted that since these assignments are managed via private GitHub teams, a public list of these roles is not currently available. - + The TOC reviewers suggest the project either maintain a public list manually or use a tool such as [team-manager](https://github.com/cilium/team-manager) to improve openness and transparency. -- [ ] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** +- [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** - + + The [GOVERNANCE.md](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md) documents the complete lifecycle, including onboarding (building trust/contributions) and removal processes for both Maintainers and the Steering Committee. -- [ ] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** +- [x] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** - + + The project demonstrates maintainer lifecycle outcomes through recorded updates in various sub-projects, such as [Trustee](https://github.com/confidential-containers/trustee/issues?q=is%3Aissue++in%3Atitle+maintainer) and [guest-components](https://github.com/confidential-containers/guest-components/issues?q=is%3Aissue++in%3Atitle+maintainer). - [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** - + + Subproject leadership and contribution follow the organization-level [governance](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md). + + The TOC reviewers note that the following subproject governance details are not yet documented and recommend completing them before graduation: + - The subproject removal process. + - The maturity status of individual subprojects. + - A public per-subproject maintainer list. ### Required -- [ ] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** +- [x] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** - + + The project documents maintainers list with all the relevant information at . -- [ ] **A number of active maintainers which is appropriate to the size and scope of the project.** +- [x] **A number of active maintainers which is appropriate to the size and scope of the project.** - + + Based on [LFX Insights](https://insights.linuxfoundation.org/project/confcont/contributors), the project has a broad group of active contributors from multiple organizations, which is appropriate for its scale. + +- [x] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** -- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** + + The project uses `CODEOWNERS` files across its repositories to enforce ownership in alignment with the documented GitHub team-based governance. - + While `CODEOWNERS` files reference GitHub teams, the membership of those teams is only visible to members of the organization and not publicly accessible. The TOC reviewers suggest considering a tool that manages org and team membership declaratively via public configuration, such as [cilium/team-manager](https://github.com/cilium/team-manager) ([config example](https://github.com/cilium/community/tree/main/ladder)), [CLOWarden](https://github.com/cncf/clowarden) ([config example](https://github.com/cncf/people)), or a similar tool, to improve transparency and auditability of project membership. -- [ ] **Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.** +- [x] **Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.** - + + The project has adopted the CNCF Code of Conduct, as documented in its [CODE_OF_CONDUCT.md](https://github.com/confidential-containers/confidential-containers/blob/main/CODE_OF_CONDUCT.md). -- [ ] **CNCF Code of Conduct is cross-linked from other governance documents.** +- [x] **CNCF Code of Conduct is cross-linked from other governance documents.** - + + The Code of Conduct is discoverable in the `.github` repository and linked from the project's metadata. -- [ ] **All subprojects, if any, are listed.** +- [x] **All subprojects, if any, are listed.** - + + The project lists its subprojects and components on its [website](https://confidentialcontainers.org/docs/architecture/design-overview/#components), including Trustee, guest-components, cloud-api-adaptor, operator, trustee-operator, and td-shim. ## Contributors and Community @@ -145,35 +195,44 @@ Note: this section may be augmented by the completion of a Governance Review fro ### Suggested -- [ ] **Contributor ladder with multiple roles for contributors.** +- [x] **Contributor ladder with multiple roles for contributors.** - + + The contributor ladder and roles are defined in the [governance document](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md#community-members-and-roles). ### Required -- [ ] **Clearly defined and discoverable process to submit issues or changes.** +- [x] **Clearly defined and discoverable process to submit issues or changes.** + + + The process for submitting changes is clearly defined in the [CONTRIBUTING.md](https://github.com/confidential-containers/.github/blob/main/CONTRIBUTING.md) and on the project's [website](https://confidentialcontainers.org/docs/contributing/#making-contributions). - +- [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** -- [ ] **Project must have, and document, at least one public communications channel for users and/or contributors.** + + The project uses the `#confidential-containers` channel on CNCF Slack as its primary public communication channel. - +- [x] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** -- [ ] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** + + Communication channels, including Slack and the weekly community meeting, are documented in the [contributing guide](https://confidentialcontainers.org/docs/contributing/#connecting-with-the-community). - +- [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** -- [ ] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** + + Weekly community meetings are held and documented in a [public Google Doc](https://docs.google.com/document/d/1E3GLCzNgrcigUlgWAZYlgqNTdVwiMwCRTJ0QnJhLZGA/). - + The TOC reviewers recommend integrating the meetings with the official CNCF calendar to improve discoverability. -- [ ] **Documentation of how to contribute, with increasing detail as the project matures.** +- [x] **Documentation of how to contribute, with increasing detail as the project matures.** - + + A [contributing guide](https://confidentialcontainers.org/docs/contributing/) is maintained. The TOC reviewers noted it should be reviewed periodically to match the current state of the project. -- [ ] **Demonstrate contributor activity and recruitment.** +- [x] **Demonstrate contributor activity and recruitment.** - + + Contributor activity is actively tracked and demonstrated via [LFX Insights](https://insights.linuxfoundation.org/project/confcont) and [CNCF DevStats](https://confidentialcontainers.devstats.cncf.io/). ## Engineering Principles @@ -192,7 +251,7 @@ Note: this section may be augmented by the completion of a Governance Review fro ### Required - [x] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. _This requirement may also be satisfied by completing a General Technical Review._** - - The general Technical Review was updated on 24-Feb-2026 (currently in Draft status), and can be discovered at . + - The General Technical Review was updated on 24-Feb-2026 (currently under review), and can be discovered at . The project's goals and differentiation are documented through its [website](https://confidentialcontainers.org): _"...enables cloud native data in use protection by leveraging hardware Trusted Execution Environments (TEEs)."_ The project's documentation and draft GTR also describe how it solves this problem differently by encapsulating unmodified Kubernetes pods inside confidential VMs, completely shielding workloads from host operating systems, cluster administrators, and cloud providers. @@ -212,21 +271,26 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** - According to the [roadmap.md](https://github.com/confidential-containers/confidential-containers/blob/main/roadmap.md) the project maintains its： + According to the [roadmap.md](https://github.com/confidential-containers/confidential-containers/blob/main/roadmap.md), the project maintains its: - short-term roadmap at the GitHub boards (including the [Confidential containers github board](https://github.com/orgs/confidential-containers/projects/6) and [Trustee github board](https://github.com/orgs/confidential-containers/projects/10)), and - its mid/long-term roadmap at the project's website based on use-case driven development. Ref: - **TODO for maintainers**: the short-term roadmap Confidential containers github board link is unavailable with outdated "view", needs to be fixed. + The short-term roadmap Confidential containers github board link is unavailable with an outdated "view", needs to be fixed. Ref: -- [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. _This requirement may also be satisfied by completing a General Technical Review._** - - _If applicable_ a general Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK. +- [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. _This requirement may also be satisfied by completing a General Technical Review._** + - The General Technical Review was updated on 24-Feb-2026 (currently under review), and can be discovered at . - The project maintains a detailed architectural overview on its [website](https://confidentialcontainers.org/docs/architecture/design-overview/), demonstrating a robust and viable cloud-native design. It effectively outlines key mechanisms such as Pod-Centric Virtualization, host deprivileging, and its sophisticated remote attestation (Trustee) architecture. + The project maintains a detailed architectural overview on its [website](https://confidentialcontainers.org/docs/architecture/design-overview/), covering key mechanisms such as Pod-Centric Virtualization, host deprivileging, and the remote attestation (Trustee) architecture. -- [ ] **Document the project's release process.** +- [x] **Document the project's release process.** - + + The project maintains a well-documented and consistent release process. + + It follows a [6-week release cadence](https://github.com/confidential-containers/confidential-containers/blob/main/README.md) aligned with the Kata Containers lifecycle. + + The community utilizes a standardized release checklist ([.github/ISSUE_TEMPLATE/release-check-list.md](https://github.com/confidential-containers/confidential-containers/blob/main/.github/ISSUE_TEMPLATE/release-check-list.md)) to ensure quality and consistency across releases. ## Security @@ -246,39 +310,25 @@ Note: this section may be augmented by a joint-assessment performed by TAG Secur The policy instructs reporters to use GitHub’s “Report a vulnerability” (private reporting) mechanism rather than filing public issues. -- [ ] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** +- [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** - **Maintainers’ input (from application):** The incubation application references a maintainers list as evidence that maintainers use 2FA: - - Maintainers list: + This was initially found blocking but fixed by [confidential-containers/confidential-containers#351](https://github.com/confidential-containers/confidential-containers/pull/351). - **TOC reviewer assessment / gap (from confidential-containers/confidential-containers#349):** - - A maintainer list does **not** by itself provide auditable evidence that 2FA is **required and enforced** for GitHub org members/maintainers. - - Reviewers need a **clear, stable, public** reference describing: - - how access is granted/revoked, - - what controls prevent unauthorized changes (e.g., CODEOWNERS / required reviews / branch protection expectations), - - whether 2FA is required/enforced for privileged roles. + According to the updated [governance.md](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md), the project now explicitly requires 2FA for GitHub org members, maintainers, Steering Committee members, and Security Managers. It also documents that maintainer access is managed through GitHub teams referenced in each repository's `CODEOWNERS` file, while clarifying that GitHub org membership is not a formal governance tier. - **Action / follow-up requested:** Project to document the access control model and explicitly document 2FA requirements and/or org enforcement: - - + Issue [#349](https://github.com/confidential-containers/confidential-containers/issues/349) was then closed as completed on Mar 3, 2026. -- [ ] **Document assignment of security response roles and how reports are handled.** +- [x] **Document assignment of security response roles and how reports are handled.** - **Maintainers’ input (from application):** - - The project points to the org-level `SECURITY.md` as the place describing handling of reports: - - + This was initially found blocking but fixed by [confidential-containers/confidential-containers#351](https://github.com/confidential-containers/confidential-containers/pull/351) and [confidential-containers/.github#25](https://github.com/confidential-containers/.github/pull/25). + + According to the updated [governance.md](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md), the project now defines the Security Manager role directly, including who holds that role, how additional Security Managers are added or removed, and how they may coordinate with affected external parties on a need-to-know basis during pending advisories. - **TOC reviewer assessment / gap (from confidential-containers/confidential-containers#350):** - - While `SECURITY.md` describes the reporting mechanism, it historically referenced “maintainers and security champions” without a clearly defined, discoverable role model elsewhere (e.g., in governance/community docs). - - Reviewers need more explicit documentation of: - - who the security responders are (org-wide vs per subproject), - - how membership/ownership is determined and maintained (onboarding/offboarding/continuity), - - high-level responsibilities (triage/coordination/communication), without duplicating the mechanics already in `SECURITY.md`. - - Also recommended: cross-link security reporting guidance from contributing documentation (and other relevant guides), so users can easily find the security reporting process. + In parallel, [confidential-containers/.github#25](https://github.com/confidential-containers/.github/pull/25) aligned `SECURITY.md` with the governance language, replaced the older "security champions" terminology, and added a link from `CONTRIBUTING.md` to the security reporting guidance so the reporting path is easier to find. - **Action / follow-up requested:** - - + Taken together, these changes address the documentation gap raised in issue [#350](https://github.com/confidential-containers/confidential-containers/issues/350). - [x] **Document Security Self-Assessment.** From 67dac9aac95db27b11493d9609d3a234ce1caed7 Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Wed, 17 Jun 2026 10:24:58 +0800 Subject: [PATCH 8/9] Apply review suggestions for CoCo dd Co-authored-by: Faseela K Signed-off-by: Kevin Wang --- projects/confidential-containers/AccuKnox-interview.md | 2 +- projects/confidential-containers/IBM-interview.md | 4 ++-- .../confidential-containers-incubation-dd.md | 8 ++++---- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/projects/confidential-containers/AccuKnox-interview.md b/projects/confidential-containers/AccuKnox-interview.md index d3b70d872..6a2493214 100644 --- a/projects/confidential-containers/AccuKnox-interview.md +++ b/projects/confidential-containers/AccuKnox-interview.md @@ -49,7 +49,7 @@ I presented the work we did in 5Gsec to the CoCo community and that's when they #### 9. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc. Measurable value is improved security posture. There is no alternative to TEE/CoCo based execution for certain threat models -wherein if one cannot trust the cloud platform provider than the only hope left is to deploy using CoCo the sensitive workloads. +wherein if one cannot trust the cloud platform provider, then the only hope left is to deploy using CoCo the sensitive workloads. #### 10. If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else? diff --git a/projects/confidential-containers/IBM-interview.md b/projects/confidential-containers/IBM-interview.md index 604813e94..a99e4a908 100644 --- a/projects/confidential-containers/IBM-interview.md +++ b/projects/confidential-containers/IBM-interview.md @@ -13,7 +13,7 @@ since then. #### 2. What were the main motivations to adopt the project and which key features do you use today? -From my point of view this is the most mature CNCF project in this area and has key industry participants contributing and collaborating. We primarly use the s390x and IBM Secure Execution for Linux versions of the project as well as the +From my point of view this is the most mature CNCF project in this area and has key industry participants contributing and collaborating. We primarily use the s390x and IBM Secure Execution for Linux versions of the project as well as the Trustee component. #### 3. Compared with other products and projects in this space (proprietary and open) what drew you to the project? @@ -76,7 +76,7 @@ As stated, the contributions from so many participants across the industry and t #### 14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. -We intend to contribute, request features for different solutions, improved user experience, and plan to continue our involvement as products depend on this project and the underlaying technology. +We intend to contribute, request features for different solutions, improved user experience, and plan to continue our involvement as products depend on this project and the underlying technology. --- ## Maturity Level Survey diff --git a/projects/confidential-containers/confidential-containers-incubation-dd.md b/projects/confidential-containers/confidential-containers-incubation-dd.md index 6f731a075..24893b1d5 100644 --- a/projects/confidential-containers/confidential-containers-incubation-dd.md +++ b/projects/confidential-containers/confidential-containers-incubation-dd.md @@ -104,7 +104,7 @@ Note: this section may be augmented by the completion of a Governance Review fro The [project governance doc](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md) is maintained in the main repository. - Since CoCo has 10+ active non-fork repos, TOC reviewers suggest to consider creating a community repository and maintain governance and community relavent docs there. + Since CoCo has 10+ active non-fork repos, TOC reviewers suggest to consider creating a community repository and maintain governance and community relevant docs there. - [x] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** @@ -275,7 +275,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - short-term roadmap at the GitHub boards (including the [Confidential containers github board](https://github.com/orgs/confidential-containers/projects/6) and [Trustee github board](https://github.com/orgs/confidential-containers/projects/10)), and - its mid/long-term roadmap at the project's website based on use-case driven development. Ref: - The short-term roadmap Confidential containers github board link is unavailable with an outdated "view", needs to be fixed. Ref: + The short-term roadmap Confidential Containers GitHub board link is unavailable with an outdated "view", needs to be fixed. Ref: - [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. _This requirement may also be satisfied by completing a General Technical Review._** - The General Technical Review was updated on 24-Feb-2026 (currently under review), and can be discovered at . @@ -356,11 +356,11 @@ The list of adopters can be found in the project repo: https://github.com/confid - [x] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** -The project provided the TOC with a list of adopters for verification of use of the project at the level expected, dev/test for incubation. The TOC was able to verify confirm at least dev/test use with all interviewed adopters. +The project provided the TOC with a list of adopters for verification of use of the project at the level expected, dev/test for incubation. The TOC was able to confirm at least dev/test use with all interviewed adopters. - [x] **TOC verification of adopters.** -The CoC maintainers provided the TOC with a list of 5-6 adopters who agreed to be interviewed for the Incubation Due Diligence process. 4 of these adopters were interviewed. The adoption portion of this document contains interview summaries from adopters who approved public attribution. All adopters are verified using CoC at the level appropriate for incubation. +The CoCo maintainers provided the TOC with a list of 5-6 adopters who agreed to be interviewed for the Incubation Due Diligence process. 4 of these adopters were interviewed. The adoption portion of this document contains interview summaries from adopters who approved public attribution. All adopters are verified using CoCo at the level appropriate for incubation. Refer to the Adoption portion of this document. From 19fbb7bd1dc3020beb8f4187c0428816aab93bcf Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Thu, 18 Jun 2026 00:15:30 +0800 Subject: [PATCH 9/9] update CoCo incubation DD, refine subproject governance relevant wording Signed-off-by: Kevin Wang --- .../confidential-containers-incubation-dd.md | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/projects/confidential-containers/confidential-containers-incubation-dd.md b/projects/confidential-containers/confidential-containers-incubation-dd.md index 24893b1d5..ade7fb673 100644 --- a/projects/confidential-containers/confidential-containers-incubation-dd.md +++ b/projects/confidential-containers/confidential-containers-incubation-dd.md @@ -29,7 +29,7 @@ Kevin Wang, Faseela K, and Lin Sun conducted the due diligence of Confidential C - **Publish a public maintainer and team-membership list**: Maintainer and functional-role assignments are managed through private GitHub teams referenced in `CODEOWNERS`, so they are not publicly readable. The TOC reviewers recommend publishing this membership through declarative configuration using a tool such as [cilium/team-manager](https://github.com/cilium/team-manager) or [CLOWarden](https://github.com/cncf/clowarden). - **State vendor neutrality explicitly in governance**: Vendor neutrality is enforced through the two-seat-per-organization Steering Committee limit, but the governance documents do not state it as a principle. The reviewers recommend adding a vendor-neutrality clause before graduation. -- **Move governance and community docs into a community repository**: With 10+ active non-fork repositories, the reviewers suggest a dedicated community repository to hold governance and community documentation. +- **State governance scope across the org**: The `confidential-containers/confidential-containers` repository serves as the de-facto community repository, but the governance does not explicitly state that it applies to all repositories under the `confidential-containers` GitHub organization. The reviewers recommend adding a short scope statement to `governance.md` so contributors landing in a subproject repository can tell which document governs it. - **Document subproject governance details**: The subproject removal process, per-subproject maturity status, and a public per-subproject maintainer list are not yet documented and should be completed before graduation. - **Integrate with the official CNCF calendar**: Weekly community meetings are documented in a public Google Doc; adding them to the official CNCF calendar would make them easier to find. - **Keep the contributing guide current**: The contributing guide has not been updated since 2024 and should be reviewed periodically to match the current state of the project. @@ -102,9 +102,9 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Clear and discoverable project governance documentation.** - The [project governance doc](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md) is maintained in the main repository. + The [project governance doc](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md) is maintained in the main repository, which serves as the de-facto community repository for the org. - Since CoCo has 10+ active non-fork repos, TOC reviewers suggest to consider creating a community repository and maintain governance and community relevant docs there. + With 10+ active non-fork subproject repositories under the org, the TOC reviewers recommend stating the scope of the governance explicitly in `governance.md` (for example, that it applies to all repositories under the `confidential-containers` GitHub organization unless a subproject documents an explicit deviation), so contributors landing in a subproject repository can tell which document governs it. - [x] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** @@ -148,12 +148,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** - Subproject leadership and contribution follow the organization-level [governance](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md). - - The TOC reviewers note that the following subproject governance details are not yet documented and recommend completing them before graduation: - - The subproject removal process. - - The maturity status of individual subprojects. - - A public per-subproject maintainer list. + The org-level [governance](https://github.com/confidential-containers/confidential-containers/blob/main/governance.md) refers to subprojects as "projects" (Trustee, guest-components, cloud-api-adaptor, operator, td-shim, etc.), and documents Maintainer onboarding and removal for each, which covers subproject leadership and contribution. Still missing before graduation: how to add or retire a subproject, the maturity status of each, and a public per-subproject maintainer list. ### Required