From f8a3cdccccc2405edcaad3814466e7d6abfa856a Mon Sep 17 00:00:00 2001 From: Ricardo Aravena Date: Fri, 6 Dec 2024 14:35:54 -0800 Subject: [PATCH 01/60] Update runtime-charter.md Signed-off-by: Ricardo Aravena Signed-off-by: Ricardo Aravena Signed-off-by: Lin Sun --- tags/tag-charters/runtime-charter.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/tags/tag-charters/runtime-charter.md b/tags/tag-charters/runtime-charter.md index f80c42588..4410b658a 100644 --- a/tags/tag-charters/runtime-charter.md +++ b/tags/tag-charters/runtime-charter.md @@ -9,6 +9,7 @@ Also reviewed and contributed to by: * Liz Rice * Brian Grant +* Ricardo Aravena ## Introduction @@ -70,9 +71,7 @@ Specific TAG deliverables are as per the above, and the [general TAG responsibil set out by the CNCF TOC](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#responsibilities--empowerment-of-tags). -## Current CNCF Projects considered to be within the Scope of this SIG - - +## Current CNCF Projects considered to be within the Scope of this TAG 1. Kubernetes 2. Containerd @@ -134,12 +133,15 @@ provided by the TOC unless otherwise stated here. **TOC Liaisons:** [Richardo Rocha](https://twitter.com/ahcorporto), [Alena Prokharchyk](https://github.com/alena1108), [Davanum Srinivas](https://twitter.com/dims) -**SIG Chairs:** - [Quinton Hoole](https://github.com/quinton-hoole), +**TAG Chairs:** + [Danielle Tal](https://github.com/miao0miao), [Ricardo Aravena](https://github.com/raravena80), - [Diane Feddema](https://github.com/dfeddema) + [Stephen Rust](https://github.com/srust) -**Tech Leads:** [Klaus Ma](http://www.klaus1982.cn/about/), 2 TBD +**Tech Leads:** + [Rajas Kakodkar](https://github.com/rajaskakodkar) + [Klaus Ma](http://www.klaus1982.cn/about/) + [Alexander Kanevskiy](https://github.com/kad) **Other named roles: **None at present; will be identified and staffed as needed. From a7de8aab061d58f4c99252dc35c327f327e1f94c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Mon, 9 Dec 2024 16:18:07 -0500 Subject: [PATCH 02/60] add an adopter interview Signed-off-by: Lin Sun --- .../in-toto-adopter-interview-chainguard.md | 0 .../in-toto-adopter-interview-github.md | 92 +++++++++++++++++++ ...-toto-adopter-interview-lockheedmartins.md | 0 projects/in-toto/in-toto-graduation-dd.md | 0 4 files changed, 92 insertions(+) create mode 100644 projects/in-toto/in-toto-adopter-interview-chainguard.md create mode 100644 projects/in-toto/in-toto-adopter-interview-github.md create mode 100644 projects/in-toto/in-toto-adopter-interview-lockheedmartins.md create mode 100644 projects/in-toto/in-toto-graduation-dd.md diff --git a/projects/in-toto/in-toto-adopter-interview-chainguard.md b/projects/in-toto/in-toto-adopter-interview-chainguard.md new file mode 100644 index 000000000..e69de29bb diff --git a/projects/in-toto/in-toto-adopter-interview-github.md b/projects/in-toto/in-toto-adopter-interview-github.md new file mode 100644 index 000000000..51f6e1a6b --- /dev/null +++ b/projects/in-toto/in-toto-adopter-interview-github.md @@ -0,0 +1,92 @@ +# In-toto Adopter Interview - GitHub +Interviewee: Zach Steindler, Principal Eng at GitHub +Interview date: Oct 7, 2024 + +## Organization Intro + +### Can you give us an overview of your organization and what it does? + +GitHub is a website where people work on code together. Very popular in OSS for people to share code and build artifacts. Also used widely by enterprise. + +## Motivation + +### Compared with other products in this space (proprietary and open), what drew you to the project? + +There are primiarly 2 things that drew us to the project: + +- We started using in-toto when we added build provenance. In-toto collects source projects to write specifications. +- In-toto use cases were attractive to us. There aren’t really other projects out there as an alternative that has lots of other projects using it. + +## Usage Scenario + +### How does your organization use the project and how long have you used it? + +GitHub owns npm, we released npm provenance in 2022 which uses in-toto. We use the in-toto framework to create publish attestation. Last year we released github artifact attestation, so anything you build with github can have build provenance. We also use SBOM and use in-toto to represent it. + +### What version is used and what is your update cadence with the project? + +We maintain our own version of custom predicate. We are currently up-to-date and we update as needed. + +### 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? + +It has been pretty smooth. There are docs around how to produce custom predicates. There are docs on how to produce build provenance. Libraries are relatively straightforward to use. Can’t think of any challenges we had! + +### Did you find the information in the repo valuable to your implementation? What specifically? + +Yes! Pretty good docs for in-toto attestation repo, SLSA(Supply Chain level for software artifacts) repo, very good repo. + +### Has your implementation of the project provided measurable value? + +Tens of thousands of people make use of npm provenance and github artifact attestation. + +### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +Yes! For GitHub releases, we plan to make it immutable by leveraging in-toto attestation. Besides that, nothing concrete. We always keeping track of new attestation released from in-toto. + +## Perception + +### What is your perception in terms of the project’s: + +#### Community openness + +Very open, I participated in the slack channel in CNCF, and have created issues/PRs that have been resolved. + +#### Governance + +Don’t think I attended any meeting. Some of the PRs have been reviewed by the Governance/steering committee, they were prompt and thorough in review. + +#### Community growth potential + +Could be biased, we are definitely invested in the ecosystem and believe in the growth of it. + +#### Maintainer diversity and ladder + +Multiple Xs of diversity. There is some diversity in terms of gender and people’s background (industry & academic & non profit OSS foundation). + +#### Maintainer response + +Couple of PRs made by me were handled well. Things are resolved in a reasonable amount of time. + +### How are you participating in the project community? + +Yes but not recently. About 6 months ago, I attended some community meetings and submitted PRs. + +### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome? + +So far, I have good experience with PRs. + +## Project Strengths + +### In your opinion, what are the overall strengths of the project? + +Community discussions are great and how they bring them (industry & academic & non profit OSS foundation). Really thinking ahead and anticipating needs before people need them. Continue to be an active community. + +## Project Improvements + +### Is there something you feel that holds the project back from reaching its ultimate potential? + +Not really. Struggle to come up with an answer. Only worry is if there are lots of layoffs, would people have time to contribute in-toto? + +### In your opinion, what can the project do better? + +Continue to think about where the industry is headed and anticipate the needs. They have demonstrated the ability to do so so far. diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md new file mode 100644 index 000000000..e69de29bb diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md new file mode 100644 index 000000000..e69de29bb From a3373ce56a7004c9c188a9d6607a38c65e62464d Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Mon, 9 Dec 2024 22:43:13 -0500 Subject: [PATCH 03/60] DD doc Signed-off-by: Lin Sun --- .../in-toto-adopter-interview-github.md | 1 + ...-toto-adopter-interview-lockheedmartins.md | 107 ++++++ projects/in-toto/in-toto-graduation-dd.md | 323 ++++++++++++++++++ 3 files changed, 431 insertions(+) diff --git a/projects/in-toto/in-toto-adopter-interview-github.md b/projects/in-toto/in-toto-adopter-interview-github.md index 51f6e1a6b..90e5a9657 100644 --- a/projects/in-toto/in-toto-adopter-interview-github.md +++ b/projects/in-toto/in-toto-adopter-interview-github.md @@ -1,4 +1,5 @@ # In-toto Adopter Interview - GitHub + Interviewee: Zach Steindler, Principal Eng at GitHub Interview date: Oct 7, 2024 diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md index e69de29bb..23320ab41 100644 --- a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md +++ b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md @@ -0,0 +1,107 @@ +# In-toto Adopter Interview - GitHub + +Interviewee: Ian Dunbar-hall, Head of Open Source Program Office, Lockheed Martins +Interview date: Sept 3, 2024 + +## Organization Intro + +### Can you give us an overview of your organization and what it does? + +[Lockheed Martins](https://www.lockheedmartin.com/en-us/contact.html) is a leading aerospace and defense company. + +## Motivation + +### Compared with other products in this space (proprietary and open), what drew you to the project? + +I recall it was at KubeCon either 2020 or 2021, and I went to the contribfest for the in-toto project. The project solves a foundational need in our space, securing software supply chain, which is very critical to our customers for delivering high quality products. Without it, it has resulted in very bad outcomes, Solarwinds, or Crowdstrike incidents, for example. + +## Usage Scenario + +### How does your organization use the project and how long have you used it? + +For the in-toto specification, we don’t directly work with specification but consume it as part of libraries. + +For the in-toto subprojects (application or libraries), we started to use the libraries in our OSS projects in Jan 2023. We have also incorporated in-toto attestation for corporate networks for any OSS projects that come to internal & external use. Basically any time when we consume any OSS projects, we check on the following: +- Is the OSS project approved for use in our company? +- How do we know if someone maliciously modified it in the corporate network? +- Can we still adopting it for products we are delivering to our customers? + +### What version is used and what is your update cadence with the project? + +We update the libraries fairly regularly, whenever any core library gets updated. +Specification changes are also adopted as part of the library update. We don’t implement the spec ourselves. + +### 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? + +Overall, a really positive experience! +- Well organized oss projects, very strong community behind it. +- Very large enterprises and universities are involved. Easy to get support. +- Well beyond community compared with other graduated projects. +- We also contributed some PR and got good feedback/reviews. Testify donated a subproject under in-toto (command line client to create attestation) and we use it to create attestation for everything. +- Lots of end users and vendors. + +### Did you find the information in the repo valuable to your implementation? What specifically? + +Yes, without a ton of background, we were able to quickly incorporate the in-toto python libraries. Slack/community meetings are both helpful. Easy to get technical recommendations. Docs are quite good for such a complex problem. + +### Has your implementation of the project provided measurable value? + +Yes. The in-toto capabilities in our products were demo-ed frequently. We are writing a white paper around how to use in-toto across public sectors for supply chain security via the public sector of the CNCF end user groups. + +### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +- Need to drive more adoptions within the company. +- We are working on the SBOMit project within OpenSSF, which is built on top of in-toto: + * https://github.com/sbomit/specification + * [Bomctl](https://github.com/bomctl/bomctl) will be announced as a sandbox project as part of OpenSSF this thurs which also uses in-toto. + +## Perception + +### What is your perception in terms of the project’s: + +#### Community openness + +Very active community, weekly meeting for some part of the in-toto ecosystem. Variety of the people involved speak very well for the project. + +#### Governance + +Steering committee was formed and a lot of people involved know the spec well, a good technical community. + +#### Community growth potential + +Good growth and expansion. + +#### Maintainer diversity and ladder + +Totally see this growing. + +#### Maintainer response + +Nothing but quick response and feedback. + +### How are you participating in the project community? + +We have done in-toto related talks at CloudNativeSecurityCon, OpenSource Summit etc. We are pretty active in the community, being on the community calls. We are also maintaining a few other projects which are built on top of in-toto. + +### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome? + +A variety of reasons. My first one was a first time in-toto user and then I wanted to incorporate in-toto in our OSS tool, and a few other minor contributions. All were addressed timely with good feedback. Really good experience which led me to be more deeply involved. + +## Project Strengths + +### In your opinion, what are the overall strengths of the project? + +Beyond the community, and diversity of others using it, the spec is also very flexible. You can add to it, or expand it or create a unique solution with it. + +## Project Improvements + +### Is there something you feel that holds the project back from reaching its ultimate potential? + +Growing the list of attestation types of in-toto will strengthen the project more. For example, adding an OSS program approval. + +### In your opinion, what can the project do better? + +- Has done a really good job of getting people using in-toto and sometimes people don’t really realize they are using it. + * [SLSA](https://slsa.dev/) is built on top of in-toto, which is very well known. Yet people don’t realize it. + +- Needs more marketing or branding because people don’t realize it as much as they are using it. diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index e69de29bb..ddac54040 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -0,0 +1,323 @@ +# In-toto Graduation Due Diligence + +- [In-toto graduation application issue](https://github.com/cncf/toc/pull/1162/) + +Project Repo(s): http://github.com/in-toto +Project Site: https://in-toto.io/ +Communication: #in-toto on CNCF Slack Workspace + +Project points of contacts: Santiago Torres, santiagotorres@purdue.edu + +## Graduation Criteria Summary for In-toto + +### Criteria Evaluation + +Lin Sun (@linsun) conducted the due diligence of in-toto who applied for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: + +- A notable stable project with mature capabilities and a wide [adopter](https://github.com/in-toto/friends?tab=readme-ov-file#project-adopters) base. +- The project has a wide range of interest across academic and cross different industries. +- The project [integrates](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations) with various other projects in the cloud native ecosystem such as GitHub, GitLab, GUAC, Tekton, etc. +- Implementation of the steering committee to capture adopters' voice in the project development and roadmap. +- The project is not only vendor neutral but also has a very diversed set of maintainers, adopters and integrators. +- The project does an excellent job of making sure that its public meetings are accessible, with notes, and easy to find meeting links. + +The following actions were provided to the project that were considered blocking but have since been resolved: + +- Enable convenient linkage for community meeting notes. +- Updating the list of subprojects in GitHub, found from the Governancy review. +- Provide an updated roadmap document in GitHub. + +### Final Assessment + +The TOC has found the project to have satisfied the criteria for Graduation. + +### Adoption Assertion + +### Criteria + +## Application Process Principles + +### Suggested + +N/A + +### Required + +- [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** + +Presentation was given to the TAG security in July 2014. + +- [x] **TAG provides insight/recommendation of the project in the context of the landscape** + +[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation + +- [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + +Don't see any concern with vendor-neutral for in-toto project. + +- [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** + - [x] Met during Project's application on 21-06-2024. + +Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria. + +- [X] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** + +Docs are available at https://in-toto.readthedocs.io/en/latest/index.html which includes install, API, code sample, and how to contribute etc. + +## Governance and Maintainers + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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.** + +[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. + +### Required + +- [X] **Clear and discoverable project governance documentation.** + +Able to find it easily. + +- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** + +TODO: need some work here. + +- [X] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** + +Vendor neutral is clearly mentioned twice in the governance doc. Steering committee composition is also diverse at the moment. + +- [x] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** + +Documented [here](https://github.com/in-toto/community/tree/main/elections) + +- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** + +[GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. + +- [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** + +[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) + +- [x] **A number of active maintainers which is appropriate to the size and scope of the project.** + +- [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** + +The project maintains a description of different roles and their election process in its [community repository](https://github.com/in-toto/community) + +- [x] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** + +Maintainers for subprojects have been managed by the ITSC and Sub-project maintainers as pull-requests to their corresponding MAINTAINERS.txt files (e.g., [[1, self nomination](https://github.com/in-toto/in-toto-rs/pull/89)],[[2, stepping down](https://github.com/in-toto/attestation/pull/406)],[[3, community nomination](https://github.com/in-toto/witness/pull/385)]). + +- [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** + +As an intentionally minimal security specification / framework, we deliberately do not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). + +Since reaching the incubation stage, the in-toto project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across our sub-projects, we have contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. + +The current ITSC comprises of the following +- Santiago Torres-Arias (Purdue University) +- Justin Cappos (New York University) +- Jack Kelly (Control Plane) +- Cole Kennedy (TestifySec) +- Trishank Karthik Kuppusamy (Datadog) + +We have had active contributions from an array of contributors across the CNCF landscape. One way to see this is via the substantial changes that made their way into the specification. + +Changes to the in-toto standard largely come in the form of ITEs (in-toto enhancements). There is a substantial ITE, ITE-4, that standardized non-file artifact specifications for in-toto metadata. The stakeholders in it are Github, Conda, SPDX and Google's Grafeas. + +Another significant ITE is [ITE-6](https://github.com/in-toto/ITE/blob/master/ITE/6/README.adoc). This enhancement introduced the in-toto Attestation Framework to record and disseminate software supply chain specific information like build provenance, code review results, test results, SBOMs, vulnerability scans, and more. in-toto attestations are now used by GitHub for NPM build provenance, OpenVEX, Docker buildx, scanners like Trivy that can generate signed SBOMs, Tekton Chains, Sigstore, GUAC, Witness, and Archivista. SolarWinds, in their next generated build system introduced after SUNBURST, also generate in-toto attestations. + +- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** + +TODO + +- [x] **Document agreement that project will adopt CNCF Code of Conduct.** +- [x] **CNCF Code of Conduct is cross-linked from other governance documents.** + +The CoC and the assertion of adherence is referenced in the [GOVERNANCE.md](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#code-of-conduct). + +- [x] **All subprojects, if any, are listed.** + +Subprojects are listed in the [README.md](https://github.com/in-toto/community/blob/main/README.md#subprojects) file of in-toto/community. + +- [x] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** + +Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee. + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### Suggested + +- [x] **Contributor ladder with multiple roles for contributors.** + +The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) + +### Required + +- [x] **Clearly defined and discoverable process to submit issues or changes.** + +A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. + +- [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** + +Communication channels are encoded in the [website](https://in-toto.io/contact/). It contains a developer facing mailing list, a public mailng list, a slack join link, github and IRC contacts. + +- [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.** + +Communication channels are encoded in the [website](https://in-toto.io/contact/) + +- [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** + +in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). + +- [x] **Documentation of how to contribute, with increasing detail as the project matures.** + +A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) + +- [ ] **Demonstrate contributor activity and recruitment.** + + + +## Engineering Principles + +- [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.** + +One of the most pressing security problems in cloud native is software supply chain security. in-toto addresses this issue by providing a secure and trustworthy means for representing all the operations within the cloud-native pipeline and verifying that they were carried out to the letter. +A good way to understand the need for in-toto in the Cloud Native space is to understand the value of signed SBOMs vs in-toto metadata + layouts. A signed SBOM indicates that some party (whose key you presumably have a reason to trust) states what the software contains. In contrast, in-toto will have signed information about the individual steps of the supply chain cryptographically linking metadata together from various parties and validating this all against the software’s policies. As a result, their protection modes would work quite differently in many cases. For example, see the following table: + + +| Attack scenario | Signed SBOM Result | In-toto layout + metadata result | +|-----------------|----------------------|----------------------------------| +| Software manipulated after software supply chain completed | Detect and reject the malicious software | Detect and reject the malicious software | +| Attacker compromises VCS and inserts malicious (unsigned) code where signatures are required |Undetected. User compromised. | Detect and reject the malicious software | +| Attacker substitutes a malicious dependency (not signed by that dependeny’s maintainer) |Undetected. User compromised. | Detect and reject the malicious software +| Attacker provides files to the build system which did not come from the VCS | Undetected. User compromised | Detect and reject the malicious software | +| Attacker containerizes / packages binaries other than the ones the build system built | Undetected. User compromised | Detect and reject the malicious software | +| Tests are not run on the software but it is (accidentally?) released to production | Undetected. User compromised | Detect and reject the malicious software | +| The legal team has not reviewed source code licenses for included libraries | Undetected. Impact varies | Detect and reject the software | + +One important thing to note about the table above is that it isn’t impossible for someone to do many of these steps and checks before signing an SBOM. If you did all of these checks, and signed the statements saying you did them to provide stronger validation, and distributed the root of trust for your signatures in a secure way, and managed situations where signing keys need to be revoked / rotated / expired, and handled trust delegation to different parties, and linked metadata between steps together, and let people write policies to reason about those steps, and let them link metadata in from dependencies to do so, and handled all of the above in scenarios where insiders can be maliciously interfering with your, system, then you would effectively reconstruct in-toto. +We are aware of some efforts, like the Zephyr project, where project members have worked to try to reconstruct some of the guarantees of in-toto and decided to live with the gaps in their security for other portions. For groups that have done this work already this does make sense to us as a viable alternative in the short term. However, we do believe that using a common, holistic approach like in-toto will be necessary as projects continually add the missing security pieces from in-toto and want to reason more and more about each other as dependencies. + +Note that in-toto is not a substitute for having appropriately secure steps in the software supply chain. For example, if you use an insecure process of building software that just curls and builds software from a website, in-toto will happily sign metadata indicating that you did the same insecure action indicated you would. + +This is why projects like SLSA and FRSCA are built as an opinionated set of steps on top of in-toto. They specify which actions they feel are more important for software supply chain security and mandate their use. + +These projects are solving different problems at different levels. In-toto allows you to capture information about your steps, ensure policies about them are applied, handle trust of keys, etc. Frameworks like SLSA and FRSCA use in-toto as a mechanism to capture and enforce a specific set of policies that result in more secure supply chains. + +- [x] **Document what the project does, and why it does it - including viable cloud native use cases.** + +https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and many integrations with other projects in the ecosystem. + +- [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** + +Roadmap for project with pointers to subproject ROADMAPs are encoded in a [ROADMAP.md file](https://github.com/in-toto/community/blob/main/ROADMAP.md) + +- [x] **Roadmap change process is documented.** + +Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/ROADMAP.md) outlines how and when the community-wide rodamap is updated (usually once a year). Each sub-project may also have their own ROADMAP that aligns to subproject-wide SLAs + +- [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** + +The [friends](https://github.com/in-toto/friends) repository outlines how Cloud-native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud-native CI/CD platforms, as well as social coding platforms and distributed buildsystems. + +- [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** + + - [x] Release expectations (scheduled or based on feature implementation) + - [x] Tagging as stable, unstable, and security related releases + - [ ] Information on branch and tag strategies + - [ ] Branch and platform support and length of support + - [x] Artifacts included in the release. + - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. + +in-toto has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. + +All implementations follow semver to communicate their feature support, as well as backwards and forwards compatiblity. + +- [x] **History of regular, quality releases.** + +A history of releases is [kept on our changelog](https://github.com/in-toto/in-toto/blob/develop/CHANGELOG.md) + +## Security + +Note: this section may be augemented by a joint-assessment performed by TAG Security. + +### Suggested + +- [x] **Achieving OpenSSF Best Practices silver or gold badge.** + +[in-toto achieves a gold OpenSSF Best Practice badge](https://www.bestpractices.dev/en/projects/1523?criteria_level=2) + +### Required + +- [x] **Clearly defined and discoverable process to report security issues.** + +Repositories describe the disclosure process using a [SECURITY.md file](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) + + +- [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** + +GitHub teams are used to provide granular access to different repositories within the organization. Protected branches are used to avoid pushes to master. Dependabot, and secret scanning is also added to all implementation repositories. + +- [x] **Document assignment of security response roles and how reports are handled.** + +Disclosure is handled by the ITSC. In addition, GitHub private vulnerability reporting is used (and has been successfully used before) to handle disclosures on implementations. + +- [x] **Document Security Self-Assessment.** + +in-toto was the [first project to carry out a security self-assessment](https://github.com/cncf/tag-security/commit/06b71c4db99ba07107cba6cf8f6fc6d4461fce82) with TAG security, and aided in developing the current process. + +- [x] **Third Party Security Review.** + +See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). + +- [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** + +The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). As of 31st of July, 2023, there are only 23 projects in the world to have such a distinction. The only other CNCF project with a Gold Badge is the [TUF project (a graduated security project)](http://theupdateframework.io). + +According to the OpenSSF Best Practices website, the in-toto project received its initial OpenSSF Best Practices badge on January 5th, 2018. + +## Ecosystem + +### Suggested + +N/A + +### Required + +- [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** + +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends) + +- [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)** + +Many adopters and integrations are [documented](https://github.com/in-toto/friends). + +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. + +- [x] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** + +Many integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). + +#### Adoption + +##### Adopter 1 - Lockheed Martins/Aerospace and defense company + +This adopter interview is performed in Sept 2024 and recorded a very happy adopter who also contributes to the in-toto project. Refer to the [interview summary](in-toto-adopter-interview-lockheedmartins.md) for more details. + +##### Adopter 2 - GitHub/Software company + +This adopter interview is performed in Oct 2024 and recorded a very adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. + +##### Adopter 3 - $COMPANY/$INDUSTRY + +_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ +MONTH YEAR \ No newline at end of file From 85a5ee549069ba88e50266a1776f12afed3425fc Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 12 Dec 2024 21:58:14 -0500 Subject: [PATCH 04/60] add chainguard interview Signed-off-by: Lin Sun --- .../in-toto-adopter-interview-chainguard.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/projects/in-toto/in-toto-adopter-interview-chainguard.md b/projects/in-toto/in-toto-adopter-interview-chainguard.md index e69de29bb..f97154303 100644 --- a/projects/in-toto/in-toto-adopter-interview-chainguard.md +++ b/projects/in-toto/in-toto-adopter-interview-chainguard.md @@ -0,0 +1,80 @@ +# In-toto Adopter Interview - Chainguard + +Interviewee: Billy Lynch, Staff Software Engineer at Chainguard +Interview date: Dec 12, 2024 + +## Organization Intro + +Chainguard is the safe source for open source, so everything we produce includes supply chain metadata like signatures, attestations, SBOMs, etc - in-toto is foundational spec for how we represent much of that data. + +## How long has your organization used the project? +Before I joined Chainguard, I was involved with in-toto as an attestation framework in various different projects (SLSA, Sigstore). I met many of the Chainguard founders through these open source projects and when I joined we continued to make heavy use of those projects, and as a result in-toto as well. We are heavy users of in-toto today, mostly the attestation spec. + +## What were the main motivations to adopt the project and which key features do you use today? + +The key feature is primarily the attestation format (e.g. the envelope and statement specs). In-toto provides a common format to describe attestation metadata like SBOMs and SLSA provenance so it is a nice and important compatibility layer for us. +In-toto also makes it easy for us to develop our own attestation predicates as well - this allows us to provide additional attestation data specific to how our images are built. + +## Compared with other products and projects in this space (proprietary and open) what drew you to the project? + +We were already working with the adjacent ecosystems (e.g. Sigstore, SLSA), so we wanted to stay in-line with the ecosystems we were already working with - in-toto was a natural choice for us. + +## What is the current level of usage (pre-production, production) and scale? + +We currently have over 1000 images in our catalog - we publish attestations for every image we produce which include SLSA provenance, SBOMs, and our own attestation predicate. + +## What version of the project is currently in use and what is your update cadence with the project? + +Because we were early adopters, we are still using the pre-v1 format, but I don't believe there has been much change from pre-v1 to v1 for the pieces we are using. If anything this shows that the spec has been fairly stable. :) +We can likely update to v1, but there hasn't been a strong driving force for it at the moment. + +## 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? + +What was really nice about in-toto attestations are the existing specs and examples users can see in the repo. These are really useful for us to see what types of metadata users already exist so we don't need to reinvent the wheel. And if the existing specs don’t fit our needs, we can define our own predicate format but still be compatible with the rest of the in-toto attestation spec. + +We've used this for our own images to define an image configuration attestation, which is similar to an SBOM but contains more information about how exactly we built an image. We were able to build this on top of in-toto’s existing format which is very powerful. + +Re challenges: Not specific to in-toto, but one of the challenges in the broader ecosystem is predicate fragmentation (e.g. what kind of SBOM predicate to use). I like that in-toto doesn't try to be the one-standard-to-rule-them-all, but gives us basic building blocks to define common concepts and is flexible enough to allow different predicates and easy extensions. There are many adjacent projects working to solve these problems, and it's something we keep an eye on. + +## 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 spec doc in the attestation repo is very thorough! Love the examples and the detailed spec definitions. Overall the docs are very useful and helpful. + +## 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? + +Pre-Chainguard, I was helping work on the SLSA build provenance format, which often had discussions with the in-toto community for the best way to define the spec in a way that was complementary to the rest of in-toto. These conversations often happened on slack (k8s or openssf) or conferences like KubeCon or OSSummit. +We still work with the maintainers today across various projects in the ecosystem - It's been great to work with all the maintainers, both on in-toto but also adjacent projects as well! + +We still work with the maintainers today across various projects in the ecosystem - It's been great to work with all the maintainers, both on in-toto but also adjacent projects as well! + +## 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. + +SBOM and attestations have increasingly become table stakes, particularly for users in regulated environments. Having standard ways to lay out this information with the artifacts we produce is very useful to us. This helps improve the supply chain security for our users by enabling transparency into our artifacts. + +## 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? + +Because the spec already exists, even if the maintenance stops, the spec is still there for us to use. The existing spec has been fairly stable for us, and we don't anticipate that changing. + +In the event there did need to be a V2 version of the spec, we would likely be interested in being involved to help shape that spec, or at the very least keeping an eye on things and be part of the community. + +## Is there something you feel that holds the project back from reaching its ultimate potential? + +In many ways, I like where the project is today, at least for attestations. It serves as a common baseline and doesn’t try to be too prescriptive about predicates. + +There are complementary projects that are often intertwined with in-toto such as DSSE (Dead Simple Signing Envelope) and SLSA, but are different enough that I'm fine with them being independent and letting them grow separately. Similar groups of maintainers often contribute across these various projects, so there's been a strong ecosystem behind them making sure they work together well. + +## In your opinion, what could the project improve? + +More examples in the wild are always appreciated! In the attestation repo, there are folders detailing all the common predicates, these are super interesting to look at and check out how others are using in-toto. + +## What are the overall strengths of the project? + +In-toto helps define the fundamentals for attestations, but they aren't too prescriptive about exact predicate formats and what data needs to be included. This helps give a common baseline for supply chain metadata, but still gives the flexibility for projects and companies to define their own custom types to fit their needs. + +It's also been great to see the cross-industry and academic collaboration for in-toto and other related projects - it's a large community effort. + +## Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +Honestly, I'm fairly happy with where things are! I'm sure there will continue to be discussions about various predicate types and the best ways to represent supply chain attestation data, but that isn't necessarily specific to in-toto. + +There may be more predicate types we end up using, or creating ourselves in the future! From 0715ea5f4fd9330f5f391827395d652d295f9da5 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 12 Dec 2024 22:00:32 -0500 Subject: [PATCH 05/60] add 3rd adopter Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index ddac54040..7f38d05be 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -299,7 +299,7 @@ Many adopters and integrations are [documented](https://github.com/in-toto/frien 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.** +- [x] **TOC verification of adopters.** Refer to the Adoption portion of this document. @@ -315,9 +315,8 @@ This adopter interview is performed in Sept 2024 and recorded a very happy adopt ##### Adopter 2 - GitHub/Software company -This adopter interview is performed in Oct 2024 and recorded a very adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. +This adopter interview is performed in Oct 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. ##### Adopter 3 - $COMPANY/$INDUSTRY -_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ -MONTH YEAR \ No newline at end of file +This adopter interview is performed in Dec 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-chainguard.md) for more details. From c77321de4673266f7626405b3f670cc3fee11cd5 Mon Sep 17 00:00:00 2001 From: Emily Fox Date: Thu, 5 Dec 2024 17:01:47 -0500 Subject: [PATCH 06/60] What: GB mtg - Add competencies and DD throughput Why: * it was requested the TOC describe used competencies for their work to better inform candidates * it was requested the TOC explicitly state minimum throughput for Due Diligence This change address the need by: * Adding explicit throughput on line 39 for accountability * Establish initial competencies at line 47 Signed-off-by: Emily Fox Signed-off-by: Lin Sun --- operations/onboarding.md | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/operations/onboarding.md b/operations/onboarding.md index f46e189c9..47f182cbd 100644 --- a/operations/onboarding.md +++ b/operations/onboarding.md @@ -36,12 +36,33 @@ TOC members rotate meeting facilitation as often as we can to ensure the TOC Cha In the course of performing our duties, TOC members are expected to: +* Lead or participate in at least 1 Project Due Diligence that is brought to TOC internal review status + * Some Due Diligence efforts may result in the TOC internal review stating the project is not ready after adopter interviews, these are still considered as meeting this expectation. Lightweight reviews/triage would not. * Be available to field questions and concerns from community members and redirect as needed * While every TOC member is expected to do this, there may be occasions or instances where there is a lot of back and forth and the Chair or Vice Chair will coordinate and provide the response as the central contact * Foster discussion - ask questions, even obvious ones to move the conversation forward or to closure * Bring project and group conflicts that escalate to the TOC level to closure, either through elevating awareness within the TOC for discussions and consensus, direct resolution while keeping the TOC informed, or escalation to the Chair and Vice Chair as appropriate * Participate in meetings, presentations, etc. as needed at KCCN or other events +#### Competencies + +In addition to the expectations defined Composition 6(b)ii and Criteria 6(d) for nomination in the CNCF Charter, TOC members should be prepared to actively employ and mature the following competencies: + +* Leadership (ex. transformational, democratic, servant, and visionary are leadership styles that may be used depending on the situation) +* Deep understanding of cloud native technologies and viability for use +* Effective communication +* Time and task management +* Accountable autonomy +* Context conveyance +* Critical thinking and advanced problem-solving (ex. causal analysis, troubleshooting, logical reasoning) +* Conflict resolution +* Improvement-oriented mindset +* Data-driven decision making +* Open-mindedness +* Market awareness (technical and economic trends and impacts) +* Software engineering methodologies and concepts +* Systems and strategic thinking +* Active listening ### Events and additional meetings @@ -74,7 +95,16 @@ In addition to these meetings, TOC members are expected to meet synchronously or ### Inactivity of a TOC member -If, for any reason, a TOC member is continuously absent without notice, see 6(f)iii, their voting privileges are *suspended* until such time as their consecutive attendance at two meetings. Due to the nature of our work, the inability of a TOC member to cast an *informed* vote (as occurs by meeting attendance *and* involvement in regular engagement as detailed above) penalizes the entire TOC's ability to regularly achieve quorum. If after the 4th absence the TOC is not notified, the TOC Chair with support of CNCF Staff will make an attempt to address the absence with the TOC member. If the Chair and Staff are unsuccessful, the Chair will bring the issue of absence to TOC vote in accordance with z6(f)ii at the next private meeting and provide notice to the Governing Board of the outcome. +If, for any reason, a TOC member is continuously absent without notice, see 6(f)iii, their voting privileges are *suspended* until such time as their consecutive attendance at two meetings. Due to the nature of our work, the inability of a TOC member to cast an *informed* vote (as occurs by meeting attendance *and* involvement in regular engagement as detailed above) penalizes the entire TOC's ability to regularly achieve quorum. If after the 4th absence the TOC is not notified, the TOC Chair with support of CNCF Staff will make an attempt to address the absence with the TOC member. + +If a TOC member is unable to fulfill the committed work and is unable to support due diligence to TOC internal review, that TOC member will be considered inactive, and the TOC Chair, with support of CNCF Staff will attempt to address the lack of progress with the TOC member. + +##### Removal + +If the Chair and Staff are unsuccessful, the Chair will bring the issue of absence or lack of progress to TOC vote in accordance with 6(f)ii at the next private meeting and provide notice to the Governing Board of the outcome. + + +#### Stepping down If, for whatever reason, a TOC member feels they cannot sustain the commitment required of the role, they may proactively notify the TOC Chair or CNCF Staff of their decision to step down. While uncommon, this is entirely reasonable to occur, particularly as lives and careers grow and shift. We thank each TOC member for their time of service to the community, however long or brief it may be. From bb50c61cf5e5d6690adb5248d4e7b7cceb6a2d97 Mon Sep 17 00:00:00 2001 From: Emily Fox Date: Fri, 6 Dec 2024 16:37:21 -0500 Subject: [PATCH 07/60] What: add time period for TOC DD Signed-off-by: Emily Fox Signed-off-by: Lin Sun --- operations/onboarding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/operations/onboarding.md b/operations/onboarding.md index 47f182cbd..426b91557 100644 --- a/operations/onboarding.md +++ b/operations/onboarding.md @@ -36,7 +36,7 @@ TOC members rotate meeting facilitation as often as we can to ensure the TOC Cha In the course of performing our duties, TOC members are expected to: -* Lead or participate in at least 1 Project Due Diligence that is brought to TOC internal review status +* Lead or participate in at least 1 Project Due Diligence per year that is brought to TOC internal review status * Some Due Diligence efforts may result in the TOC internal review stating the project is not ready after adopter interviews, these are still considered as meeting this expectation. Lightweight reviews/triage would not. * Be available to field questions and concerns from community members and redirect as needed * While every TOC member is expected to do this, there may be occasions or instances where there is a lot of back and forth and the Chair or Vice Chair will coordinate and provide the response as the central contact From c893975ffd7ab061d146c6ab805b7728761b331b Mon Sep 17 00:00:00 2001 From: Emily Fox Date: Fri, 6 Dec 2024 16:40:19 -0500 Subject: [PATCH 08/60] What: add @dims@kgamanji & @craigbox 's suggestions Signed-off-by: Emily Fox Signed-off-by: Lin Sun --- operations/onboarding.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/operations/onboarding.md b/operations/onboarding.md index 426b91557..4d6faa213 100644 --- a/operations/onboarding.md +++ b/operations/onboarding.md @@ -49,8 +49,9 @@ In the course of performing our duties, TOC members are expected to: In addition to the expectations defined Composition 6(b)ii and Criteria 6(d) for nomination in the CNCF Charter, TOC members should be prepared to actively employ and mature the following competencies: * Leadership (ex. transformational, democratic, servant, and visionary are leadership styles that may be used depending on the situation) +* Community management for guiding TAGs and projects * Deep understanding of cloud native technologies and viability for use -* Effective communication +* Communication (empathy, inclusivity, effectiveness, action-oriented) * Time and task management * Accountable autonomy * Context conveyance @@ -62,6 +63,7 @@ In addition to the expectations defined Composition 6(b)ii and Criteria 6(d) for * Market awareness (technical and economic trends and impacts) * Software engineering methodologies and concepts * Systems and strategic thinking +* Problem solving through automation-driven approaches * Active listening ### Events and additional meetings From 0eee1ba968f5e3ffa5bca9a25185e6dd35a5d8f4 Mon Sep 17 00:00:00 2001 From: Emily Fox Date: Mon, 9 Dec 2024 14:51:59 -0500 Subject: [PATCH 09/60] What: incorporate @angellk's comments Signed-off-by: Emily Fox Signed-off-by: Lin Sun --- operations/onboarding.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/operations/onboarding.md b/operations/onboarding.md index 4d6faa213..a511ac567 100644 --- a/operations/onboarding.md +++ b/operations/onboarding.md @@ -36,8 +36,9 @@ TOC members rotate meeting facilitation as often as we can to ensure the TOC Cha In the course of performing our duties, TOC members are expected to: -* Lead or participate in at least 1 Project Due Diligence per year that is brought to TOC internal review status - * Some Due Diligence efforts may result in the TOC internal review stating the project is not ready after adopter interviews, these are still considered as meeting this expectation. Lightweight reviews/triage would not. +* Lead or meaninfully contribute to at least 1 Project Due Diligence per year that is brought to TOC internal review status. The TOC Chair or Vice Chair (with support of Staff) will determine if the DD brought forward meets the TOC's DD criteria above and beyond the technical review by the TOC. + * Some Due Diligence efforts may result in the TOC internal review stating the project is not ready after adopter interviews, these are still considered as meeting this expectation as determined by the Chair or Vice Chair. + * Lightweight reviews/triage of DD applications, while also required, do not meet the expectations of leading or participating in a Project DD. * Be available to field questions and concerns from community members and redirect as needed * While every TOC member is expected to do this, there may be occasions or instances where there is a lot of back and forth and the Chair or Vice Chair will coordinate and provide the response as the central contact * Foster discussion - ask questions, even obvious ones to move the conversation forward or to closure From 601a6a9b7e928d4a19172695f595b539a6ca54dc Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Mon, 28 Oct 2024 22:42:26 +0800 Subject: [PATCH 10/60] add CubeFS Graduation DD report Signed-off-by: Kevin Wang Signed-off-by: Lin Sun --- .../cubefs-adopter-interview-beike.md | 116 ++++ .../cubefs-adopter-interview-jd.com.md | 129 +++++ .../cubefs-adopter-interview-netease.md | 132 +++++ projects/chubaofs/cubefs-graduation-dd.md | 499 ++++++++++++++++++ 4 files changed, 876 insertions(+) create mode 100644 projects/chubaofs/cubefs-adopter-interview-beike.md create mode 100644 projects/chubaofs/cubefs-adopter-interview-jd.com.md create mode 100644 projects/chubaofs/cubefs-adopter-interview-netease.md create mode 100644 projects/chubaofs/cubefs-graduation-dd.md diff --git a/projects/chubaofs/cubefs-adopter-interview-beike.md b/projects/chubaofs/cubefs-adopter-interview-beike.md new file mode 100644 index 000000000..3fab50f93 --- /dev/null +++ b/projects/chubaofs/cubefs-adopter-interview-beike.md @@ -0,0 +1,116 @@ +# CubeFS Adopter Interview - BEIKE + +Interview date: Sept. 11th, Wednesday, 2024 +Interviewee: FangRong Lin, Senior Development Engineer, BEIKE; Bin Yan, Senior Development Engineer, BEIKE + +## Organization Intro + +### Can you give us an overview of your organization and what it does? + +Beike is an integrated online and offline platform for housing transactions and services. +Our website offers users browsing of housing information, house photos, etc., and helps users manage transaction information and contracts for houses. +Our team belongs to Beike's private cloud and provides file storage for internal business teams. +Scenarios involving CubeFS include historical data, logs, and cold backups of databases, as well as AI training/inference scenarios. + +## Motivation + +### Compared with other products in this space (proprietary and open), what drew you to the project? + +Due to team changes, we are not familiar with the background information of the previous technical selection. +Based on our current usage, CubeFS demonstrates advantages in overall read/write and concurrency performance, which aligns well with our company's business characteristics. The storage team customizes the system according to the needs of the business team to meet their requirements. + +## Usage Scenario + +### How long has your organization used the project? + +Started in early 2020. CubeFS v2.3 was the first version adopted. + +### What were the main motivations to adopt the project and which key features do you use today? + +We primarily use the triple-replica redundancy feature. CubeFS is easy to scale, which is crucial for us. + +We basically collect and evaluate storage growth requirements from all business teams quarterly. However, the growth rate is unpredictable, making it difficult to forecast storage needs in advance. CubeFS excels in this scenario with its robust scalability, ensuring high standards of data stability. + +### What is the current level of usage (pre-production, production) and scale? + +We are using CubeFS in a large-scale production environment with a total capacity of 30PB (triple-replica redundancy). + +### What version is used and what is your update cadence with the project? + +We are currently using version 3.3.1 with some downstream modifications. Additionally, some legacy environments are still running on version 2.4. We initially used version 2.4 extensively, but later upgraded to 3.3.1 to meet business requirements. + +We don't have a fixed update cadence. But we will upgrade when the community releases particularly attractive features or important bug fixes. + +### 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? + +Our business teams were using NFS previously. Compared to NFS, CubeFS has lower write performance for small files. During the migration from NFS to CubeFS, we faced challenges with the decreased write performance. + +Additionally, the community had provided a tool for writing HDFS data to CubeFS, but it hasn't been maintained for a long time. When we encountered related scenarios during implementation, we faced some issues and received limited support from the community. + +### 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 disk throttling feature has been particularly useful. + +Our team closely follows the community's annual version plans and examines the features in the development branches. For useful features, we implement them in our own version. For example, we implemented metadata support for RocksDB (the community version caches all metadata in memory) and a disk-based distributed cache (the community version is memory-based). + +As for why we have some customized implementations: + +1. The community version does not fully meet our performance requirements, so modifications are necessary for implementation. +2. The community's development cycle is relatively long, and our own release cadence does not align well with the community's plan. + +After our own implementation is launched, we evaluate the actual performance and functionality improvements. If the results are relatively good, we will discuss with the community and try to contribute back to upstream. + +### 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 + +The environment maintenance of CubeFS is relatively convenient. + +Previously, Beike did not build its own storage system and mostly adopted procurement methods. After we adopted CubeFS, many business teams used Beike's self-built solution, which can save costs and make it easier to debug and resolve problems. + +### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc + +We hope to participate in the community's plans in the future. Currently, our team is relatively small, so we will focus on our actual needs and primarily engage with parts of the community that align well with our goals. We aim to communicate and collaborate with the community to drive progress together. + +## Perception + +### What is your perception in terms of the project’s + +- Community openness +- Governance +- Community growth potential +- Maintainer diversity and ladder +- Maintainer response + +The community is quite open and friendly, and questions asked in the WeChat group are well addressed. +However the recent community developments seem slowed down, which is behind the roadmap. +As for community governance, we don’t have much participation. + +### How are you participating in the project community? + +We mainly participate in discussions in the WeChat group and attend the community's monthly meetings. +For valuable commits, we will contribute back to the community. +We also closely follow articles published by the community. + +### 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? + +Our team leader engages with the community, particularly regarding technical selection, initial cluster sizing, and performance estimation. The primary communication channel used is the WeChat group. + +## Project Strengths + +### In your opinion, what are the overall strengths of the project? + +1. Concurrent read and write operations for multiple files. +2. Efficient utilization of overall bandwidth, which can scale with the size of the cluster. + +## Project Improvements + +### Is there something you feel that holds the project back from reaching its ultimate potential? + +1. The management of the git commit history is not very clean. For example, when we are trying to back port a feature, it is hard to find all commits related. +2. We hope some features in the community can be made pluggable, so they do not affect existing functionality. +3. We hope the community can improve compatibility for upgrading historical versions. For instance, when upgrading from version 2.4 to 3.3.1, we encountered significant compatibility issues. Business teams may be reluctant to upgrade clients, and compatibility between old clients and new backends can become an obstacle. + +### In your opinion, what can the project do better? + +The community needs to enhance its promotion and outreach efforts, especially regarding usage guidelines. + +CubeFS is a relatively simple and user-friendly storage solution in the industry, making it easy to use and customize. However, the number of public users is lower than expected. We suggest the community focus more on increasing its user base. diff --git a/projects/chubaofs/cubefs-adopter-interview-jd.com.md b/projects/chubaofs/cubefs-adopter-interview-jd.com.md new file mode 100644 index 000000000..2ad83d8ea --- /dev/null +++ b/projects/chubaofs/cubefs-adopter-interview-jd.com.md @@ -0,0 +1,129 @@ +# CubeFS Adopter Interview - JD.com + +Interview date: Sept. 6th, 2024 +Interviewee: Mevin Zhang, Software Architect, JD.com + +## Organization Intro + +### Can you give us an overview of your organization and what it does? + +We are from JD.com, also known as Jingdong Mall, we primarily serve the retail business. + +We use CubeFS as the foundation for our entire storage infrastructure, supporting various unstructured storage scenarios across JD Retail's middleware, online and offline operations, big data, and AI training. We have multiple large resource pools for these purposes. + +## Motivation + +### Compared with other products in this space (proprietary and open), what drew you to the project? + +We chose CubeFS for its customizability to fit our specific scenarios and its support for large-scale clusters. CubeFS also supports multiple protocols, including POSIX and S3, whereas many other options only support either A or B protocols. + +In JD.com's case, different business departments use different protocols. CephFS does not support operating on the same dataset with different protocols simultaneously, which complicates the overall tech stack. Additionally, MooseFS has issues with scalability and stability. + +## Usage Scenario + +### How long has your organization used the project? + +We started using CubeFS in 2018. + +### What were the main motivations to adopt the project and which key features do you use today? + +We are using most of the major features of CubeFS, including: + +- Support for multiple protocols +- Management capabilities for large-scale clusters +- A design that is friendly to both large and small files +- Multi-tenant support + +### What is the current level of usage (pre-production, production) and scale? + +We have been using CubeFS in the production environment for over six years. We have multiple clusters, with the largest cluster consisting of more than 4,000 servers, utilizing a multi-module hybrid deployment. Each node runs different CubeFS modules. Our total storage capacity exceeds 300TB, and we have over 1 million clients online simultaneously. + +### What version is used and what is your update cadence with the project? + +We are using the 2020 version of CubeFS from the community. +Bug fixes are manually back ported without a fixed schedule. + +### 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? + +CubeFS provides general protocols, so no modifications were needed during the application integration process. + +However, due to the unique distribution of hardware resources and IDC, and our company's high availability requirements, we had to customize resource scheduling strategies. This included determining how replicas should be distributed and how new resources should be allocated based on the company's IT architecture. + +### 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 project design docs clearly explained the current key design ideas and the reasons behind. They were very helpful for us to better understand and work on customizing & extending CubeFS. + +### 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 + +We adopted CubeFS to build our storage system from scratch, as we previously lacked such a large-scale storage solution. + +This implementation reduced the maintenance and resource costs for different business teams. + +By utilizing centralized large resource pools, we improved resource utilization. Storage resource usage reached 80-90%, with some environments achieving usage rates up to 98%. + +### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc + +We have been actively engaging and collaborating with the community, sharing our solutions and use cases, proposing features, and contributing implementations. + +One of the features we are recently discussing is: distributed cache. + +We also participate in in-depth discussions and exchanges through community meetings and ad-hoc sessions. + +### JD.com was the initiating organization of the CubeFS project, and some of the initial maintainers later on joined other organizations. What motivates you to continue to use CubeFS and engage with the community? + +Most crucially, CubeFS fulfills our technical and business requirements, and has been successfully and extensively deployed on a large scale in production since its early stage. + +We consider JD.com and the community as a mutually supportive relationship, which motivates us to keep participating and helping the community grow + + +### For the heavily customized version within JD.com, what are the considerations for the follow-up? E.g. better aligned with the upstream code base, decoupled downstream enhancements + +We have had some discussions with the community, but currently, we don’t have enough energy to fully align with the upstream code base. However, in the long term, we hope to better integrate our version with the upstream one. We will contribute some of our features back to the community to help that process. + +## Perception + +### What is your perception in terms of the project’s + +- Community openness +- Governance +- Community growth potential +- Maintainer diversity and ladder +- Maintainer response + +The community governance is relatively rational, with a clear ladder and well-defined responsibilities from Contributor to Maintainer. + +Maintainers are responsive, actively dealing with GitHub issues and PRs. The community WeChat group is also quite active, with maintainers, other adopters, and contributors all taking part in the discussions. + +### How are you participating in the project community? + +We contribute by sharing our internal solutions and insights with the community. We also share issues and thoughts when we synchronize differences between the open-source version and JD.com’s internal version, including code and solution-level. + +Additionally, JD.com has several project maintainers who participate in community activities such as PR reviews. + +### 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 engaged with community members and maintainers through GitHub and WeChat groups. The communication methods and timeliness met our needs effectively. + +## Project Strengths + +### In your opinion, what are the overall strengths of the project? + +1. Support for extreme scenarios. +2. CubeFS provides functionalities that numerous other projects lack. +3. It fulfills the internal requirements of large enterprises such as JD.com: + a. Ultra-large scale. + b. Support for an enormous number of tenants. + c. Support for multiple protocols (simultaneous operations and data visibility), which is vital for companies with complex internal structures. + +## Project Improvements + +### Is there something you feel that holds the project back from reaching its ultimate potential? + +The items planned in the current roadmap e.g. 1.”Support for distributed caching”, 2. “Support for RDMA devices”, are quite valuable to us. + +### In your opinion, what can the project do better? + +From a community perspective, the project could: + +- Organize and participate in more events to encourage greater involvement in the CubeFS community. +- Promote wider adoption of CubeFS by engaging more users. diff --git a/projects/chubaofs/cubefs-adopter-interview-netease.md b/projects/chubaofs/cubefs-adopter-interview-netease.md new file mode 100644 index 000000000..b5d17fc0e --- /dev/null +++ b/projects/chubaofs/cubefs-adopter-interview-netease.md @@ -0,0 +1,132 @@ +# CubeFS Adopter Interview - NetEase + +Interview date: Auguest 1st, 2024 +Interviewee: Rio Zhang, Operations Engineer, NetEase + +## Organization Intro + +### Can you give us an overview of your organization and what it does? + +The big data team of NetEase Games. Business scenarios are: + +1. Business functions require the data analysis and log retrieval capabilities of ElasticSearch. A storage-computing separation scheme with flexible and adjustable positions is expected. +2. In the scenario of AI machine training and learning, NFS was used before, and there are challenges in reliability and performance. +3. In the log storage scenario of K8s, the disk space of nodes is limited. With the help of CubeFS, remote storage can be realized. + +CubeFS is used for data analysis and log retrieval, including: + +1. Game operation logs and game server logs. +2. For scoring and recommendation based on game data, storage-computing separation is required. + +## Motivation + +### Compared with other products in this space (proprietary and open), what drew you to the project? + +We made the selection in 2020. At that time, there were not many comparable options. Compared with proprietary solutions, we were more inclined to open source because it can be maintained by ourselves and has better data privacy. + +In fact, there were not many open source distributed storage solutions at that time. The relatively well-known Ceph is known to be difficult to maintain and requires a lot of manpower. Practice has proved that as a user of CubeFS, not much manpower is required. + +## Usage Scenario + +### How long has your organization used the project? + +We have been using CubeFS for 4 years. Started with v2.1.0 in July, 2020. + +### What were the main motivations to adopt the project and which key features do you use today? + +The initial motivation was to achieve storage-computing separation for ElasticSearch. Moreover, CubeFS had been widely implemented on a large scale at JD.com, reliability was ensured. + +As the project evolves and business needs arise: + +- We use the Erasure Code subsystem to back up and load ElasticSearch snapshots through the S3 interface. Compared with the previous replica system, storage is reduced by 50%. + +- Machine learning requires high-performance and highly available storage. After testing, CubeFS meets the requirements and is put into use. We mainly use the replica subsystem, FUSE, and S3 interfaces. For public cloud acceleration, we use the cfs-bcache cache. + +- We store the logs generated by K8s pods to avoid the host Kubelet entering disk pressure status. In this case, we mainly use the replica subsystem and the FUSE interface. + +### What is the current level of usage (pre-production, production) and scale? + +**Pre-production environment:** about 20 servers, storing 100TB of data, mainly test environment and intranet office network equipment, SLA requirements are not so high. + +**Production Environment:** More than 200 servers, including replica systems and Erasure Code systems, storing 15PB of user data + +### What version is used and what is your update cadence with the project? + +One feature release upgrade per year, CubeFS is usually stable, no fatal bugs. +For bugfix releases, we upgrade as needed. +The upgrade process is done by automated scripts, which does not require attendance, and administrators only step in to fix problems when they occur. + +### 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? + +Most of the time, we integrate with existing services via the FUSE interface, with a small number of services natively supporting S3. The main challenges encountered in these projects were: + +- CubeFS does not work according to posix semantics in some corner cases, such as the behavior when reading and writing is stuck or reporting errors, but they were fixed after the community maintainer debugged and located them together. In this process, the community was responsive and positively dealing with problems. +- There were many problems before CubeFS v2.4.0, and in the later version we mainly met operational and maintenance issues, such as ease of use, etc. We can deal with them by ourselves and actively communicate with the community. + +### 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? + +Yes, we did find the information valuable. We often look for source code logic based on printed logs or running parameters. The project manual is mainly used to find usage parameters and common FAQs. The documentation is relatively complete, and in most scenarios, we can find the needed information in the documents. The official account of the community has source code analysis articles, which are of great help in familiarizing ourselves with the implementation of the project. + +### 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 + +Compared to the previous maintenance of ElasticSearch on traditional physical disks, we used LVM to rent out to multiple users. The disks were not fully consumed but the CPUs were, resulting in a large amount of waste of resource fragmentation. Moreover, the IO cannot be adjusted, and hardware failures have a large impact. We expanded and promoted the reduced storage capacity to other businesses such as AI training and K8s logging. + +Improvements in problem challenges: + +- Reduction in resource waste. Previously, the usage rate was that only 60% of the CPU was actually consumed and only 39% of the disk was consumed. After using CubeFS, the usage rate is 80%, with almost no resource fragmentation. Disks do not need to be set up with RAID 10 to reduce the failure rate. Using CubeFS has increased storage efficiency by 100%. +- Compared to three replicas, Erasure Code reduces the consumption of storage space by nearly 100% (saving 50% of space). +- Reduction in operation and maintenance manpower. Before using CubeFS, every time a server fails, it requires manual handling, and all involved business layers need to be modified accordingly. After using CubeFS, handling server failures does not require changes in the business layer. + +Solution to problems: CubeFS provides a high-performance storage solution for the AI training scenario. + +### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc + +We hope CubeFS can be further improved in hybrid cloud acceleration and provide kernel client support. + +- For the hybrid cloud scenarios: + - Workloads are deployed in IDC + public cloud or only running in the public cloud, resources need to be released after completion. With the data source in IDC, a caching scheme is used to accelerate data access on the public cloud. + - Currently, the cache and client have a 1:1 deployment relationship. The cache cannot be reused, resulting in high resource consumption. We hope the community can consider providing a shared cache solution. +- Regarding the kernel space client: + - Currently, the FUSE client is in user space and has limited performance. We hope the community can consider providing a kernel space client to offer higher performance. + +## Perception + +### What is your perception in terms of the project’s +- Community openness +- Governance +- Community growth potential +- Maintainer diversity and ladder +- Maintainer response + + +The community has done relatively well in the areas above. +The community has shown that it values users and will provide targeted user support in the community, such as answering questions. +The community is also active, with regular updates on the WeChat official account. + +### How are you participating in the project community? + +We mainly submit code and issues on GitHub and communicate with developers through issues and WeChat groups. + +### 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 mainly interact with community members through WeChat and GitHub issues. The purpose is to solve usage problems and discuss some optimization methods. + +It can meet the need for communicating with community members. + +## Project Strengths + +### In your opinion, what are the overall strengths of the project? + +Relatively low maintenance cost and few open source competitors. + +## Project Improvements + +### Is there something you feel that holds the project back from reaching its ultimate potential? + +The low performance ceiling of the user-space interface of FUSE holds the project back from reaching its ultimate potential. When using the FUSE interface for writing to ElasticSearch, it cannot achieve a very high QPS. Our current workaround is to write to a physical SSD first and then convert to CubeFS storage through ElasticSearch's hot and cold separation mechanism. In fact, using a physical SSD is not storage-compute separation. + +If FUSE could provide merged writes, it would meet the performance requirements. Given the current actual situation where FUSE may not be easy to modify, considering the kernel-space approach could be an option. + +### In your opinion, what can the project do better? + +The project could do better by finding several medium and large companies to jointly research and use it and contribute to the community. In my view, smaller companies are more inclined towards commercial cloud solutions. Apart from commercial cloud solutions, storage developed by companies with R&D capabilities will be closed source or even be based on secondary development of an open source component. diff --git a/projects/chubaofs/cubefs-graduation-dd.md b/projects/chubaofs/cubefs-graduation-dd.md new file mode 100644 index 000000000..6c2765b35 --- /dev/null +++ b/projects/chubaofs/cubefs-graduation-dd.md @@ -0,0 +1,499 @@ +# CubeFS Graduation Due Diligence + +- Link to [CubeFS Graduation application](https://github.com/cncf/toc/pull/1140) + + + +## Graduation Evaluation Summary for CubeFS + +### Criteria Evaluation + +Kevin Wang conducted the due diligence of CubeFS who applied for graduation. The project has completed the criteria that show its maturity at graduation. + +The following criteria implementations are noteworthy to call out: + +- A stable and easily maintainable distributed file system, with excellent concurrent write performance, scalability and extensibility. +- Has a strong and growing community of maintainers and adopters, ensuring its long-term sustainability. +- Provided diverse channels for community users and contributors to interact, and public meeting links, recordings and notes can be easily found. +- Provided high-quality, well-organized documentation and practical examples to help users quickly learn and master the project. +- The project completed the [third party security audit by Ada Logics](https://github.com/cubefs/cubefs/blob/master/security/CubeFS-security-audit-2023-report.pdf) with no high-level or critical issues found. The project team actively resolved the 12 detected issues, clearly demonstrated commitment to security, which is praiseworthy. + +The following actions were provided to the project that were considered blocking but have since been resolved: + +- Removed the Project Lead role, previously held by one individual and considered conflicting with community neutrality. And instead, established a Technical Steering Committee (TSC) with a defined number of seats and neutrality requirements. +- Updated the governance documents to clarify the management rules for subprojects. +- Added a [RELEASE.md](https://github.com/cubefs/cubefs/blob/master/RELEASE.md) file, including updating the release process to reflect the latest engineering principles criteria. +- Updated the governance documents to inlcude roadmap changing process. + +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: + +- TOC Reviewer recommends finalizing the ongoing Governance Review by the TAG Contributor Strategy to achieve a more comprehensive community governance. +- TOC Reviewer recommends to extend its current management rules to cover all repos under the GitHub organization, including non-subproject repos, and archive any repos that are no longer being maintained. +- Make full use of `cubefs-community` repo, as the canonical location for community governance-related documents. +- To better support project adopters, TOC Reviewer suggests keeping deep engagement with them and improving the project's extensibility and code history management. This will facilitate easier tracking of community updates. +- To foster a more inclusive global community, TOC Reviewer recommends making a plan for global community development. This plan may include initiatives like English-language community meetings and cultivating contributors from various regions to better support adopters worldwide. +- TOC Reviewer recommends to organizing dedicated TSC meeting, in order to keep TSC members engaged. +- To enhance community decision-making transparency, the TOC Reviewer recommends the project provide explicit records of voting processes, e.g. manual vote counts or using [gitvote](https://github.com/cncf/gitvote). + +### Adoption Evaluation + +The adopter interviews reflect the production grade usage of CubeFS for the applied Graduation level. According to the feedback, CubeFS simplifies the interaction between users and storage infrastructure by providing a high-performance, scalable, reliable and easy-to-maintain distributed file system. Developers leverage CubeFS to address the challenges of complex distributed file systems, including large-scale data storage, high concurrent access, data reliability and the complexity of system maintenance. Adopters have been using CubeFS in the production environment for many years, managing data ranging from hundreds of terabytes to petabytes and supporting the access of millions of clients. Overall, the stability, reliable performance and active community of CubeFS have built the trust of adopters. + +### Final Assessment + +The TOC has found the project to have satisfied the criteria for Graduation. + +## Application Process Principles + +### Suggested + +N/A + +### Required + +- [x] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** + + The CubeFS team has given presentation on the TAG Storage meeting on April 24, 2024. [link to recording](https://www.youtube.com/watch?v=UgRBZhzfr4w) + + The project has requested Governance Review by TAG Contributor Strategy at: + +- [x] **TAG provides insight/recommendation of the project in the context of the landscape** + + TAG Storage recommendation can be found in [this doc](https://docs.google.com/document/d/1D-Y1XVmPNu_g4Vtl6ZhmueR2ATmuGjoe8Bnc-uTFsqI/edit). + > TAG Storage has reviewed CubeFS for its graduation request, provided suggestions for updating CubeFS-csi and CubeFS-helm projects to resolve CVEs, and the team responded quickly to address the issues. We recommend that the CubeFS team continue to keep these projects up to date. We believe that the project’s health is sound in general, the customer adoption has been increasing, and the project is at a mature state and it is ready to move to the graduation level. + +- [x] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + + - **Neutral resources** - CubeFS has its own channels (community branded and managed), including: + - Homepage: + - Mailing list: + - Slack: + - WeChat: + - Twitter: + - Community Meeting: + + - **Governance** - [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md) defined vendor-neutrality requirements on the TSC, Maintainers, Committers, including: + - [The structure of the Technical Steering Committee Section](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#the-structure-of-the-maintainers) says: `No single vendor can exceed 50% of the total number of personnel.` + - [The structure of the Maintainers Section](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#the-structure-of-the-maintainers) says: `No single vendor can exceed 50% of the total number of personnel.` + - [The structure of the Committers Section](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#the-structure-of-the-committers) says: `No single vendor can exceed 50% of the total number of personnel.` + +- [x] **Review and acknowledgement of expectations for [graduated](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.** + - [x] Met during Project's application on 10-Apr-2024 as a kick-off meeting. + + The [initial PR](https://github.com/cncf/toc/pull/1140) was submitted on 5-Aug-2023. The TOC Reviewer was assigned on 9-Apr-2024. + + On 10-Apr-2024, the TOC Reviewer and project maintainers met during the kick-off meeting of the Graduation process, discussed the changes and update in the TOC repo regarding the criteria and expectations for moving levels, release, and freeze time period for KubeCons. + + The project provided [updates](https://github.com/cubefs/cubefs/issues/3298) using the recommended template on 18-Jun-2024. + + The TOC Reviewer and project maintainers met multiple time during the due diligence review. Some [suggested action items](https://github.com/cncf/toc/pull/1140#issuecomment-2195009379) were provided during the review, and the project maintainers have been highly responsive throughout the process. + + Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria. + +- [x] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** + + - [CubeFS introduction documentation](https://cubefs.io/docs/master/overview/introduction.html) introduces the CubeFS architecture and main features. + - [CubeFS installation documentation](https://cubefs.io/docs/master/deploy/env.html) covers serveral ways of deployment. + - [CubeFS end user documentation](https://cubefs.io/docs/master/user-guide/volume.html) includes basics operations as creating a volume, using volume and using cli tool. + +## Governance and Maintainers + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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.** + + CubeFS has been continuously updating governance doc to reflect project growth, some examples are: + - CubeFS initial governance: + - Added Commiter role in May. 2023: + - Added Steering Committee in Apr. 2024: + - Update maintainer list according to activity and add steering commitee member: + - Update the Governance Document to eliminate the role of the leader: + The description of 'project lead' implies a somewhat authoritarian role, but with the establishment of a steering committee, the steering committee should be considered the highest decision-making body.Thus CubeFS delete the role of 'project lead'. + - Adding governance rules related to SIGs.: + - Adding governance rules related to RoadMap.: + +### Required + +- [x] **Clear and discoverable project governance documentation.** + + CubeFS governance documentation: [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md) + +- [x] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** + + + Examples showing that governance is up to date: + - Update the document of the roadmap: + - Add new Committer: + - Nomination of Chairs and Tech Leads for SIG-CSI and SIG-Docs: + +- [x] **Governance clearly documents [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** + + CubeFS has clear vendor-neutrality description the [governance doc](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md), including matters related to information transparency, channel transparency, decision-making, and other aspects among vendors. + +- [x] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** + + - Decision making process on leadership roles: [GOVERNANCE.md#decision-making-process](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#decision-making-process) + - Contribution acceptance: [CONTRIBUTING.md](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/CONTRIBUTING.md) + - Requests to the CNCF: [GOVERNANCE.md#cubefs-and-cncf](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#cubefs-and-cncf) + - Changes to governance or project goals + - Changes to governance or project goals: [GOVERNANCE.md#changes-in-project-governance](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-project-governance) + - Steering Committee Member is responsible for formulation roadmap: [GOVERNANCE.md#expectations-from-the-steering-committee](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#expectations-from-the-steering-committee) + +- [x] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** + + Main CubeFS project role update according to governance doc: + - [Becoming a Maintainer](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#becoming-a-maintainer) + - [Changes in Maintainer membership](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-maintainership) + - [Expectations From the steering committee](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#expectations-from-the-steering-committee) + - [Changes in Steering Committee](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-steering-committee) + - [Becoming a committer](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#becoming-a-committer) + - [Changes in committer membership](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-commitership) + + Governance of to SIGs. Rules for assignment, onboarding, and removal: [GOVERNANCE.md#sig](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#sig) + Product Security Committee Membership: Rules for assignment, onboarding, and removal: [security-release-process.md#product-security-committee-membership](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/security/security-release-process.md#product-security-committee-membership) + +- [x] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** + + CubeFS documents maintainers list at: + +- [x] **A number of active maintainers which is appropriate to the size and scope of the project.** + + CubeFS has 14 top level maintainers from: JD.com, BEIKE, OPPO, Bytedance, LinkedIn, XFusion. Ref: + + Activities of maintainers can be found at: [chubaofs.devstats.cncf.io](https://chubaofs.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All&var-country_name=All&var-companies=All) + +- [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** + + CubeFS has a clear maintainer lifecycle process documented in their governance doc: + - [GOVERNANCE.md#becoming-a-maintainer](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-maintainer) + - Document changes in maintainership, onboarding, offboarding: [GOVERNANCE.md#changes-in-maintainership](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#changes-in-maintainership) + +- [x] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** + + Demonstrations regarding the maintainer lifecycle of the CubeFS project: + - Chuanqing Zhang was added as a new committer + - Shuqiang Zheng was added as a new committer + - updated maintainer list including removal of inactive maintainers, and added steering committee members + +- [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** + + According to the [Maintainers list](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/MAINTAINERS.md), CubeFS currently has top level maintainers from OPPO, JD.com, BEIKE, Bytedance, LinkedIn, and additional committers from BIGO, VIVO. + + Definition of Maintainers and Committers can be found in the [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md) + Both Maintainers and Committers require diversed membership: `No single vendor can exceed 50% of the total number of personnel.` + +- [x] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** + + CubeFS uses a github CODEOWNERS mechanism to manage the code access between different community roles. Ref: + + +- [x] **Document agreement that project will adopt CNCF Code of Conduct.** + + Documented at [GOVERNANCE.md#code-of-conduct](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#code-of-conduct) + +- [x] **CNCF Code of Conduct is cross-linked from other governance documents.** + + CNCF Code of conduct is cross-linked in the [Code of Conduct of CubeFS](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/CODE_OF_CONDUCT.md) + +- [x] **All subprojects, if any, are listed.** + + The following projects are associated with CubeFS and maintained as sub-projects. + - [cubefs-helm](https://github.com/cubefs/cubefs-helm): CubeFS installation to helm in the Kubernetes ecosystem + - [cubefs-csi](https://github.com/cubefs/cubefs-csi): CSI (Container Storage Interface) plugin for CubeFS + - [cubefs-dashboard](https://github.com/cubefs/cubefs-dashboard): Dashboard for CubeFS + +- [x] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** + + According to [Governance.md#sub-projects](https://github.com/cubefs/cubefs/blob/3576d88889e94d7173401e389824dd61cc485718/GOVERNANCE.md#sub-projects), sub-projects can have their own repositories but follow the same governance mechanism as the main project + + Subprojects Goverance descriptions can be found at: + - cubefs-helm Governance: + - cubefs-csi Governance: + - cubefs-dashboard Governance: + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### Suggested + +- [x] **Contributor ladder with multiple roles for contributors.** + + Cubefs have multiple roles for contributors + - Steering committee member: [GOVERNANCE.md#expectations-from-the-steering-committee](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#expectations-from-the-steering-committee) + - Maintainer: [GOVERNANCE.md#expectations-from-maintainers](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#expectations-from-maintainers) + - Commiter: [GOVERNANCE.md#committer](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#committer) + +### Required + +- [x] **Clearly defined and discoverable process to submit issues or changes.** + + Defined in [CONTRIBUTING.md](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md), in the root path of CubeFS main repo. + +- [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** + + CubeFS has the following public communications channel for users and contributors documented in the [Project README](https://github.com/cubefs/cubefs#community) + - Website: + - Mailing list: + - Slack: + - WeChat: + - X/Twitter: + +- [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.** + + - The communication channels for CubeFS documented at + - Besides public channels, CubeFS has a private mailing list for users reporting security vulnerabilities. Ref: [SECURITY.md](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/SECURITY.md) + +- [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** + + CubeFS currently holds monthly community meeting, integrated with [CNCF calendar](https://www.cncf.io/calendar/) + Meeting minutes and recordings listed at: [CubeFS meeting schedule](https://github.com/cubefs/cubefs-community/wiki/Meeting-Schedule) + +- [x] **Documentation of how to contribute, with increasing detail as the project matures.** + + CubeFS contribution workflow documented at: [CONTRIBUTING.md#workflow](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/CONTRIBUTING.md#workflow) + +- [x] **Demonstrate contributor activity and recruitment.** + + - Contributor activities measured by devstats: [chubaofs.devstats.cncf.io](https://chubaofs.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=Since%20joining%20CNCF&var-metric=contributions&var-repogroup_name=All&var-country_name=All&var-companies=All) + - Contributor activity measured by GitHub contributor dashboard: [The contributions of contributors](https://github.com/cubefs/cubefs/graphs/contributors) + - Example of recruiting new committers according to contributor's contributions: + - [shuqiang-zheng](https://github.com/shuqiang-zheng) : + - [Contribution pr record](https://github.com/cubefs/cubefs/pulls?q=is%3Apr+is%3Amerged+author%3Ashuqiang-zheng) + - [PR link](https://github.com/cubefs/cubefs/pull/3384) to add to Committers list + - [zhangchuanqing](https://github.com/zhangchuanqing5658) : + - [Contribution main branch](https://github.com/cubefs/cubefs/tree/develop-v3.5.0-metanode_rocksdb) + - [PR link](https://github.com/cubefs/cubefs/pull/3386) to add to Committers list + + - Recruiting new contributors by participating in developer events + - [Summer of Open Source](https://www.we2shopping.com/blog/2829327/) + - [Developer activity 2024](https://github.com/cubefs/cubefs/issues/3105) + - [Developer activity 2023](https://github.com/cubefs/cubefs/issues/1920) + +## Engineering Principles + +### Suggested + +N/A + +### 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.** + + Project goal from project [README.md#what-can-you-build-with-cubefs](https://github.com/cubefs/cubefs/blob/master/README.md#what-can-you-build-with-cubefs): + + > As an open-source distributed storage, CubeFS can serve as your datacenter filesystem, data lake storage infra, and private or hybrid cloud storage. + > In particular, CubeFS enables the separation of storage/compute architecture for databases and AI/ML applications. + > + > Some key features of CubeFS include: + > + > - Multiple access protocols such as POSIX, HDFS, S3, and its own REST API + > - Highly scalable metadata service with strong consistency + > - Performance optimization of large/small files and sequential/random writes + > - Multi-tenancy support with better resource utilization and tenant isolation + > - Hybrid cloud I/O acceleration through multi-level caching + > - Flexible storage policies, high-performance replication or low-cost erasure coding + +- [x] **Document what the project does, and why it does it - including viable cloud native use cases.** + + CubeFS Introduction: [link](https://cubefs.io/docs/master/overview/introduction.html) + + According to [CubeFS doc](), typical use cases are: + - Big Data Analytics + - Deep Learning/Machine Learning + - Container Shared Storage + - Database & Middleware + - Online Services + - Traditional NAS to Cloud + +- [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** + + CubeFS has a public roadmap doc at [ROADMAP.md](https://github.com/cubefs/cubefs/blob/master/ROADMAP.md) + +- [x] **Roadmap change process is documented.** + + CubeFS documentes its roadmap rules and changing process in [GOVERNANCE.md#roadmap](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#roadmap) + +- [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** + + - CubeFS architecture overview: + - Design details are documented under the "Design" section, an example is: + +- [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** + + - [x] Release expectations (scheduled or based on feature implementation) + CubeFS documents their release frequency as needed (beta and official releases), which can be regarded as based on feature implementation. + - [x] Tagging as stable, unstable, and security related releases + CubeFS uses beta to mark their unstable releases. Ref: [RELEASE.md#types-of-releases](https://github.com/cubefs/cubefs/blob/master/RELEASE.md#types-of-releases). + Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/master/security/security-release-process.md) + - [x] Information on branch and tag strategies + + > | Type | Versioning | Branch | Frequency | + > | ---- | ---------- | --------- | --------- | + > | beta | vX.Y.Z-beta | release-X.Y.Z-Beta | as needed (at branch time) | + > | official | vX.Y.Z | release-X.Y.Z | as needed (post beta) | + + - [x] Branch and platform support and length of support + No specific description of platform supported, according to the [artifacts-included-in-the-release](https://github.com/cubefs/cubefs/blob/cef58ab3db04857b05a69d9a132e37d4d92e79c7/RELEASE.md#artifacts-included-in-the-release), currently only amd64 binaries are maintained by the community. + Length of support clearly documented, support latest 3 minor releases. + - [x] Artifacts included in the release. + - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. + Each release note specifies the artifacts included in the release. Example: [CubeFS v3.3.2 release notes](https://github.com/cubefs/cubefs/releases/tag/v3.3.2) + +- [x] **History of regular, quality releases.** + + History of CubeFS releases and changelogs: + +## Security + +Note: this section may be augemented by a joint-assessment performed by TAG Security. + +### Suggested + +- [x] **Achieving OpenSSF Best Practices silver or gold badge.** + + CubeFS has achieved the OpenSSF Best Practices siler badge: + + [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/6232/badge)](https://www.bestpractices.dev/projects/6232) + +### Required + +- [x] **Clearly defined and discoverable process to report security issues.** + + CubeFS has a clear security vulnerability report guide at: [SECURITY.md](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/SECURITY.md#report-a-vulnerability) + +- [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** + + - CubeFS commnity is currently WIP in the enforcement of two-factor authentication for all members: . + - DCO sign-off and review&approval by maintainers are required for all the incoming pull-request Ref: + > Every pull request that merges code to the master branch needs to be approved by at least one core maintainer for code review and pass all checks (including the DCO check) before it can be merged. + - CubeFS also enabled the following static and dynamic scanning, security scanning to help ensure the code quality: + - [gofumpt](https://github.com/cubefs/cubefs/blob/master/docker/script/run_format.sh) + - golint:In file [docker-compose.yml:469](https://github.com/cubefs/cubefs/blob/master/docker/docker-compose.yml#L469-L477) + - gosec:In file [docker-compose.yuml:479](https://github.com/cubefs/cubefs/blob/master/docker/docker-compose.yml#L479-L487) + - Fuzz testing [cubefs: add base fuzzers cncf/cncf-fuzzing#387](https://github.com/cncf/cncf-fuzzing/pull/387) + - CI integration includes ci-test-unit, ci-test-s3 and ci-sast: [ci.yml](https://github.com/cubefs/cubefs/blob/master/.github/workflows/ci.yml) + +- [x] **Document assignment of security response roles and how reports are handled.** + + The CubeFS [Security Release Process](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/security/security-release-process.md) documents response roles and process of handling reports. + +- [x] **Document Security Self-Assessment.** + + + +- [x] **Third Party Security Review.** + + - [x] Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs. + + CubeFS has passed the Third Party Security Review, Ref: [CubeFS-Security-Audit-2023-report](https://github.com/cubefs/cubefs/blob/master/security/CubeFS-security-audit-2023-report.pdf). + All found issues have been fixed, ref: page4 in the report "Executive summary". + Security advisories of the fixes: [link](https://github.com/cubefs/cubefs/security/advisories?state=Triage) + +- [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** + + CubeFS has achieved OpenSSF Best Practices passing badge: + +## Ecosystem + +### Suggested + +N/A + +### Required + +- [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** + + The [ADOPTERS.md](https://github.com/cubefs/cubefs/blob/master/ADOPTERS.md) documentes adopters with adoption level and success stories. + +- [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. + CubeFS has been adopted by a large base of end users, most of which prefer to remain anonymous. + +- [x] **TOC verification of adopters.** + + CubeFS Maintainers provided the TOC sponsor with a list of 7 users who agreed to be interviewed for the Graduation Due Diligence process. + Refer to the [Adoption portion of this document](#adoption) for details. + +- [x] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** + + - Integration with Hadoop: + - Integration with Kubernetes: + - Integration with Prometheus: + - Integration with Grafana: + + + +#### Adoption + +##### Adopter 1 - NetEase / Internet + +NetEase has integrated CubeFS into its cloud-native infrastructure since 2020, using it as a distributed file system solution. After a thorough evaluation of various options, CubeFS was selected for its superior scalability and reliability. Currently in production, NetEase's deployment spans over 200 servers and manages more than 15 petabytes of user data. + +The core features of CubeFS that NetEase finds most valuable are high availability, fault tolerance, and the ability to handle large data volumes efficiently. These functionalities have made CubeFS an integral part of their cloud operations. The project's compatibility with Kubernetes has also been a significant advantage. + +During the implementation phase, NetEase found the documentation quite helpful, although there was an initial challenge in understanding the architecture. They received community support that helped them overcome these initial hurdles. + +NetEase upgrades their deployment of CubeFS with one minor release per year and patch releases as needed. CubeFS releases are usually stable and upgrades can be done with automated scripts in most cases. + +Looking ahead, NetEase intends to increase its engagement with the CubeFS community and explore additional features that could enhance their cloud services. They view the project as a valuable asset that has not only met their storage needs but also contributed to their learning and development in distributed systems. + +The adoption of CubeFS has been a significant benefit for NetEase, enhancing its cloud services with a robust and scalable storage solution. The project's stability and clear scope and roadmap have built trust with NetEase, making it a reliable component for its cloud-native infrastructure needs. + +August, 2024 + +Ref: [Adopter Interview - NetEase](./cubefs-adopter-interview-netease.md) + +##### Adopter 2 - BEIKE / Housing Transactions and Services + +BEIKE has been using CubeFS since early 2020, starting with version 2.3. Currently, they are using version 3.3.1 in a large-scale production environment with a total capacity of 30PB (triple-replica redundancy), and some legacy environments are still running on version 2.4. + +The main motivation for adoption was CubeFS's overall read/write and concurrency performance, scalability, as well as the ability to seamlessly integrate with existing infrastructure. + +The adoption resulted in saving storage costs and easier debugging and problem resolution. The disk throttling feature has been useful, and the fault tolerance and data consistency features have been crucial in maintaining service continuity, even during peak business periods. + +During the migration from NFS to CubeFS, they faced challenges with decreased write performance for small files. They also met issues with the HDFS data integration tool due to lack of maintenance. And BEIKE found the CubeFS documentation to be comprehensive and the community support to be responsive, which has been instrumental in the successful integration and ongoing maintenance of the system. + +The community is open and friendly, BEIKE mainly participates in discussions in the WeChat group and attends monthly meetings, and contributes back when possible. Looking ahead, BEIKE hopes to be more involved in feature planning, enhancement discussions, and foster deeper collaboration with other community members. + +Overall, CubeFS's strengths include concurrent read and write operations and efficient bandwidth utilization. Areas for improvement include cleaner git commit history management, making features pluggable, and improving compatibility for upgrading historical versions. The community also needs to improve its promotion and outreach efforts. + +September, 2024 + +Ref: [Adopter Interview - BEIKE](./cubefs-adopter-interview-beike.md) + +##### Adopter3 - Live Streaming and Short Video + +Adopter3 started to use CubeFS in the second half of 2022. It began with testing and was deployed for production in January 2023. The key reason for adopting CubeFS was its ability to handle concurrent writes and the capability to horizontally scale metadata nodes. These were major advantages compared to HDFS and CephFS, which had constraints in performance, maintenance, and handling small files. + +CubeFS has been convenient to use with its FUSE mounting. It has been integrated with the Kubernetes clusters and is also used directly on physical machines in some scenarios. The community documentation has been helpful to the adopter for learning about APIs, RESTful commands, and the architecture. Some internal business units have transitioned from CephFS to CubeFS, benefiting from reduced maintenance time. The replacement of HDFS with CubeFS is in progress. + +In the future, Adopter3 plans to use the EC (Erasure Coding) feature when the community's architecture becomes more stable. Currently, they are focusing on replacing HDFS. Adopter3 has 3 committers in the community, interacting with maintainers primarily through WeChat group discussions. + +Overall, the CubeFS project is considered stable. However, there is room for improvement in areas such as covering more corner cases, promoting the project more effectively, and enhancing the format and content of issue and PR descriptions to facilitate better maintenance. + +September, 2024 + +Note: Adopter3 preferred to remain anonymous. The interview details are kept in a private file for CNCF TOC review. + +##### Adopter4 - Online Retailing + +JD.com has been using CubeFS since 2018 as the foundation for its entire storage infrastructure. This adoption supports a diverse range of unstructured storage needs across the company's retail operations, including middleware, online and offline business, big data, and AI training, etc. In production for more than 6 years, they have multiple clusters, with the largest one consisting of over 4,000 servers and a total storage capacity exceeding 300TB, serving over 1 million clients concurrently. They use the 2020 version from the community and manually backport bug fixes. + +JD.com choses CubeFS because it is customizable for their specific scenarios and supports large-scale clusters. CubeFS supports operating on the same dataset with different protocols simultaneously, like POSIX and S3, while alternatives like CephFS support only one. The adopter has also evaulated MooseFS, however it didn't met their requirements in scalability and stability. + +JD.com has found the project documentation invaluable, particularly the design documents, which facilitated a deeper understanding and customization of CubeFS. The adoption has led to significant value, including reduced maintenance and resource costs, and improved resource utilization, reaching up to 98% in some environments. + +From the adopter's perspective, the CubeFS community has rational governance and responsive maintainers. JD.com participates by sharing internal solutions, having maintainers review PRs, and interacting via GitHub and WeChat groups. + +JD.com has a positive view of the CubeFS community, with rational governance and responsive maintainers. JD.com participates by sharing internal solutions, having maintainers review PRs, and interacting via GitHub and WeChat groups. They will continue to actively engage, contribute solutions, propose features, seeing the relationship as mutually beneficial. + +Overall, CubeFS has strengths such as handling extreme scenarios and meeting enterprise requirements. JD.com suggests that the project could benefit from more community events and wider adoption promotion to reach its full potential. + + +October, 2024 + +Ref: [Adopter Interview - JD.com](./cubefs-adopter-interview-JD.com.md) From b97b8f01435ecab12cc1265ccbc911a1134410a2 Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Tue, 29 Oct 2024 18:14:03 +0800 Subject: [PATCH 11/60] update document links in CubeFS graduation DD Signed-off-by: Kevin Wang Signed-off-by: Lin Sun --- projects/chubaofs/cubefs-graduation-dd.md | 115 +++++++++++----------- 1 file changed, 58 insertions(+), 57 deletions(-) diff --git a/projects/chubaofs/cubefs-graduation-dd.md b/projects/chubaofs/cubefs-graduation-dd.md index 6c2765b35..1eb72adb8 100644 --- a/projects/chubaofs/cubefs-graduation-dd.md +++ b/projects/chubaofs/cubefs-graduation-dd.md @@ -16,13 +16,13 @@ The following criteria implementations are noteworthy to call out: - Has a strong and growing community of maintainers and adopters, ensuring its long-term sustainability. - Provided diverse channels for community users and contributors to interact, and public meeting links, recordings and notes can be easily found. - Provided high-quality, well-organized documentation and practical examples to help users quickly learn and master the project. -- The project completed the [third party security audit by Ada Logics](https://github.com/cubefs/cubefs/blob/master/security/CubeFS-security-audit-2023-report.pdf) with no high-level or critical issues found. The project team actively resolved the 12 detected issues, clearly demonstrated commitment to security, which is praiseworthy. +- The project completed the [third party security audit by Ada Logics](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/CubeFS-security-audit-2023-report.pdf) with no high-level or critical issues found. The project team actively resolved the 12 detected issues, clearly demonstrated commitment to security, which is praiseworthy. The following actions were provided to the project that were considered blocking but have since been resolved: - Removed the Project Lead role, previously held by one individual and considered conflicting with community neutrality. And instead, established a Technical Steering Committee (TSC) with a defined number of seats and neutrality requirements. - Updated the governance documents to clarify the management rules for subprojects. -- Added a [RELEASE.md](https://github.com/cubefs/cubefs/blob/master/RELEASE.md) file, including updating the release process to reflect the latest engineering principles criteria. +- Added a [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md) file, including updating the release process to reflect the latest engineering principles criteria. - Updated the governance documents to inlcude roadmap changing process. 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: @@ -72,12 +72,12 @@ N/A - Twitter: - Community Meeting: - - **Governance** - [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md) defined vendor-neutrality requirements on the TSC, Maintainers, Committers, including: - - [The structure of the Technical Steering Committee Section](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#the-structure-of-the-maintainers) says: `No single vendor can exceed 50% of the total number of personnel.` - - [The structure of the Maintainers Section](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#the-structure-of-the-maintainers) says: `No single vendor can exceed 50% of the total number of personnel.` - - [The structure of the Committers Section](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#the-structure-of-the-committers) says: `No single vendor can exceed 50% of the total number of personnel.` + - **Governance** - [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md) defined vendor-neutrality requirements on the TSC, Maintainers, Committers, including: + - [The structure of the Technical Steering Committee Section](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#the-structure-of-the-technical-steering-committee) says: `No single vendor can exceed 50% of the total number of personnel.` + - [The structure of the Maintainers Section](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#the-structure-of-the-maintainers) says: `No single vendor can exceed 50% of the total number of personnel.` + - [The structure of the Committers Section](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#the-structure-of-the-committers) says: `No single vendor can exceed 50% of the total number of personnel.` -- [x] **Review and acknowledgement of expectations for [graduated](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.** +- [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** - [x] Met during Project's application on 10-Apr-2024 as a kick-off meeting. The [initial PR](https://github.com/cncf/toc/pull/1140) was submitted on 5-Aug-2023. The TOC Reviewer was assigned on 9-Apr-2024. @@ -105,20 +105,21 @@ Note: this section may be augmented by the completion of a Governance Review fro - [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.** CubeFS has been continuously updating governance doc to reflect project growth, some examples are: - - CubeFS initial governance: + - CubeFS initial governance: - Added Commiter role in May. 2023: - Added Steering Committee in Apr. 2024: - Update maintainer list according to activity and add steering commitee member: - Update the Governance Document to eliminate the role of the leader: - The description of 'project lead' implies a somewhat authoritarian role, but with the establishment of a steering committee, the steering committee should be considered the highest decision-making body.Thus CubeFS delete the role of 'project lead'. + The description of 'project lead' implies a somewhat authoritarian role, but with the establishment of a Steering Committee, the Steering Committee should be considered the highest decision-making body.Thus CubeFS delete the role of 'project lead'. - Adding governance rules related to SIGs.: - Adding governance rules related to RoadMap.: + - Renamed Steering Committee to Technical Steering Committee, and clarified responsibilities and lifecycle of TSC, maintainers, and committers, SIGs: ### Required - [x] **Clear and discoverable project governance documentation.** - CubeFS governance documentation: [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md) + CubeFS governance documentation: [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md) - [x] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** @@ -130,45 +131,45 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Governance clearly documents [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** - CubeFS has clear vendor-neutrality description the [governance doc](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md), including matters related to information transparency, channel transparency, decision-making, and other aspects among vendors. + CubeFS has clear vendor-neutrality description the [governance doc](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md), including matters related to information transparency, channel transparency, decision-making, and other aspects among vendors. - [x] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** - - Decision making process on leadership roles: [GOVERNANCE.md#decision-making-process](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#decision-making-process) - - Contribution acceptance: [CONTRIBUTING.md](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/CONTRIBUTING.md) - - Requests to the CNCF: [GOVERNANCE.md#cubefs-and-cncf](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#cubefs-and-cncf) + - Decision making process on leadership roles: [GOVERNANCE.md#decision-making-process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#decision-making-process) + - Contribution acceptance: [CONTRIBUTING.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/CONTRIBUTING.md) + - Requests to the CNCF: [GOVERNANCE.md#cubefs-and-cncf](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#cubefs-and-cncf) - Changes to governance or project goals - - Changes to governance or project goals: [GOVERNANCE.md#changes-in-project-governance](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-project-governance) - - Steering Committee Member is responsible for formulation roadmap: [GOVERNANCE.md#expectations-from-the-steering-committee](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#expectations-from-the-steering-committee) + - Changes to governance or project goals: [GOVERNANCE.md#changes-in-project-governance](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-project-governance) + - Technical Steering Committee Member is responsible for formulation roadmap: [GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc) - [x] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** Main CubeFS project role update according to governance doc: - - [Becoming a Maintainer](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#becoming-a-maintainer) - - [Changes in Maintainer membership](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-maintainership) - - [Expectations From the steering committee](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#expectations-from-the-steering-committee) - - [Changes in Steering Committee](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-steering-committee) - - [Becoming a committer](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#becoming-a-committer) - - [Changes in committer membership](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#changes-in-commitership) + - [Becoming a Maintainer](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#becoming-a-maintainer) + - [Changes in Maintainer membership](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-maintainership) + - [Expectations From the Technical Steering Committee](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc) + - [Changes in TSC](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-tsc) + - [Becoming a committer](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#becoming-a-committer) + - [Changes in committer membership](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-commitership) - Governance of to SIGs. Rules for assignment, onboarding, and removal: [GOVERNANCE.md#sig](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/GOVERNANCE.md#sig) - Product Security Committee Membership: Rules for assignment, onboarding, and removal: [security-release-process.md#product-security-committee-membership](https://github.com/cubefs/cubefs/blob/6617aa1eb7bf6b63bfacc2c266eeb711c650973f/security/security-release-process.md#product-security-committee-membership) + Governance of to SIGs. Rules for assignment, onboarding, and removal: [GOVERNANCE.md#sig](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#sig) + Product Security Committee Membership: Rules for assignment, onboarding, and removal: [security-release-process.md#product-security-committee-membership](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md#product-security-committee-membership) - [x] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** - CubeFS documents maintainers list at: + CubeFS documents maintainers list at: - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** - CubeFS has 14 top level maintainers from: JD.com, BEIKE, OPPO, Bytedance, LinkedIn, XFusion. Ref: + CubeFS has 14 top level maintainers from: JD.com, BEIKE, OPPO, Bytedance, LinkedIn, XFusion. Ref: Activities of maintainers can be found at: [chubaofs.devstats.cncf.io](https://chubaofs.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All&var-country_name=All&var-companies=All) - [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** CubeFS has a clear maintainer lifecycle process documented in their governance doc: - - [GOVERNANCE.md#becoming-a-maintainer](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#becoming-a-maintainer) - - Document changes in maintainership, onboarding, offboarding: [GOVERNANCE.md#changes-in-maintainership](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#changes-in-maintainership) + - Becoming a maintainer: [GOVERNANCE.md#becoming-a-maintainer](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#becoming-a-maintainer) + - Changes in maintainership: [GOVERNANCE.md#changes-in-maintainership](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-maintainership) - [x] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** @@ -179,9 +180,9 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** - According to the [Maintainers list](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/MAINTAINERS.md), CubeFS currently has top level maintainers from OPPO, JD.com, BEIKE, Bytedance, LinkedIn, and additional committers from BIGO, VIVO. + According to the [Maintainers list](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/MAINTAINERS.md), CubeFS currently has top level maintainers from OPPO, JD.com, BEIKE, Bytedance, LinkedIn, and additional committers from BIGO, VIVO. - Definition of Maintainers and Committers can be found in the [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md) + Definition of Maintainers and Committers can be found in the [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md). Both Maintainers and Committers require diversed membership: `No single vendor can exceed 50% of the total number of personnel.` - [x] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** @@ -191,11 +192,11 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Document agreement that project will adopt CNCF Code of Conduct.** - Documented at [GOVERNANCE.md#code-of-conduct](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#code-of-conduct) + Documented at [GOVERNANCE.md#code-of-conduct](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#code-of-conduct) - [x] **CNCF Code of Conduct is cross-linked from other governance documents.** - CNCF Code of conduct is cross-linked in the [Code of Conduct of CubeFS](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/CODE_OF_CONDUCT.md) + CNCF Code of conduct is cross-linked in the [Code of Conduct of CubeFS](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/CODE_OF_CONDUCT.md) - [x] **All subprojects, if any, are listed.** @@ -206,7 +207,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** - According to [Governance.md#sub-projects](https://github.com/cubefs/cubefs/blob/3576d88889e94d7173401e389824dd61cc485718/GOVERNANCE.md#sub-projects), sub-projects can have their own repositories but follow the same governance mechanism as the main project + According to [Governance.md#sub-projects](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#sub-projects), sub-projects can have their own repositories but follow the same governance mechanism as the main project Subprojects Goverance descriptions can be found at: - cubefs-helm Governance: @@ -222,15 +223,15 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Contributor ladder with multiple roles for contributors.** Cubefs have multiple roles for contributors - - Steering committee member: [GOVERNANCE.md#expectations-from-the-steering-committee](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#expectations-from-the-steering-committee) - - Maintainer: [GOVERNANCE.md#expectations-from-maintainers](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#expectations-from-maintainers) - - Commiter: [GOVERNANCE.md#committer](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/GOVERNANCE.md#committer) + - Technical Steering committee member: [GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc) + - Maintainer: [GOVERNANCE.md#expectations-from-maintainers](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-maintainers) + - Commiter: [GOVERNANCE.md#expectations-from-committers](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-committers) ### Required - [x] **Clearly defined and discoverable process to submit issues or changes.** - Defined in [CONTRIBUTING.md](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md), in the root path of CubeFS main repo. + Defined in [CONTRIBUTING.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/CONTRIBUTING.md), in the root path of CubeFS main repo. - [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** @@ -244,7 +245,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [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.** - The communication channels for CubeFS documented at - - Besides public channels, CubeFS has a private mailing list for users reporting security vulnerabilities. Ref: [SECURITY.md](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/SECURITY.md) + - Besides public channels, CubeFS has a private mailing list for users reporting security vulnerabilities. Ref: [SECURITY.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/SECURITY.md) - [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** @@ -253,7 +254,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Documentation of how to contribute, with increasing detail as the project matures.** - CubeFS contribution workflow documented at: [CONTRIBUTING.md#workflow](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/CONTRIBUTING.md#workflow) + CubeFS contribution workflow documented at: [CONTRIBUTING.md#workflow](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/CONTRIBUTING.md#workflow) - [x] **Demonstrate contributor activity and recruitment.** @@ -268,7 +269,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [PR link](https://github.com/cubefs/cubefs/pull/3386) to add to Committers list - Recruiting new contributors by participating in developer events - - [Summer of Open Source](https://www.we2shopping.com/blog/2829327/) + - [Summer of Open Source](https://www.bilibili.com/video/BV1WV4y1Z7nw/) - [Developer activity 2024](https://github.com/cubefs/cubefs/issues/3105) - [Developer activity 2023](https://github.com/cubefs/cubefs/issues/1920) @@ -282,7 +283,7 @@ N/A - [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.** - Project goal from project [README.md#what-can-you-build-with-cubefs](https://github.com/cubefs/cubefs/blob/master/README.md#what-can-you-build-with-cubefs): + Project goal from project [README.md#what-can-you-build-with-cubefs](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/README.md#what-can-you-build-with-cubefs): > As an open-source distributed storage, CubeFS can serve as your datacenter filesystem, data lake storage infra, and private or hybrid cloud storage. > In particular, CubeFS enables the separation of storage/compute architecture for databases and AI/ML applications. @@ -310,11 +311,11 @@ N/A - [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** - CubeFS has a public roadmap doc at [ROADMAP.md](https://github.com/cubefs/cubefs/blob/master/ROADMAP.md) + CubeFS has a public roadmap doc at [ROADMAP.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/ROADMAP.md) - [x] **Roadmap change process is documented.** - CubeFS documentes its roadmap rules and changing process in [GOVERNANCE.md#roadmap](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md#roadmap) + CubeFS documentes its roadmap rules and changing process in [GOVERNANCE.md#roadmap](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#roadmap) - [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** @@ -326,8 +327,8 @@ N/A - [x] Release expectations (scheduled or based on feature implementation) CubeFS documents their release frequency as needed (beta and official releases), which can be regarded as based on feature implementation. - [x] Tagging as stable, unstable, and security related releases - CubeFS uses beta to mark their unstable releases. Ref: [RELEASE.md#types-of-releases](https://github.com/cubefs/cubefs/blob/master/RELEASE.md#types-of-releases). - Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/master/security/security-release-process.md) + CubeFS uses beta to mark their unstable releases. Ref: [RELEASE.md#types-of-releases](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md#types-of-releases). + Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md) - [x] Information on branch and tag strategies > | Type | Versioning | Branch | Frequency | @@ -336,7 +337,7 @@ N/A > | official | vX.Y.Z | release-X.Y.Z | as needed (post beta) | - [x] Branch and platform support and length of support - No specific description of platform supported, according to the [artifacts-included-in-the-release](https://github.com/cubefs/cubefs/blob/cef58ab3db04857b05a69d9a132e37d4d92e79c7/RELEASE.md#artifacts-included-in-the-release), currently only amd64 binaries are maintained by the community. + No specific description of platform supported, according to the [artifacts-included-in-the-release](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md#artifacts-included-in-the-release), currently only amd64 binaries are maintained by the community. Length of support clearly documented, support latest 3 minor releases. - [x] Artifacts included in the release. - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. @@ -362,33 +363,33 @@ Note: this section may be augemented by a joint-assessment performed by TAG Secu - [x] **Clearly defined and discoverable process to report security issues.** - CubeFS has a clear security vulnerability report guide at: [SECURITY.md](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/SECURITY.md#report-a-vulnerability) + CubeFS has a clear security vulnerability report guide at: [SECURITY.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/SECURITY.md#report-a-vulnerability) - [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** - CubeFS commnity is currently WIP in the enforcement of two-factor authentication for all members: . - - DCO sign-off and review&approval by maintainers are required for all the incoming pull-request Ref: + - DCO sign-off and review&approval by maintainers are required for all the incoming pull-request Ref: > Every pull request that merges code to the master branch needs to be approved by at least one core maintainer for code review and pass all checks (including the DCO check) before it can be merged. - CubeFS also enabled the following static and dynamic scanning, security scanning to help ensure the code quality: - - [gofumpt](https://github.com/cubefs/cubefs/blob/master/docker/script/run_format.sh) - - golint:In file [docker-compose.yml:469](https://github.com/cubefs/cubefs/blob/master/docker/docker-compose.yml#L469-L477) - - gosec:In file [docker-compose.yuml:479](https://github.com/cubefs/cubefs/blob/master/docker/docker-compose.yml#L479-L487) + - [gofumpt](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/docker/script/run_format.sh) + - golint:In file [docker-compose.yml:469](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/docker/docker-compose.yml#L469-L477) + - gosec:In file [docker-compose.yuml:479](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/docker/docker-compose.yml#L479-L487) - Fuzz testing [cubefs: add base fuzzers cncf/cncf-fuzzing#387](https://github.com/cncf/cncf-fuzzing/pull/387) - - CI integration includes ci-test-unit, ci-test-s3 and ci-sast: [ci.yml](https://github.com/cubefs/cubefs/blob/master/.github/workflows/ci.yml) + - CI integration includes ci-test-unit, ci-test-s3 and ci-sast: [ci.yml](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/.github/workflows/ci.yml) - [x] **Document assignment of security response roles and how reports are handled.** - The CubeFS [Security Release Process](https://github.com/cubefs/cubefs/blob/1536a544f2d9547647ad4e260edade60163e3585/security/security-release-process.md) documents response roles and process of handling reports. + The CubeFS [Security Release Process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md) documents response roles and process of handling reports. - [x] **Document Security Self-Assessment.** - + - [x] **Third Party Security Review.** - [x] Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs. - CubeFS has passed the Third Party Security Review, Ref: [CubeFS-Security-Audit-2023-report](https://github.com/cubefs/cubefs/blob/master/security/CubeFS-security-audit-2023-report.pdf). + CubeFS has passed the Third Party Security Review, Ref: [CubeFS-Security-Audit-2023-report](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/CubeFS-security-audit-2023-report.pdf). All found issues have been fixed, ref: page4 in the report "Executive summary". Security advisories of the fixes: [link](https://github.com/cubefs/cubefs/security/advisories?state=Triage) @@ -406,7 +407,7 @@ N/A - [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** - The [ADOPTERS.md](https://github.com/cubefs/cubefs/blob/master/ADOPTERS.md) documentes adopters with adoption level and success stories. + The [ADOPTERS.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/ADOPTERS.md) documentes adopters with adoption level and success stories. - [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)** @@ -496,4 +497,4 @@ Overall, CubeFS has strengths such as handling extreme scenarios and meeting ent October, 2024 -Ref: [Adopter Interview - JD.com](./cubefs-adopter-interview-JD.com.md) +Ref: [Adopter Interview - JD.com](./cubefs-adopter-interview-jd.com.md) From b84fbec2eaabbfb21e8f65a93b6d53bcc6ff8bea Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Wed, 30 Oct 2024 17:20:10 +0800 Subject: [PATCH 12/60] update links in CubeFS graduation DD Signed-off-by: Kevin Wang Signed-off-by: Lin Sun --- projects/chubaofs/cubefs-graduation-dd.md | 52 ++++++++++++----------- 1 file changed, 27 insertions(+), 25 deletions(-) diff --git a/projects/chubaofs/cubefs-graduation-dd.md b/projects/chubaofs/cubefs-graduation-dd.md index 1eb72adb8..9a4c82857 100644 --- a/projects/chubaofs/cubefs-graduation-dd.md +++ b/projects/chubaofs/cubefs-graduation-dd.md @@ -34,6 +34,7 @@ The following recommendations were provided to the project that are non-blocking - To foster a more inclusive global community, TOC Reviewer recommends making a plan for global community development. This plan may include initiatives like English-language community meetings and cultivating contributors from various regions to better support adopters worldwide. - TOC Reviewer recommends to organizing dedicated TSC meeting, in order to keep TSC members engaged. - To enhance community decision-making transparency, the TOC Reviewer recommends the project provide explicit records of voting processes, e.g. manual vote counts or using [gitvote](https://github.com/cncf/gitvote). +- TOC Reviewer recommends to add explicit descripion of platforms supported in the [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md) ### Adoption Evaluation @@ -65,9 +66,9 @@ N/A - [x] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** - **Neutral resources** - CubeFS has its own channels (community branded and managed), including: - - Homepage: + - Homepage: - Mailing list: - - Slack: + - Slack: - WeChat: - Twitter: - Community Meeting: @@ -135,20 +136,20 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** - - Decision making process on leadership roles: [GOVERNANCE.md#decision-making-process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#decision-making-process) + - Decision making process on leadership roles: [GOVERNANCE.md#the-tsc-decision-making-process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#the-tsc-decision-making-process) - Contribution acceptance: [CONTRIBUTING.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/CONTRIBUTING.md) - Requests to the CNCF: [GOVERNANCE.md#cubefs-and-cncf](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#cubefs-and-cncf) - Changes to governance or project goals - Changes to governance or project goals: [GOVERNANCE.md#changes-in-project-governance](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-project-governance) - - Technical Steering Committee Member is responsible for formulation roadmap: [GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc) + - Technical Steering Committee Member is responsible for roadmap formulation: [GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc) - [x] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** Main CubeFS project role update according to governance doc: + - [Becoming a TSC member](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#becoming-a-tsc-member) + - [Changes in TSC](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-tsc) - [Becoming a Maintainer](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#becoming-a-maintainer) - [Changes in Maintainer membership](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-maintainership) - - [Expectations From the Technical Steering Committee](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc) - - [Changes in TSC](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-tsc) - [Becoming a committer](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#becoming-a-committer) - [Changes in committer membership](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-commitership) @@ -161,7 +162,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** - CubeFS has 14 top level maintainers from: JD.com, BEIKE, OPPO, Bytedance, LinkedIn, XFusion. Ref: + CubeFS currenlty has 14 top level maintainers from: JD.com, BEIKE, OPPO, Bytedance, LinkedIn, XFusion. Ref: Activities of maintainers can be found at: [chubaofs.devstats.cncf.io](https://chubaofs.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All&var-country_name=All&var-companies=All) @@ -189,7 +190,6 @@ Note: this section may be augmented by the completion of a Governance Review fro CubeFS uses a github CODEOWNERS mechanism to manage the code access between different community roles. Ref: - - [x] **Document agreement that project will adopt CNCF Code of Conduct.** Documented at [GOVERNANCE.md#code-of-conduct](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#code-of-conduct) @@ -222,10 +222,12 @@ Note: this section may be augmented by the completion of a Governance Review fro - [x] **Contributor ladder with multiple roles for contributors.** - Cubefs have multiple roles for contributors + Cubefs has the following roles for contributors that are related to code and non-code contributions: - Technical Steering committee member: [GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc) - Maintainer: [GOVERNANCE.md#expectations-from-maintainers](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-maintainers) - Commiter: [GOVERNANCE.md#expectations-from-committers](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-committers) + - SIG member: [GOVERNANCE.md#expectations-from-sigs-member](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-sigs-member) + - Product Security Committee (PSC): [security-release-process.md#product-security-committee-psc](https://github.com/cubefs/cubefs/blob/master/security/security-release-process.md#product-security-committee-psc) ### Required @@ -260,16 +262,11 @@ Note: this section may be augmented by the completion of a Governance Review fro - Contributor activities measured by devstats: [chubaofs.devstats.cncf.io](https://chubaofs.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=Since%20joining%20CNCF&var-metric=contributions&var-repogroup_name=All&var-country_name=All&var-companies=All) - Contributor activity measured by GitHub contributor dashboard: [The contributions of contributors](https://github.com/cubefs/cubefs/graphs/contributors) - - Example of recruiting new committers according to contributor's contributions: - - [shuqiang-zheng](https://github.com/shuqiang-zheng) : - - [Contribution pr record](https://github.com/cubefs/cubefs/pulls?q=is%3Apr+is%3Amerged+author%3Ashuqiang-zheng) - - [PR link](https://github.com/cubefs/cubefs/pull/3384) to add to Committers list - - [zhangchuanqing](https://github.com/zhangchuanqing5658) : - - [Contribution main branch](https://github.com/cubefs/cubefs/tree/develop-v3.5.0-metanode_rocksdb) - - [PR link](https://github.com/cubefs/cubefs/pull/3386) to add to Committers list + - Examples of recruiting new committers according to contributor's contributions: + - Add [shuqiang-zheng](https://github.com/shuqiang-zheng) to Committers list: + - Add [zhangchuanqing](https://github.com/zhangchuanqing5658) to Committers list: - Recruiting new contributors by participating in developer events - - [Summer of Open Source](https://www.bilibili.com/video/BV1WV4y1Z7nw/) - [Developer activity 2024](https://github.com/cubefs/cubefs/issues/3105) - [Developer activity 2023](https://github.com/cubefs/cubefs/issues/1920) @@ -324,23 +321,29 @@ N/A - [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** - - [x] Release expectations (scheduled or based on feature implementation) + - [x] **Release expectations (scheduled or based on feature implementation)** + CubeFS documents their release frequency as needed (beta and official releases), which can be regarded as based on feature implementation. - - [x] Tagging as stable, unstable, and security related releases + - [x] **Tagging as stable, unstable, and security related releases** + CubeFS uses beta to mark their unstable releases. Ref: [RELEASE.md#types-of-releases](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md#types-of-releases). Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md) - - [x] Information on branch and tag strategies + + - [x] **Information on branch and tag strategies** > | Type | Versioning | Branch | Frequency | > | ---- | ---------- | --------- | --------- | > | beta | vX.Y.Z-beta | release-X.Y.Z-Beta | as needed (at branch time) | > | official | vX.Y.Z | release-X.Y.Z | as needed (post beta) | - - [x] Branch and platform support and length of support + - [x] **Branch and platform support and length of support** + No specific description of platform supported, according to the [artifacts-included-in-the-release](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md#artifacts-included-in-the-release), currently only amd64 binaries are maintained by the community. Length of support clearly documented, support latest 3 minor releases. - - [x] Artifacts included in the release. - - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. + + - [x] **Artifacts included in the release.** + - **Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.** + Each release note specifies the artifacts included in the release. Example: [CubeFS v3.3.2 release notes](https://github.com/cubefs/cubefs/releases/tag/v3.3.2) - [x] **History of regular, quality releases.** @@ -480,7 +483,7 @@ September, 2024 Note: Adopter3 preferred to remain anonymous. The interview details are kept in a private file for CNCF TOC review. -##### Adopter4 - Online Retailing +##### Adopter4 - JD.com / Online Retailing JD.com has been using CubeFS since 2018 as the foundation for its entire storage infrastructure. This adoption supports a diverse range of unstructured storage needs across the company's retail operations, including middleware, online and offline business, big data, and AI training, etc. In production for more than 6 years, they have multiple clusters, with the largest one consisting of over 4,000 servers and a total storage capacity exceeding 300TB, serving over 1 million clients concurrently. They use the 2020 version from the community and manually backport bug fixes. @@ -494,7 +497,6 @@ JD.com has a positive view of the CubeFS community, with rational governance and Overall, CubeFS has strengths such as handling extreme scenarios and meeting enterprise requirements. JD.com suggests that the project could benefit from more community events and wider adoption promotion to reach its full potential. - October, 2024 Ref: [Adopter Interview - JD.com](./cubefs-adopter-interview-jd.com.md) From de0607e5b6d9ed2e0c2046082b18d69710e458c1 Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Thu, 31 Oct 2024 18:08:41 +0800 Subject: [PATCH 13/60] Update projects/chubaofs/cubefs-graduation-dd.md Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Kevin Wang Signed-off-by: Lin Sun --- projects/chubaofs/cubefs-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/chubaofs/cubefs-graduation-dd.md b/projects/chubaofs/cubefs-graduation-dd.md index 9a4c82857..aaaac0bab 100644 --- a/projects/chubaofs/cubefs-graduation-dd.md +++ b/projects/chubaofs/cubefs-graduation-dd.md @@ -23,7 +23,7 @@ The following actions were provided to the project that were considered blocking - Removed the Project Lead role, previously held by one individual and considered conflicting with community neutrality. And instead, established a Technical Steering Committee (TSC) with a defined number of seats and neutrality requirements. - Updated the governance documents to clarify the management rules for subprojects. - Added a [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md) file, including updating the release process to reflect the latest engineering principles criteria. -- Updated the governance documents to inlcude roadmap changing process. +- Updated the governance documents to include roadmap changing process. 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: From a9892f1d1520d19f1d0969c3a42f950cbd797222 Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Thu, 31 Oct 2024 19:46:13 +0800 Subject: [PATCH 14/60] Update recommendations according to suggestion from TheFoxAtWork Signed-off-by: Kevin Wang Signed-off-by: Lin Sun --- projects/chubaofs/cubefs-graduation-dd.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/projects/chubaofs/cubefs-graduation-dd.md b/projects/chubaofs/cubefs-graduation-dd.md index aaaac0bab..00f00977c 100644 --- a/projects/chubaofs/cubefs-graduation-dd.md +++ b/projects/chubaofs/cubefs-graduation-dd.md @@ -30,9 +30,11 @@ The following recommendations were provided to the project that are non-blocking - TOC Reviewer recommends finalizing the ongoing Governance Review by the TAG Contributor Strategy to achieve a more comprehensive community governance. - TOC Reviewer recommends to extend its current management rules to cover all repos under the GitHub organization, including non-subproject repos, and archive any repos that are no longer being maintained. - Make full use of `cubefs-community` repo, as the canonical location for community governance-related documents. -- To better support project adopters, TOC Reviewer suggests keeping deep engagement with them and improving the project's extensibility and code history management. This will facilitate easier tracking of community updates. +- TOC Reviewer recommends improving the project's extensibility and adding more pluggable framework designs. This would facilitate easier customization and easier decoupling of downstream enhancements by adopters. +- TOC Reviewer recommends improving feature lifecycle management, including feature maturity, configuration, commit history, and release notes. This would make it easier for adopters to track community updates and backport patches as needed. +- TOC Reviewer recommends to establish Adopters WG or other similar group, as a dedicated space for adopters to collaborate on shared features and functionality to continue improving and enhancing the project. - To foster a more inclusive global community, TOC Reviewer recommends making a plan for global community development. This plan may include initiatives like English-language community meetings and cultivating contributors from various regions to better support adopters worldwide. -- TOC Reviewer recommends to organizing dedicated TSC meeting, in order to keep TSC members engaged. +- TOC Reviewer recommends organizing dedicated TSC meeting, in order to keep TSC members engaged. - To enhance community decision-making transparency, the TOC Reviewer recommends the project provide explicit records of voting processes, e.g. manual vote counts or using [gitvote](https://github.com/cncf/gitvote). - TOC Reviewer recommends to add explicit descripion of platforms supported in the [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md) From f20e18ae7773aacd0ac8b679f57a5152e7f52871 Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Thu, 7 Nov 2024 03:24:50 +0800 Subject: [PATCH 15/60] address review comments from @angellk Signed-off-by: Kevin Wang Signed-off-by: Lin Sun --- projects/chubaofs/cubefs-graduation-dd.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/projects/chubaofs/cubefs-graduation-dd.md b/projects/chubaofs/cubefs-graduation-dd.md index 00f00977c..1adb4c94f 100644 --- a/projects/chubaofs/cubefs-graduation-dd.md +++ b/projects/chubaofs/cubefs-graduation-dd.md @@ -37,6 +37,9 @@ The following recommendations were provided to the project that are non-blocking - TOC Reviewer recommends organizing dedicated TSC meeting, in order to keep TSC members engaged. - To enhance community decision-making transparency, the TOC Reviewer recommends the project provide explicit records of voting processes, e.g. manual vote counts or using [gitvote](https://github.com/cncf/gitvote). - TOC Reviewer recommends to add explicit descripion of platforms supported in the [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md) +- TOC Reviewer recommends to cross reference the [roadmap governance(https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#roadmap)] and [change process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-project-roadmap) on the [ROADMAP.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/ROADMAP.md) to make it easier to find for potential contributors. +- And for the [roadmap change process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-project-roadmap), it's recommneded to include collecting roadmap proposals through public channels, and use more community fashion phrasing, which would encourage contributors to join the discussion and better understand whhere the project is heading to. +- TOC Reviewer recommends to update security policy to include an embargo and private disclosure period before doing public disclosure for security vulnerbilities. And tagging a release clearly as "security-fixes-only" will help users to prioritize an upgrade. ### Adoption Evaluation @@ -329,7 +332,8 @@ N/A - [x] **Tagging as stable, unstable, and security related releases** CubeFS uses beta to mark their unstable releases. Ref: [RELEASE.md#types-of-releases](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md#types-of-releases). - Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md) + + Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md). CubeFS doesn't have explict tagging rule for security releases. Though this is not required, tagging a release with "security-fixes-only" alike markers would be helpful for users to prioritize upgrades. - [x] **Information on branch and tag strategies** From 89ad92a122fd00833b4c4ab4a768861c6a1173c9 Mon Sep 17 00:00:00 2001 From: Emily Fox Date: Thu, 12 Dec 2024 17:47:01 -0500 Subject: [PATCH 16/60] What: Update TOC Due Diligence guide with recent changes cncf#1503 Why: * the TOC has fielded feedback from maintainers and TOC members, implemented changes to address issues, and needs to update our docs to reflect this. This change address the need by: * re-writing the triage to align with current process * calling out the adopter form for adopter interview collection * detail process for projects not yet ready to move * linking the adopter interview form in the process/README * updating process/README to inform on triaging and not-ready applications Signed-off-by: Emily Fox Signed-off-by: Lin Sun --- operations/dd-toc-guide.md | 99 +++++++++++++++++++++++++++++--------- process/README.md | 13 +++-- 2 files changed, 85 insertions(+), 27 deletions(-) diff --git a/operations/dd-toc-guide.md b/operations/dd-toc-guide.md index b53269926..71e070e66 100644 --- a/operations/dd-toc-guide.md +++ b/operations/dd-toc-guide.md @@ -2,6 +2,12 @@ This document provides the TOC with guidance on how to execute due diligence of CNCF projects for each level of maturity. It complements the Moving Levels process detailed in the [Process Directory](../process/README.md). +## Quick Links + +Getting Started: **[Triage applications](#initial-triageevaluation-prior-to-assignment)** | **[TOC Assignment](#toc-members-step-forward-to-be-assigned)** | **[Kick-off](#kicking-off-the-due-diligence)** +The Due Diligence (DD): **[Due Diligence](#completing-due-diligence)** | [**Finalizing DD](#finalizing-the-due-diligence)** | **[Adopter Interviews](#conducting-adopter-interviews)** +Wrapping it up: **[TOC internal review](#toc-internal-review)** | **[Public Comment](#public-comment-period)** | **[Voting](#voting)** + ## What is due diligence? Due diligence is the process by which the TOC performs an independent review of CNCF projects to assess their posture, maturity, and adoption across a variety of technical, governance, and community focuses. The intent of the due diligence is to provide project and adopters with an independent senior technical evaluation of a project's readiness for production. Similar to how organizations have established software development processes and check points prior to software delivery or deployment that ensure the software meets the organization's goals and objectives, the due diligence is a point in time artifact of the project's acheivement for meeting the goals and objectives expected for their maturity level. By performing the due diligence on CNCF projects, the TOC supports our adopters in gaining confidence that the project has been reviewed against documented criteria for their maturity level, can understand any deviations from those criteria, and may not need to repeat this type of evaluation, rather they may incorporate or leverage the contents of the due diligence to guide and information their decision making. It also conveys to adopters the potential level of effort in adopting and integrating the project into their archicture and infrastructure. For projects, the due diligence provides an evaluation of the project against the expectations of adopters across multiple focuses. It can and often will include additional recommendations to the project that may support them in reaching the next level of maturity, improving their documentation or architecture, and in some cases highlight opportunities to distinguish themselves and their features or functionality from other projects within the same area. @@ -32,13 +38,13 @@ Currently, there exist three levels in the CNCF: Projects not already in the Foundation may apply directly to Incubation if they feel they are ready. At this point of application, they undergo due diligence that also considers their fit in the CNCF, much the same as the considerations for inclusion of sandbox projects. -It is critical that TOC members strive to complete due diligence in a reasonable amount of time. The process involves multi-parties that requires coordination and clear communication of expectations. Delays in completing due diligence can create friction with projects and may encounter TOC member term endings, requiring project to start fresh with a new member. It is expected the process will take time, adopter interviews may be difficult to schedule in a timely fashion, so being upfront on these expectations is important. +It is critical that TOC members strive to complete due diligence in a reasonable amount of time. The process involves multi-parties that requires coordination and clear communication of expectations. Delays in completing due diligence can create friction with projects and may encounter TOC member term endings, requiring project to start fresh with a new member. It is expected the process will take time, adopter interviews may be difficult to schedule in a timely fashion, so being upfront on these expectations is important. **Each TOC member is expected to manage their project's application timeline to the best of their ability and reduce any delays where possible.** -Every TOC member is expected to conduct due diligence of CNCF projects. In cases where there may be a perceived conflict of interest, the due diligence must have two TOC members participating in order to dissolve any illusion of bias (for or against). +Every TOC member is expected to conduct due diligence of CNCF projects and triage those applications. In cases where there may be a perceived [conflict of interest](#conflicts-of-interest), the due diligence must have two TOC members participating in order to dissolve any illusion of bias (for or against). TOC members may not take on anymore than two (2) projects for due diligence at a given time unless one of the following conditions is true: * the TOC member is functioning as a guide to new TOC members learning this process -* the TOC member is has two projects in voting +* the TOC member has two projects in voting * the TOC member has one project in voting, and another in progress We expect all TOC members to be mindful of their obligations and timelines, whether they be work, cloud native, or personal and manage their workload accordingly. @@ -49,6 +55,57 @@ We expect all TOC members to be mindful of their obligations and timelines, whet The issue will contain a limited set of information about the project at the time of its application, commonly asserting its conformance to the stated criteria with links to where or descriptions as to how they are implemented. +### Initial triage/evaluation prior to assignment + +All TOC members are expected to assist in the triaging of project applications to move levels to ensure that when a TOC member is ready to be assigned, the project is ready to be evaluated with no immediate blockers that would inhibit or delay the TOC's engagement. + +This light-weight triage/evaluation must cover the list below (it is not exhaustive and is a minimum triage set from the [incubation template retrieved 12 DEC 2025](https://github.com/cncf/toc/blob/c2943ffc98064dd88e9ef9c4afd5a8856898942f/.github/ISSUE_TEMPLATE/template-incubation-application.md)): +* Adoption Assertion includes the Adopters file link, and the project has an entry in the Adopter's form responses to provide 5-7 adopters to reach out to. +* Application Process Principles provides + * the link to the Recording, issue, and/or meeting notes from a TAG meeting where the project presented with the domain specific TAG + * assertion of vendor neutrality + * assertion of review and acknowledge of expectations of CNCF projects and requirements for moving forward through the CNCF maturity levels + * provided any additional documentation links the project feels is appropriate for its type +* Governance and Maintainers provides + * link to the project's governance + * any notes on governance iteration + * Maintainers file is linked + * lists number of active maintainers + * link to or information regarding doc and code ownership + * link to the project's code of conduct (should link to CNCF CoC) + * link to CoC references in Governance docs (can be a link to governance only and we recommend linking in contributions as well) + * link to subproject listing, if applicable. +* Contributors and Community provides + * link to contributing file or other file that describes issues or change submissions (i.e. enhancement proposal process) + * link to file containing project communication channels + * links to information on community meetings, recordings, and/or notes + * link to the contributing file + * information on active contributors (i.e. quantity, contribution metrics, etc.) and documented efforts to attract more contributors (i.e. issues, presenting at conferences, slack messages, mailing lists, etc.) +* Engineering Principles + * link to information on the project goals and objectives, scan for the use cases or problems the project addresses + * link to information on supported use cases, what the project does, etc. + * link to roadmap, project board, or milestones + * link to project architecture diagram and documentation + * link to project release process +* Security + * link to joint assessment if available + * link to security.md, scan for a process to report issues + * link to (scorecard: scan for branch protection, token permissions, SAST, and CI best practices in results) or link to other evidence of repo hardening + * link to security report resolution process and roles + * link to completed or PR filed self-assessment + * link to best practices badge, confirm it is "passing" and 100% complete +* Ecosystem + * link to adopters file + * link to integrations/ compatibility information of other projects and products + + If some of the criteria are not yet met, or missing, the TOC member triaging will add a comment detailing all items that are unmet or missing and close the application; affixing the "not-ready" label and move the card to the "Not-Ready-Will Return" column of the [TOC project board](https://github.com/orgs/cncf/projects/27/views/9)'s Applications to Move levels tab. Projects are expected to re-apply upon completion of outstanding items. When the project is ready to reapply, they should link to the previous application so the TOC may leverage and reuse as much prior work as reasonable. + +Once the TOC has triaged the application and found all criteria to have content, the TOC member performing triage comment the application is complete and ready for assignment. The TOC member will affix the "ready" label and move the project from the "new" column on the application's board. The project's application will be updated by the TOC member with a comment that details where work still needs to be completed, next steps associated with completion of those, and an estimated timeframe that the project is likley to complete those items by. + +TOC members are expected to triage projects in the "new" column on the board for projects that are returning from a previous not-ready application, verify completion, and move them to the top of the ready for assignment column. + +TOC members are to priortize selecting projects from the ready for assignment column over the new column to expedite the queue and make the best use of TOC time. + ### TOC member(s) step forward to be assigned Commonly referred to as the Project's Application Sponsor, TOC members assign themselves to projects to sponsor the application for moving levels. Sponsoring an application ensures a focused point of contact exists for both the project and the TOC in completeing the Due Diligence, public comment, and execution of voting. @@ -75,19 +132,9 @@ A TOC member will require a co-sponsor for a project if any of the following con If a conflict of interest is present, the TOC member will state they have a conflict and seek a second sponsor on the project's application issue prior to proceeding. -### Initial evaluation - -Once the TOC member is assigned the project, they should perform a cursory, light-weight evaluation of the project's completion of the criteria. If some of the criteria are not yet met, or missing, the TOC should notify the project of the issues requiring resolution before re-applying, and once confirmed by the project, comment publicly on the Issue with those recommendations for resolution and close it. TOC members should use their best judgement in determining if the unmet criteria are simple fixes or if they require substantial effort or time to properly complete. For example, a project applying to graduation should have clear and discoverable governance documentation. If the TOC member cannot find any governance documentation at all, they should engage the project to confirm that none exists. If it does exist, but is not readily discoverable, the TOC member may continue to move forward with due diligence as improving discoverable may be resolved through appropriate linking. If it doesn't exist, the TOC should finish the lightweight review, capture all unmet criteria, engage the project on the findings, and relay the next steps. - -When the project is ready to reapply, they should link to the previous application so the TOC may leverage and reuse as much prior work as reasonable. - -Once the TOC member has conferred with the project, the project's application will be updated by the TOC member with a comment that details where work still needs to be completed, next steps associated with completion of those, and an estimated timeframe that the project is likley to complete those items by. Once the comment is added, the application may be closed, the "not-ready" label affixed, and the application moved to the "Not-Ready-Will Return" column of the [TOC project board](https://github.com/orgs/cncf/projects/27/views/9)'s Applications to Move levels tab. - -TOC members are expected to review this column on the board for projects that are returning from a previous not-ready application and select from here over the backlog to expedite the queue and make the best use of TOC time. - ### Kicking off the due diligence -Once the project is assigned a TOC member and the initial evaluation looks good to proceed, the TOC member engages the project's maintainers or leadership group to kick off the due diligence. This can be done by commenting on the Issue, starting a slack channel (public or private), slack group direct message, email exchange, or thread in the project's primary communication channel. We strive to keep these discussions transparent and visible but should consider any potential sensitive issues that come about as a result of the review (resolution of vulnerabilities for instance). +Once the project is assigned a TOC member, the TOC member engages the project's maintainers or leadership group to kick off the due diligence. This can be done by commenting on the Issue, starting a slack channel (public or private), slack group direct message, email exchange, or thread in the project's primary communication channel. We strive to keep these discussions transparent and visible but should consider any potential sensitive issues that come about as a result of the review (resolution of vulnerabilities for instance). TOC members, with support from CNCF staff, should schedule a meeting with the project to the extent possible given availability and timezones. Asynchrounous kick-offs can occur, but may result in additional back and forth or delays. Each Kick-off meeting should have a central kick-off document that allows the TOC and the project to capture expectations, decisions, timelines, and other pertinent references needed for successful completion of the due diligence. A [kick-off meeting template](toc-templates/template-kickoff-notes.md) is located in the [toc-templates](toc-templates/) folder. @@ -95,6 +142,8 @@ Once the Kick-off is scheduled, the TOC member should move the project's card on ### Completing Due Diligence +NOTE: the Due Diligence can be completed in conjuction with adopter interviews, some TOC members find completion of the DD as informative to conducting interviews, but not in all cases. + The TOC will use the appropriate Due Diligence for the project's applied level as the basis for a PR ([Incubation template](toc-templates/template-dd-pr-incubation.md), [Graduation template](toc-templates/template-dd-pr-graduation.md)) and will evaluate the project's assertions in the application issue against the discoverable and publically available sites, repos, files, and other artifacts of the project. The TOC's evaluation against each criteria goes in the corresponding area of the PR template. Previously, the project was responsible for completing the due diligence such that it allowed the TOC member to review and comment. Due to the extensive back and forth in this prior process and with recent changes to the criteria, the TOC has altered the process leverage a Due Diligence PR as the TOC's assessment of the projects completion of the criteria. Therefore TOC members are expected to complete the Due Diligence PR with support from the project and TAG(s). @@ -123,7 +172,7 @@ TOC members who sponsor projects seeking graduation are expected to review the r ### Finalizing the Due Diligence -When the TOC has finished their criteria evaluation, they should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Active Review & Discussion" and re-engage the project to elevate and discuss any items neededing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may copied into the kick-off document to faciliate discussion and to provide for additional context and discussion with the project until they are finalized. +When the TOC has finished their criteria evaluation, they should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews & Project Discussion" and re-engage the project to elevate and discuss any items neededing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may copied into the kick-off document to faciliate discussion and to provide for additional context and discussion with the project until they are finalized. The TOC member may then file the PR and place it in draft until the Adopter Interviews are completed. @@ -135,32 +184,34 @@ Feedback by the TAG is encouraged prior to Due diligence being initiated, as req ### Conducting Adopter Interviews -After the evaluation has incorporated project feedback and discussion, the TOC member may move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews" to begin outreach and scheduling with adopters. - In order to appropriately ascertain the adoption of a project, the TOC interviews a sampling of the project's adopters to understand how it is being used, what problems it is solving, the ease of adoption and integration, the community and contribution experience, and learn how adopters are experiencing the project's maturity level. -The TOC member should request 5-7 potential adopters to be interviewed and work with the TOC on gathering contact information for them. The TOC, with support from CNCF staff, is responsible for engaging adopters, gathering publication consent, scheduling, conducting, summarizing, gathering final approval, and including the approved summary of the interview within the Due Diligence. +The TOC member begin reaching out to the 5-7 potential adopters provided by the project to be interviewed and work with the TAB in conducting the interview. The TOC, with support from CNCF staff and the TAB, is responsible for engaging adopters, gathering publication consent, scheduling, conducting, summarizing, gathering final approval, and including the approved summary of the interview within the Due Diligence. The TOC maintains a core list of questions intended to initiate discussion with adopters, but may add additional questions, or skip questions depending on the course of the interview and the organization's level of comfort in providing responses. -Interviews typically do not take more than 30 minutes to complete, and TOC members should anticipate about 1 hour of time dedicated to summarizing adopter responses. +Interviews typically do not take more than 30 minutes to complete, and TOC and TAB members should anticipate about 1 hour of time dedicated to summarizing adopter responses. #### Reaching out to Adopters -Once a TOC member has a listing of potential interviewees, they should leverage the [Adopter Interview Request email template](/operations/toc-templates/template-adopter-interview-request.md) to engage. The email template provides the essential information needed for interviewers to coordinate with their marketing, PR, or other outreach team for approval and allows adopters the opportunity to remain anonymous. It is imperative that the TOC honor any anonymity concerns and work to address them with adopters, the final approval of the summarized response is a mechanism that allows us to confirm with the adopter their comfort and approval of the final content intended for publication and make any corrections they feel are warranted. +Once a TOC member has a listing of potential interviewees, they should leverage the [Adopter Interview Request email template](/operations/toc-templates/template-adopter-interview-request.md) to engage and include any TAB members interested in supporting the interview. The email template provides the essential information needed for interviewers to coordinate with their marketing, PR, or other outreach team for approval and allows adopters the opportunity to remain anonymous. + +It is imperative that the TOC honor any anonymity concerns and work to address them with adopters, the final approval of the summarized response is a mechanism that allows us to confirm with the adopter their comfort and approval of the final content intended for publication and make any corrections they feel are warranted. TOC members are free to bring in the Chair or Vice Chair to assist in addressing such concerns. To ease scheduling with Adopters, TOC members are recommended to either include set aside dates/times for adopters as part of the initial email, or to provide a scheduling link to expedite scheduling and avoid delay. -It is anticipated that a minimum of three adopter interviews are required to appropriately ascertain adoption of a project. However in the course of interviewing, you may find that you need additional adopters to be interviewed. +It is anticipated that a minimum of three adopter interviews are required to appropriately ascertain adoption of a project. However in the course of interviewing, you may find that you need additional adopters or types of adopters to be interviewed. For projects moving from Incubation to Graduation, if considerable time has passed since Incubation (according to the TOC's judgement), the TOC should refresh the Adopter interviews. This may be done by reaching out to previous interviewees, by engaging a new group of adopters for interviews, or some combination thereof. If the time period between Incubation and Graduation is fairly recent, the TOC member should exercise their judgement in choosing to pursue additional interviews. That decision should be recorded with justification in the adoption section of the template. #### Recording Responses -Adopter interviews are expected to be interactive. The [adopter questions template](toc-templates/template-adopter-questions.md) should serve as a starting point for questions when interviewing, however TOC members are expected to use their best judgement in asking questions, deep diving on responses, and crafting additional questions or skipping others. +**Adopter interviews are expected to be interactive**. The [adopter questions template](toc-templates/template-adopter-questions.md) should serve as a starting point for questions when interviewing, however TOC members are expected to use their best judgement in asking questions, deep diving on responses, and crafting additional questions or skipping others. You may need to record the meeting to fully capture the responses or take sufficient notes that you can summarize the discussion and convey, with enough breadth, how the adopter is using the project, what environments (such as dev, test, prod), their engagement with the project, use, experience, and future plans. +TOC and TAB members are NOT to email questions to adopters in order for them to write in their responses. If there is a language or time zone challenge, TOC members are expected to inform the broader TOC and seek assistance. + #### Summary Approval TOC members will summarize responses to the questions asked in a separate, non-public document until the Adopter approves the content. @@ -185,9 +236,9 @@ Evaluation summary is composed of two parts: the Criteria and the Adoption. The ## TOC Internal Review -Once the TOC member has completed the Due Diligence, the TOC member tags the TOC on the PR for an TOC internal review. The TOC member should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "TOC Review". +Once the TOC member has completed the Due Diligence, they should create a PR in their personal TOC repo and share the link with the TOC for review. The TOC member should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "TOC Review". -The TOC member should craft a slack message thread that provides the project name, level applied, links to the PR and issue, and thread any additional call outs, questions, or potential issues warranting further discussion not otherwise captured in the PR. The internal review is expected to last 1 week, assuming no issues are brought up. +The TOC member should craft a slack message thread that provides the project name, level applied, links to the PR and issue, and thread any additional call outs, questions, or potential issues warranting further discussion not otherwise captured in the PR. The internal review is expected to last 1 week, assuming no issues are brought up. The TOC member is responsible for updating the project with the change in status for internal review. diff --git a/process/README.md b/process/README.md index e964b4d52..5ff0bbbd8 100644 --- a/process/README.md +++ b/process/README.md @@ -43,10 +43,17 @@ While the details of the process are described in detail further for Incubating #### Applications to move levels are done by submitting an incubation or graduation [application issue](https://github.com/cncf/toc/issues/new/choose) on the TOC repo *Who: Project* -* Projects seeking to move to incubation should submit the Incubation Application issue and detail how they meet the incubation level criteria, existing incubating projects seeking to move to graduation should submit the Graduation Application issue and detail how they meet the graduation level criteria. -* As prior applications are closed, the TOC selects the next project from the backlog. +* Projects seeking to move to incubation should submit the Incubation Application issue and detail how they meet the incubation level criteria with links to evidence of implementation, existing incubating projects seeking to move to graduation should submit the Graduation Application issue and detail how they meet the graduation level criteria with links to evidence of implementation. +* **Project must complete the [Adopter Interview Form with 5-7 adopters willing to be interviewed](https://docs.google.com/forms/d/1n1oLC6IKj5-7S_xeEjIdEjbtS9SWniuAo7IIOyLFuK8/)**. +* As prior applications are closed, the TOC selects the next project from the "ready for assignment" column of the [TOC project board](https://github.com/orgs/cncf/projects/27/views/9)'s **Applications to Move levels** tab. -#### A TOC sponsor(s) is assigned and the project is moved to 'Due Diligence' or 'Active Review' on the project boards depending on which level is proposed. +#### The TOC triages project applications for completeness +*Who: TOC* + +* Project applications that are found to be incomplete will be commented with the outstanding areas to be completed, closed, and moved to Not Ready- Will return in the [TOC project board](https://github.com/orgs/cncf/projects/27/views/9)'s **Applications to Move levels** tab. +* When a project has completed all outstanding areas, the project can re-apply, link to the previous application, and reuse any previous content as appropriate. + +#### A TOC sponsor(s) is assigned and the project is moved to 'TOC DD Eval' on the project board *Who: TOC* #### Application Kick off Meeting is scheduled and held From 554c6f34bfaf5509743f5a0bf573f1fdc24c80fa Mon Sep 17 00:00:00 2001 From: Emily Fox Date: Fri, 13 Dec 2024 14:36:52 -0500 Subject: [PATCH 17/60] What: add @dims comments Signed-off-by: Emily Fox Signed-off-by: Lin Sun --- operations/dd-toc-guide.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/operations/dd-toc-guide.md b/operations/dd-toc-guide.md index 71e070e66..1614ce4df 100644 --- a/operations/dd-toc-guide.md +++ b/operations/dd-toc-guide.md @@ -4,8 +4,10 @@ This document provides the TOC with guidance on how to execute due diligence of ## Quick Links -Getting Started: **[Triage applications](#initial-triageevaluation-prior-to-assignment)** | **[TOC Assignment](#toc-members-step-forward-to-be-assigned)** | **[Kick-off](#kicking-off-the-due-diligence)** -The Due Diligence (DD): **[Due Diligence](#completing-due-diligence)** | [**Finalizing DD](#finalizing-the-due-diligence)** | **[Adopter Interviews](#conducting-adopter-interviews)** +Getting Started: **[Triage applications](#initial-triageevaluation-prior-to-assignment)** | **[TOC Assignment](#toc-members-step-forward-to-be-assigned)** | **[Kick-off](#kicking-off-the-due-diligence)** + +The Due Diligence (DD): **[Due Diligence](#completing-due-diligence)** | **[Finalizing DD](#finalizing-the-due-diligence)** | **[Adopter Interviews](#conducting-adopter-interviews)** + Wrapping it up: **[TOC internal review](#toc-internal-review)** | **[Public Comment](#public-comment-period)** | **[Voting](#voting)** ## What is due diligence? @@ -100,7 +102,7 @@ This light-weight triage/evaluation must cover the list below (it is not exhaust If some of the criteria are not yet met, or missing, the TOC member triaging will add a comment detailing all items that are unmet or missing and close the application; affixing the "not-ready" label and move the card to the "Not-Ready-Will Return" column of the [TOC project board](https://github.com/orgs/cncf/projects/27/views/9)'s Applications to Move levels tab. Projects are expected to re-apply upon completion of outstanding items. When the project is ready to reapply, they should link to the previous application so the TOC may leverage and reuse as much prior work as reasonable. -Once the TOC has triaged the application and found all criteria to have content, the TOC member performing triage comment the application is complete and ready for assignment. The TOC member will affix the "ready" label and move the project from the "new" column on the application's board. The project's application will be updated by the TOC member with a comment that details where work still needs to be completed, next steps associated with completion of those, and an estimated timeframe that the project is likley to complete those items by. +Once the TOC has triaged the application and found all criteria to have content, the TOC member performing triage comment the application is complete and ready for assignment. The TOC member will affix the "ready" label and move the project from the "new" column on the application's board. The project's application will be updated by the TOC member with a comment that details where work still needs to be completed, next steps associated with completion of those, and an estimated timeframe that the project is likely to complete those items by. TOC members are expected to triage projects in the "new" column on the board for projects that are returning from a previous not-ready application, verify completion, and move them to the top of the ready for assignment column. @@ -134,11 +136,11 @@ If a conflict of interest is present, the TOC member will state they have a conf ### Kicking off the due diligence -Once the project is assigned a TOC member, the TOC member engages the project's maintainers or leadership group to kick off the due diligence. This can be done by commenting on the Issue, starting a slack channel (public or private), slack group direct message, email exchange, or thread in the project's primary communication channel. We strive to keep these discussions transparent and visible but should consider any potential sensitive issues that come about as a result of the review (resolution of vulnerabilities for instance). +Once the project is assigned to the TOC member(s), the TOC member(s) engages the project's maintainers or leadership group to kick off the due diligence. This can be done by commenting on the Issue, starting a slack channel (public or private), slack group direct message, email exchange, or thread in the project's primary communication channel. We strive to keep these discussions transparent and visible but should consider any potential sensitive issues that come about as a result of the review (resolution of vulnerabilities for instance). TOC members, with support from CNCF staff, should schedule a meeting with the project to the extent possible given availability and timezones. Asynchrounous kick-offs can occur, but may result in additional back and forth or delays. Each Kick-off meeting should have a central kick-off document that allows the TOC and the project to capture expectations, decisions, timelines, and other pertinent references needed for successful completion of the due diligence. A [kick-off meeting template](toc-templates/template-kickoff-notes.md) is located in the [toc-templates](toc-templates/) folder. -Once the Kick-off is scheduled, the TOC member should move the project's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "In Due Diligence". It is *strongly* recommended that you inform the project to verify compliance with the CNCF's licensing policy (set forth in the [Section 11 of the Charter](https://github.com/cncf/foundation/blob/master/charter.md) with [additional information here](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md)). +Once the Kick-off is scheduled, the TOC member(s) should move the project's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "In Due Diligence". It is *strongly* recommended that you inform the project to verify compliance with the CNCF's licensing policy (set forth in the [Section 11 of the Charter](https://github.com/cncf/foundation/blob/master/charter.md) with [additional information here](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md)). ### Completing Due Diligence @@ -146,13 +148,13 @@ NOTE: the Due Diligence can be completed in conjuction with adopter interviews, The TOC will use the appropriate Due Diligence for the project's applied level as the basis for a PR ([Incubation template](toc-templates/template-dd-pr-incubation.md), [Graduation template](toc-templates/template-dd-pr-graduation.md)) and will evaluate the project's assertions in the application issue against the discoverable and publically available sites, repos, files, and other artifacts of the project. The TOC's evaluation against each criteria goes in the corresponding area of the PR template. -Previously, the project was responsible for completing the due diligence such that it allowed the TOC member to review and comment. Due to the extensive back and forth in this prior process and with recent changes to the criteria, the TOC has altered the process leverage a Due Diligence PR as the TOC's assessment of the projects completion of the criteria. Therefore TOC members are expected to complete the Due Diligence PR with support from the project and TAG(s). +Previously, the project was responsible for completing the due diligence such that it allowed the TOC member(s) to review and comment. Due to the extensive back and forth in this prior process and with recent changes to the criteria, the TOC has altered the process leverage a Due Diligence PR as the TOC's assessment of the projects completion of the criteria. Therefore TOC members are expected to complete the Due Diligence PR with support from the project and TAG(s). -As the TOC member reviews the criteria, any deviations or implementation notes from the review should be recorded within the due diligence PR as part of their evaluation for that specific criteria. The TOC member will provide an overall evaluation statement that summarizes the content of the due diligence once the Adopter Interview Summaries are recorded. For more information on adopter interviews, refer to [Conducting Adopter Interviews](#conducting-adopter-interviews). +As the TOC member(s) reviews the criteria, any deviations or implementation notes from the review should be recorded within the due diligence PR as part of their evaluation for that specific criteria. The TOC member will provide an overall evaluation statement that summarizes the content of the due diligence once the Adopter Interview Summaries are recorded. For more information on adopter interviews, refer to [Conducting Adopter Interviews](#conducting-adopter-interviews). -As an example, let's say a project is asserting their sub-projects have leadership, contribution information, maturity statuses, and add/removal processes. The TOC member, in confirming this may determine that the sub-projects share the same contributor file on the org's evolution directory and may change the maturity level in accordance with their documented process, but the process is not clear as to what initiates that change or who. For a sandbox project seeking incubation, this may be non-blocking but the TOC may recommend the project improve the documented process. As such, the TOC member will record their finding and corresponding recommendation. +As an example, let's say a project is asserting their sub-projects have leadership, contribution information, maturity statuses, and add/removal processes. The TOC member(s), in confirming this may determine that the sub-projects share the same contributor file on the org's evolution directory and may change the maturity level in accordance with their documented process, but the process is not clear as to what initiates that change or who. For a sandbox project seeking incubation, this may be non-blocking but the TOC may recommend the project improve the documented process. As such, the TOC member(s) will record their finding and corresponding recommendation. -Another example, if the TOC member is looking over the project's stated goals and objectives that have not changed since the project was accepted into the CNCF, and they are now applying to Graduate, the TOC member will ask the project to clarify or provide additional information as to why the project hasn't iniatiated any changes and if they still feel those goals and objectives are accurate for the future of the project. The TOC member will then summarize the response and record it in the PR under the corresponding criteria evaluation. +Another example, if the TOC member(s) is looking over the project's stated goals and objectives that have not changed since the project was accepted into the CNCF, and they are now applying to Graduate, the TOC member(s) will ask the project to clarify or provide additional information as to why the project hasn't iniatiated any changes and if they still feel those goals and objectives are accurate for the future of the project. The TOC member(s) will then summarize the response and record it in the PR under the corresponding criteria evaluation. It is expected that the TOC's evaluation of a project's completion of the criteria may reveal a mismatch in understanding or an unexpected implementation. Documenting the TOC evaluation in the Due Diligence PR provides the project, TAGs, community, adopters, and TOC with a point of reference to understand if the criteria are meeting the outcomes required of a project for a certain maturity level, or if compensating mechanisms that supplement or augment the criteria are in place that work best for that specific project. @@ -174,7 +176,7 @@ TOC members who sponsor projects seeking graduation are expected to review the r When the TOC has finished their criteria evaluation, they should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews & Project Discussion" and re-engage the project to elevate and discuss any items neededing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may copied into the kick-off document to faciliate discussion and to provide for additional context and discussion with the project until they are finalized. -The TOC member may then file the PR and place it in draft until the Adopter Interviews are completed. +The TOC member(s) may then file the PR and place it in draft until the Adopter Interviews are completed. #### Engaging TAGs @@ -186,7 +188,7 @@ Feedback by the TAG is encouraged prior to Due diligence being initiated, as req In order to appropriately ascertain the adoption of a project, the TOC interviews a sampling of the project's adopters to understand how it is being used, what problems it is solving, the ease of adoption and integration, the community and contribution experience, and learn how adopters are experiencing the project's maturity level. -The TOC member begin reaching out to the 5-7 potential adopters provided by the project to be interviewed and work with the TAB in conducting the interview. The TOC, with support from CNCF staff and the TAB, is responsible for engaging adopters, gathering publication consent, scheduling, conducting, summarizing, gathering final approval, and including the approved summary of the interview within the Due Diligence. +The TOC member(s) begin reaching out to the 5-7 potential adopters provided by the project to be interviewed and work with the TAB in conducting the interview. The TOC, with support from CNCF staff and the TAB, is responsible for engaging adopters, gathering publication consent, scheduling, conducting, summarizing, gathering final approval, and including the approved summary of the interview within the Due Diligence. The TOC maintains a core list of questions intended to initiate discussion with adopters, but may add additional questions, or skip questions depending on the course of the interview and the organization's level of comfort in providing responses. @@ -202,7 +204,7 @@ To ease scheduling with Adopters, TOC members are recommended to either include It is anticipated that a minimum of three adopter interviews are required to appropriately ascertain adoption of a project. However in the course of interviewing, you may find that you need additional adopters or types of adopters to be interviewed. -For projects moving from Incubation to Graduation, if considerable time has passed since Incubation (according to the TOC's judgement), the TOC should refresh the Adopter interviews. This may be done by reaching out to previous interviewees, by engaging a new group of adopters for interviews, or some combination thereof. If the time period between Incubation and Graduation is fairly recent, the TOC member should exercise their judgement in choosing to pursue additional interviews. That decision should be recorded with justification in the adoption section of the template. +For projects moving from Incubation to Graduation, if considerable time has passed since Incubation (according to the TOC's judgement), the TOC should refresh the Adopter interviews. This may be done by reaching out to previous interviewees, by engaging a new group of adopters for interviews, or some combination thereof. If the time period between Incubation and Graduation is fairly recent, the TOC member(s) should exercise their judgement in choosing to pursue additional interviews. That decision should be recorded with justification in the adoption section of the template. #### Recording Responses @@ -236,19 +238,19 @@ Evaluation summary is composed of two parts: the Criteria and the Adoption. The ## TOC Internal Review -Once the TOC member has completed the Due Diligence, they should create a PR in their personal TOC repo and share the link with the TOC for review. The TOC member should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "TOC Review". +Once the TOC member(s) has completed the Due Diligence, they should create a PR in their personal TOC repo and share the link with the TOC for review. The TOC member(s) should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "TOC Review". -The TOC member should craft a slack message thread that provides the project name, level applied, links to the PR and issue, and thread any additional call outs, questions, or potential issues warranting further discussion not otherwise captured in the PR. The internal review is expected to last 1 week, assuming no issues are brought up. +The TOC member(s) should craft a slack message thread that provides the project name, level applied, links to the PR and issue, and thread any additional call outs, questions, or potential issues warranting further discussion not otherwise captured in the PR. The internal review is expected to last 1 week, assuming no issues are brought up. -The TOC member is responsible for updating the project with the change in status for internal review. +The TOC member(s) is responsible for updating the project with the change in status for internal review. ### Reapplication -In the event a project was not ready to move levels after the due diligence was completed and the project has reapplied through an issue, the previous or new TOC member assigned will initiate a new Due Diligence based on the previous one. The TOC should refresh the prior evaluations with corresponding dates to show changes and improvements and ammend the evaluation statements accordingly. +In the event a project was not ready to move levels after the due diligence was completed and the project has reapplied through an issue, the previous or new TOC member(s) assigned will initiate a new Due Diligence based on the previous one. The TOC should refresh the prior evaluations with corresponding dates to show changes and improvements and ammend the evaluation statements accordingly. ## Public Comment Period -Assuming no issues have come up during the TOC internal review, the TOC member may put the due diligence out for public comment. The TOC member should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Public Comment". +Assuming no issues have come up during the TOC internal review, the TOC member may put the due diligence out for public comment. The TOC member(s) should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Public Comment". TOC members are to leverage the [public comment template](toc-templates/template-dd-public-comment.md) and be mindful of the timeline to consider if a freeze is in effect or soon will be. All public comment messages are to be sent on the [TOC public mailing list](https://lists.cncf.io/g/cncf-toc/topics). Once sent, they should be linked on the PR and the project notified. From d3d3509cf1757e75ba32d8b723b7d4c50d271d92 Mon Sep 17 00:00:00 2001 From: lianmakesthings Date: Thu, 12 Dec 2024 13:03:45 +0100 Subject: [PATCH 18/60] update App Delivery leadership team Signed-off-by: lianmakesthings Signed-off-by: Lin Sun --- tags/cncf-tags.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tags/cncf-tags.md b/tags/cncf-tags.md index 649509b33..60a37926d 100644 --- a/tags/cncf-tags.md +++ b/tags/cncf-tags.md @@ -29,15 +29,14 @@ TOC and TOC Contributors have fulfilled TAG duties in the past and will continue | Name | |-----------------------| | [Lian Li](https://github.com/lianmakesthings) | -| [Josh Gavant](https://github.com/joshgav) | -| [Thomas Schuetz](https://github.com/thschue) | +| [Roberth Strand](https://github.com/roberthstrand) | #### Tech Leads | Name | |-----------------------| -| [Alois Reitbauer](https://github.com/AloisReitbauer) | -| [Roberth Strand](https://github.com/roberthstrand) | +| [Sarah Christoff](https://github.com/schristoff) | +| [Dylan Page](https://github.com/GenPage) | ### TAG Contributor Strategy From 874b26c930ec6a0f28199b077d60c8666597afea Mon Sep 17 00:00:00 2001 From: leonrayang Date: Sat, 5 Aug 2023 15:19:27 +0800 Subject: [PATCH 19/60] Proposing CubeFS for graduation Signed-off-by: leonrayang Signed-off-by: Lin Sun --- projects/cubefs/cubefs-graduation-proposal.md | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 projects/cubefs/cubefs-graduation-proposal.md diff --git a/projects/cubefs/cubefs-graduation-proposal.md b/projects/cubefs/cubefs-graduation-proposal.md new file mode 100644 index 000000000..61dd99ee1 --- /dev/null +++ b/projects/cubefs/cubefs-graduation-proposal.md @@ -0,0 +1,47 @@ +# CubeFS Graduation Proposal +CubeFS, an open-source project that joined CNCF as a sandbox project in December 2019, has made remarkable progress since then. With its growing community of contributors and users including big names like Oppo, JD, Xiaomi, NetEase, and BIGO, CubeFS has already scaled up to hundreds of petabytes (PB+). As of July 2022, CubeFS has become an incubating project and we are confident that it is now ready to graduate. +## Introduction + +[CubeFS](https://cubefs.io) is a cloud-native storage product that was introduced to the CNCF storage SIG in June 2019. It offers shared storage solutions for various applications and is widely used in scenarios such as AI, big data, and database management. CubeFS boasts several key features that make it a reliable option for users + +**Multi-Protocol Interoperability** By unifying access to multiple protocols such as HDFS, POSIX, and S3, it enables one set of data to be accessed in multiple protocols , avoiding the need to copy data between different access approaches. + +**Multi-Engine Support** CubeFS supports two storage engines, multiple copies and erasure coding, and has made a lot of multidimensional optimizations for these engines. This enables the flexibly to meet the demands of different business scenarios for IO performance and storage cost. + +**Strong Scalability** The metadata of CubeFS has horizontal scalability, and a single cluster can easily support billions of files and exabytes of storage capacity. +**High Performance** It supports multi-level caching, delicated optimizations for small files, and various high-performance replication protocols. + +**Multi-tenancy** CubeFS provides multi-tenant management and achieves access isolation and performance non-interference between tenants through namespace management and QoS. + +**Cloud-Native** CubeFS can be easily deployed, run, and upgraded on Kubernetes . With the CSI plugin, PODs can easily access storage volumes. + +## Graduation State Criteria +#### Have committers from at least two organizations +* [OPPO](https://www.oppo.com/cn/) Consumer electronics and mobile communications company. It uses CubeFS to support its cloud platform and diverse customers running on it. +* [JD.com](https://www.jd.com) Top e-commerce company in China. It has the largest CubeFS cluster of all adopters, and uses CubeFS to provide storage solutions to its containerized applications in a large scale Kubernetes cluster, and to withstand an overwhelming data flow during sales promotions. +* [BIGO](https://www.bigo.tv/) It uses CubeFS to store logs for AI platform applications that running in the container environment, because CubeFS have excellent concurrent processing capability. +* [Xiaomi Corporation](https://www.mi.com/c/about) It uses CubeFS to serve various applications such as AI, Big Data, shared file system and so on. +* [Netease game company](http://www.netease.com/) It uses CubeFS to support Elasticsearch and AI machine learning business. +#### Have achieved and maintained a Core Infrastructure Initiative [Best Practices Badge](https://bestpractices.coreinfrastructure.org/projects/6232) +* CubeFS‘s OpenSSF badge can be seen in Best Practices Badge. + +#### Have completed an independent and third party security audit with results published of similar scope and quality as this example which includes all critical vulnerabilities and all critical vulnerabilities need to be addressed before graduation +* The security audit has been initiated by OSTIF and is in progress. + +#### Explicitly define a project governance and committer process. The committer process should cover the full committer lifecycle including onboarding and offboarding or emeritus criteria. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers +* The CubeFS project governance is defined in the [GOVERNANCE](https://github.com/cubefs/cubefs/blob/master/GOVERNANCE.md). + +#### Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence + +* How to participate in the CubeFS project is defined in [CONTRIBUTING](https://github.com/cubefs/cubefs/blob/master/CONTRIBUTING.md) ,The list of maintainers has been stored in [MAINTAINERS](https://github.com/cubefs/cubefs/blob/master/MAINTAINERS.md). + +#### Have a public list of Project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the Project website). For a specification, have a list of adopters for the implementation(s) of the spec. Refer to FAQs for guidelines on identifying adopters +* The CubeFS project has a public list of Project adopter which is maintained in [ADOPTERS](https://github.com/cubefs/cubefs/blob/master/ADOPTERS.md). + +## Incubation Details +#### Link to Incubation Due Diligence(DD) Document +* [Incubation proposal](https://github.com/cncf/toc/pull/586) +* [CubeFS Due Diligence](https://docs.google.com/document/d/1WDJEeRDO8pHAetyCbU7TftZfvxSATc3bsLj7VJeNoJ0/edit#heading=h.560y4815aj5r) +#### Address any concerns or recommendations from the TAG and/or TOC sponsor(s) from the DD Document +* There are currently no known outstanding concerns or recommendations regarding +the CubeFS project. From 083b109abe629afe80f59542913512ccc2a79e1e Mon Sep 17 00:00:00 2001 From: Bob Killen Date: Wed, 18 Dec 2024 11:48:34 -0600 Subject: [PATCH 20/60] move cubefs docs to correct directory Signed-off-by: Bob Killen Signed-off-by: Lin Sun --- projects/{chubaofs => cubefs}/cubefs-adopter-interview-beike.md | 0 projects/{chubaofs => cubefs}/cubefs-adopter-interview-jd.com.md | 0 projects/{chubaofs => cubefs}/cubefs-adopter-interview-netease.md | 0 projects/{chubaofs => cubefs}/cubefs-graduation-dd.md | 0 4 files changed, 0 insertions(+), 0 deletions(-) rename projects/{chubaofs => cubefs}/cubefs-adopter-interview-beike.md (100%) rename projects/{chubaofs => cubefs}/cubefs-adopter-interview-jd.com.md (100%) rename projects/{chubaofs => cubefs}/cubefs-adopter-interview-netease.md (100%) rename projects/{chubaofs => cubefs}/cubefs-graduation-dd.md (100%) diff --git a/projects/chubaofs/cubefs-adopter-interview-beike.md b/projects/cubefs/cubefs-adopter-interview-beike.md similarity index 100% rename from projects/chubaofs/cubefs-adopter-interview-beike.md rename to projects/cubefs/cubefs-adopter-interview-beike.md diff --git a/projects/chubaofs/cubefs-adopter-interview-jd.com.md b/projects/cubefs/cubefs-adopter-interview-jd.com.md similarity index 100% rename from projects/chubaofs/cubefs-adopter-interview-jd.com.md rename to projects/cubefs/cubefs-adopter-interview-jd.com.md diff --git a/projects/chubaofs/cubefs-adopter-interview-netease.md b/projects/cubefs/cubefs-adopter-interview-netease.md similarity index 100% rename from projects/chubaofs/cubefs-adopter-interview-netease.md rename to projects/cubefs/cubefs-adopter-interview-netease.md diff --git a/projects/chubaofs/cubefs-graduation-dd.md b/projects/cubefs/cubefs-graduation-dd.md similarity index 100% rename from projects/chubaofs/cubefs-graduation-dd.md rename to projects/cubefs/cubefs-graduation-dd.md From 8764fc38d7b6f24f83d2853b61e4a84949004d44 Mon Sep 17 00:00:00 2001 From: Emily Fox Date: Fri, 20 Dec 2024 10:19:25 -0500 Subject: [PATCH 21/60] What: incorporate @angellk 's comments Signed-off-by: Emily Fox Signed-off-by: Lin Sun --- operations/dd-toc-guide.md | 27 ++++++++++++++++++--------- process/README.md | 6 ++++++ 2 files changed, 24 insertions(+), 9 deletions(-) diff --git a/operations/dd-toc-guide.md b/operations/dd-toc-guide.md index 1614ce4df..d153da956 100644 --- a/operations/dd-toc-guide.md +++ b/operations/dd-toc-guide.md @@ -46,6 +46,7 @@ Every TOC member is expected to conduct due diligence of CNCF projects and triag TOC members may not take on anymore than two (2) projects for due diligence at a given time unless one of the following conditions is true: * the TOC member is functioning as a guide to new TOC members learning this process +* the TOC member is serving as a secondary to the primary TOC member conducting a due diligence in order to offer additional domain support or other relevant subject matter expertise * the TOC member has two projects in voting * the TOC member has one project in voting, and another in progress @@ -64,7 +65,7 @@ All TOC members are expected to assist in the triaging of project applications t This light-weight triage/evaluation must cover the list below (it is not exhaustive and is a minimum triage set from the [incubation template retrieved 12 DEC 2025](https://github.com/cncf/toc/blob/c2943ffc98064dd88e9ef9c4afd5a8856898942f/.github/ISSUE_TEMPLATE/template-incubation-application.md)): * Adoption Assertion includes the Adopters file link, and the project has an entry in the Adopter's form responses to provide 5-7 adopters to reach out to. * Application Process Principles provides - * the link to the Recording, issue, and/or meeting notes from a TAG meeting where the project presented with the domain specific TAG + * Either: the link to the Recording, issue, and/or meeting notes from a TAG meeting where the project presented with the domain specific TAG -or- completion of the [General Technical Review (GTR)](../tags/resources/toc-supporting-guides/general-technical-questions.md) or [Domain Technical Review (DTR)](../tags/resources/toc-supporting-guides/tag-domain-technical-review-template.md) in lieu of a TAG meeting * assertion of vendor neutrality * assertion of review and acknowledge of expectations of CNCF projects and requirements for moving forward through the CNCF maturity levels * provided any additional documentation links the project feels is appropriate for its type @@ -100,7 +101,9 @@ This light-weight triage/evaluation must cover the list below (it is not exhaust * link to adopters file * link to integrations/ compatibility information of other projects and products - If some of the criteria are not yet met, or missing, the TOC member triaging will add a comment detailing all items that are unmet or missing and close the application; affixing the "not-ready" label and move the card to the "Not-Ready-Will Return" column of the [TOC project board](https://github.com/orgs/cncf/projects/27/views/9)'s Applications to Move levels tab. Projects are expected to re-apply upon completion of outstanding items. When the project is ready to reapply, they should link to the previous application so the TOC may leverage and reuse as much prior work as reasonable. +Projects should NOT be blocked if they do not have a Governance Review or a GTR/DTR completed. Both the Governance review and GTR/DTRs depend on the availability of our community members in our TAGs which cannot be guaranteed. + +If some of the criteria are not yet met, or missing, the TOC member triaging will add a comment detailing all items that are unmet or missing and close the application; affixing the "not-ready" label and move the card to the "Not-Ready-Will Return" column of the [TOC project board](https://github.com/orgs/cncf/projects/27/views/9)'s Applications to Move levels tab. Projects are expected to re-apply upon completion of outstanding items. When the project is ready to reapply, they should link to the previous application so the TOC may leverage and reuse as much prior work as reasonable. Once the TOC has triaged the application and found all criteria to have content, the TOC member performing triage comment the application is complete and ready for assignment. The TOC member will affix the "ready" label and move the project from the "new" column on the application's board. The project's application will be updated by the TOC member with a comment that details where work still needs to be completed, next steps associated with completion of those, and an estimated timeframe that the project is likely to complete those items by. @@ -110,7 +113,9 @@ TOC members are to priortize selecting projects from the ready for assignment co ### TOC member(s) step forward to be assigned -Commonly referred to as the Project's Application Sponsor, TOC members assign themselves to projects to sponsor the application for moving levels. Sponsoring an application ensures a focused point of contact exists for both the project and the TOC in completeing the Due Diligence, public comment, and execution of voting. +Commonly referred to as the Project's Application Sponsor, TOC members assign themselves to projects to sponsor the application for moving levels. Sponsoring an application ensures a focused point of contact exists for both the project and the TOC in completing the Due Diligence, public comment, and execution of voting. + +The TOC member that assigns themselves a project to sponsor the application for moving levels may request a secondary TOC member to support the due diligence according to eligibility. TOC members ready to perform due diligence a project's application will socialize this internally with the TOC to provide opportunity for other members to participate. Once a TOC member or members is determined, those TOC members must assign themselves to the Issue and move the issue's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Assigned". @@ -132,11 +137,13 @@ A TOC member will require a co-sponsor for a project if any of the following con This does not mean they can't have any involvement with a project at all as contributing to pull requests or adopting the project are signals of a healthy interest and knowledge of the project. To ensure appropriate evaluation without bias, a second, unconflicted TOC member must be assigned to co-sponsor the project with them. -If a conflict of interest is present, the TOC member will state they have a conflict and seek a second sponsor on the project's application issue prior to proceeding. +If a conflict of interest is present, the TOC member will state they have a conflict and seek a second _primary_ sponsor on the project's application issue prior to proceeding. ### Kicking off the due diligence -Once the project is assigned to the TOC member(s), the TOC member(s) engages the project's maintainers or leadership group to kick off the due diligence. This can be done by commenting on the Issue, starting a slack channel (public or private), slack group direct message, email exchange, or thread in the project's primary communication channel. We strive to keep these discussions transparent and visible but should consider any potential sensitive issues that come about as a result of the review (resolution of vulnerabilities for instance). +Once the project is assigned to the TOC member(s), the TOC member(s) engages the project's maintainers or leadership group to kick off the due diligence. This can be done by commenting on the Issue, starting a slack channel (public or private), slack group direct message, email exchange, or thread in the project's primary communication channel. We strive to keep these discussions transparent and visible but should consider any potential sensitive issues that come about as a result of the review (resolution of vulnerabilities for instance). + +Any form of communication must include _two members_ of CNCF staff to ensure consistency and continuity throughout the process. TOC members, with support from CNCF staff, should schedule a meeting with the project to the extent possible given availability and timezones. Asynchrounous kick-offs can occur, but may result in additional back and forth or delays. Each Kick-off meeting should have a central kick-off document that allows the TOC and the project to capture expectations, decisions, timelines, and other pertinent references needed for successful completion of the due diligence. A [kick-off meeting template](toc-templates/template-kickoff-notes.md) is located in the [toc-templates](toc-templates/) folder. @@ -174,7 +181,7 @@ TOC members who sponsor projects seeking graduation are expected to review the r ### Finalizing the Due Diligence -When the TOC has finished their criteria evaluation, they should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews & Project Discussion" and re-engage the project to elevate and discuss any items neededing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may copied into the kick-off document to faciliate discussion and to provide for additional context and discussion with the project until they are finalized. +When the TOC has finished their criteria evaluation, they should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews & Project Discussion" and re-engage the project to elevate and discuss any items neededing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may be copied into the kick-off document to faciliate discussion and to provide for additional context and discussion with the project until they are finalized. The TOC member(s) may then file the PR and place it in draft until the Adopter Interviews are completed. @@ -190,9 +197,11 @@ In order to appropriately ascertain the adoption of a project, the TOC interview The TOC member(s) begin reaching out to the 5-7 potential adopters provided by the project to be interviewed and work with the TAB in conducting the interview. The TOC, with support from CNCF staff and the TAB, is responsible for engaging adopters, gathering publication consent, scheduling, conducting, summarizing, gathering final approval, and including the approved summary of the interview within the Due Diligence. -The TOC maintains a core list of questions intended to initiate discussion with adopters, but may add additional questions, or skip questions depending on the course of the interview and the organization's level of comfort in providing responses. +Projects should not coach or instruct adopters with answers to interview questions and may encourage adopters to be open and transparent during the interviews. All interview notes are kept private unless permission is received from the adopter's organization for the notes to be made public. + +The TOC maintains a [core list of questions](/operations/toc-templates/template-adopter-questions.md) intended to initiate discussion with adopters, but may add additional questions, or skip questions depending on the course of the interview and the organization's level of comfort in providing responses. -Interviews typically do not take more than 30 minutes to complete, and TOC and TAB members should anticipate about 1 hour of time dedicated to summarizing adopter responses. +Interviews typically do not take more than 30-60 minutes to complete, and TOC and TAB members should anticipate about 1 hour of time dedicated to summarizing adopter responses. Some interviews may take more or less time, it is dependent upon the interview, any prior interviews that may introduce conflicting stories among adopters, or other concerns noted by the TOC members and the community. #### Reaching out to Adopters @@ -246,7 +255,7 @@ The TOC member(s) is responsible for updating the project with the change in sta ### Reapplication -In the event a project was not ready to move levels after the due diligence was completed and the project has reapplied through an issue, the previous or new TOC member(s) assigned will initiate a new Due Diligence based on the previous one. The TOC should refresh the prior evaluations with corresponding dates to show changes and improvements and ammend the evaluation statements accordingly. +In the event a project was not ready to move levels after the due diligence was completed and the project has reapplied through an issue, the previous or new TOC member(s) assigned will initiate a new Due Diligence based on the previous one. The TOC should refresh the prior evaluations with corresponding dates to show changes and improvements and amend the evaluation statements accordingly. ## Public Comment Period diff --git a/process/README.md b/process/README.md index 5ff0bbbd8..be1ebfd94 100644 --- a/process/README.md +++ b/process/README.md @@ -27,6 +27,12 @@ Evaluting projects against the criteria does take some time and the TOC has rece The TOC, with support from the [Technical Advisory Groups](/tags/README.md), have a wide variety of resources available to assist projects. Current and aspiring maintainers of cloud native projects can find a lot of information and templates on [contribute.cncf.io/maintainers](https://contribute.cncf.io/maintainers/). The TOC also maintains [project Guide Posts](../docs/project_guideposts.md) - a collection of guiding points that have assisted cloud native projects as they grow and mature in the ecosystem. These are not requirements for moving levels, those may be found in the respective application issue templates ([Incubation](../.github/ISSUE_TEMPLATE/template-incubation-application.md), [Graduation](../.github/ISSUE_TEMPLATE/template-graduation-application.md)). The [Guide Posts](../docs/project_guideposts.md) are a resources for projects to leverage that is beneficial in meeting or exceeding the criteria defined. +Additionally, projects interested in preparing to apply to move levels are encouraged to pursue the following activities as the resulting artifacts can and often are leveraged in the TOC's completion of the Due Diligence in lieu of certain sections of the DD. + +* Pursue a [Goverance Review with TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy/issues/new?template=governance-review-request.yaml) - A governance review is an indepth look at how your project is governed, its documentation, its practices, and general project operations. For more information please [checkout the maintainer page on governance](https://contribute.cncf.io/maintainers/governance/overview/) or join the [Governance Review Group](https://github.com/cncf/tag-contributor-strategy/tree/main/governance). +* Complete a [General Technical Review (GTR)](../tags/resources/toc-supporting-guides/general-technical-questions.md) or [Domain Technical Review (DTR)](../tags/resources/toc-supporting-guides/tag-domain-technical-review-template.md) - these reviews are provide a structured framework to explore the technical lifecycle aspects of a project experienced or sought by adopters as well as dive deep on the design and architecture of the project within its technical domain of focus. The results of these can support projects in identifying next steps to increase usability, resilience, scale, performance, and ease-of-use. +* Collaborate with [TAG Security on a joint-review](https://github.com/cncf/tag-security/blob/main/community/assessments/guide/README.md#joint-assessment) - highly recommended for currently incubating projects, the joint review is a comprehensive assessment of a project's security, it helps project's prepare for a successful security audit. + ## How to apply to move levels ### Applying to Sandbox From ee3d1e8a28634836b92e72928b8f8070e278ee4c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:44:43 -0500 Subject: [PATCH 22/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 80 +++++++++++------------ 1 file changed, 39 insertions(+), 41 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 7f38d05be..a5eb0b2d6 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -23,9 +23,10 @@ Lin Sun (@linsun) conducted the due diligence of in-toto who applied for Graduat The following actions were provided to the project that were considered blocking but have since been resolved: -- Enable convenient linkage for community meeting notes. - Updating the list of subprojects in GitHub, found from the Governancy review. - Provide an updated roadmap document in GitHub. +- Document the release process. +- Provide instructions of onboarding & offboarding members/roles in the community. ### Final Assessment @@ -80,19 +81,19 @@ Note: this section may be augmented by the completion of a Governance Review fro Able to find it easily. -- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** +- [X] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** -TODO: need some work here. +Confirmed with the team the [Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is up to date. - [X] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** Vendor neutral is clearly mentioned twice in the governance doc. Steering committee composition is also diverse at the moment. -- [x] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** +- [X] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** Documented [here](https://github.com/in-toto/community/tree/main/elections) -- [ ] **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).** [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. @@ -129,20 +130,17 @@ Changes to the in-toto standard largely come in the form of ITEs (in-toto enhanc Another significant ITE is [ITE-6](https://github.com/in-toto/ITE/blob/master/ITE/6/README.adoc). This enhancement introduced the in-toto Attestation Framework to record and disseminate software supply chain specific information like build provenance, code review results, test results, SBOMs, vulnerability scans, and more. in-toto attestations are now used by GitHub for NPM build provenance, OpenVEX, Docker buildx, scanners like Trivy that can generate signed SBOMs, Tekton Chains, Sigstore, GUAC, Witness, and Archivista. SolarWinds, in their next generated build system introduced after SUNBURST, also generate in-toto attestations. -- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** - -TODO - -- [x] **Document agreement that project will adopt CNCF Code of Conduct.** -- [x] **CNCF Code of Conduct is cross-linked from other governance documents.** +- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** +- [X] **Document agreement that project will adopt CNCF Code of Conduct.** +- [X] **CNCF Code of Conduct is cross-linked from other governance documents.** The CoC and the assertion of adherence is referenced in the [GOVERNANCE.md](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#code-of-conduct). -- [x] **All subprojects, if any, are listed.** +- [X] **All subprojects, if any, are listed.** Subprojects are listed in the [README.md](https://github.com/in-toto/community/blob/main/README.md#subprojects) file of in-toto/community. -- [x] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** +- [X] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee. @@ -152,29 +150,29 @@ Note: this section may be augmented by the completion of a Governance Review fro ### Suggested -- [x] **Contributor ladder with multiple roles for contributors.** +- [X] **Contributor ladder with multiple roles for contributors.** The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) ### Required -- [x] **Clearly defined and discoverable process to submit issues or changes.** +- [X] **Clearly defined and discoverable process to submit issues or changes.** A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. -- [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** +- [X] **Project must have, and document, at least one public communications channel for users and/or contributors.** Communication channels are encoded in the [website](https://in-toto.io/contact/). It contains a developer facing mailing list, a public mailng list, a slack join link, github and IRC contacts. -- [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.** +- [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.** Communication channels are encoded in the [website](https://in-toto.io/contact/) -- [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** +- [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). -- [x] **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 contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) @@ -184,7 +182,7 @@ A contribution guide is placed at the toplevel [community repository](https://gi ## Engineering Principles -- [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.** +- [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.** One of the most pressing security problems in cloud native is software supply chain security. in-toto addresses this issue by providing a secure and trustworthy means for representing all the operations within the cloud-native pipeline and verifying that they were carried out to the letter. A good way to understand the need for in-toto in the Cloud Native space is to understand the value of signed SBOMs vs in-toto metadata + layouts. A signed SBOM indicates that some party (whose key you presumably have a reason to trust) states what the software contains. In contrast, in-toto will have signed information about the individual steps of the supply chain cryptographically linking metadata together from various parties and validating this all against the software’s policies. As a result, their protection modes would work quite differently in many cases. For example, see the following table: @@ -209,29 +207,29 @@ This is why projects like SLSA and FRSCA are built as an opinionated set of step These projects are solving different problems at different levels. In-toto allows you to capture information about your steps, ensure policies about them are applied, handle trust of keys, etc. Frameworks like SLSA and FRSCA use in-toto as a mechanism to capture and enforce a specific set of policies that result in more secure supply chains. -- [x] **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.** https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and many integrations with other projects in the ecosystem. -- [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** +- [X] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** Roadmap for project with pointers to subproject ROADMAPs are encoded in a [ROADMAP.md file](https://github.com/in-toto/community/blob/main/ROADMAP.md) -- [x] **Roadmap change process is documented.** +- [X] **Roadmap change process is documented.** Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/ROADMAP.md) outlines how and when the community-wide rodamap is updated (usually once a year). Each sub-project may also have their own ROADMAP that aligns to subproject-wide SLAs -- [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** +- [X] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** The [friends](https://github.com/in-toto/friends) repository outlines how Cloud-native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud-native CI/CD platforms, as well as social coding platforms and distributed buildsystems. -- [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** +- [X] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** - - [x] Release expectations (scheduled or based on feature implementation) - - [x] Tagging as stable, unstable, and security related releases - - [ ] Information on branch and tag strategies - - [ ] Branch and platform support and length of support - - [x] Artifacts included in the release. + - [X] Release expectations (scheduled or based on feature implementation) + - [X] Tagging as stable, unstable, and security related releases + - [X] Information on branch and tag strategies + - [X] Branch and platform support and length of support + - [X] Artifacts included in the release. - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. in-toto has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. @@ -248,34 +246,34 @@ Note: this section may be augemented by a joint-assessment performed by TAG Secu ### Suggested -- [x] **Achieving OpenSSF Best Practices silver or gold badge.** +- [X] **Achieving OpenSSF Best Practices silver or gold badge.** [in-toto achieves a gold OpenSSF Best Practice badge](https://www.bestpractices.dev/en/projects/1523?criteria_level=2) ### Required -- [x] **Clearly defined and discoverable process to report security issues.** +- [X] **Clearly defined and discoverable process to report security issues.** Repositories describe the disclosure process using a [SECURITY.md file](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) -- [x] **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.)** GitHub teams are used to provide granular access to different repositories within the organization. Protected branches are used to avoid pushes to master. Dependabot, and secret scanning is also added to all implementation repositories. -- [x] **Document assignment of security response roles and how reports are handled.** +- [X] **Document assignment of security response roles and how reports are handled.** Disclosure is handled by the ITSC. In addition, GitHub private vulnerability reporting is used (and has been successfully used before) to handle disclosures on implementations. -- [x] **Document Security Self-Assessment.** +- [X] **Document Security Self-Assessment.** in-toto was the [first project to carry out a security self-assessment](https://github.com/cncf/tag-security/commit/06b71c4db99ba07107cba6cf8f6fc6d4461fce82) with TAG security, and aided in developing the current process. -- [x] **Third Party Security Review.** +- [X] **Third Party Security Review.** See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). -- [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** +- [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). As of 31st of July, 2023, there are only 23 projects in the world to have such a distinction. The only other CNCF project with a Gold Badge is the [TUF project (a graduated security project)](http://theupdateframework.io). @@ -289,21 +287,21 @@ N/A ### Required -- [x] **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.)** Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends) -- [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)** +- [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)** Many adopters and integrations are [documented](https://github.com/in-toto/friends). 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. -- [x] **TOC verification of adopters.** +- [X] **TOC verification of adopters.** Refer to the Adoption portion of this document. -- [x] **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.** Many integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). From ea565738a6e1a1978cae57133c602bfa8161f2d0 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:57:35 -0500 Subject: [PATCH 23/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index a5eb0b2d6..4edafe8a8 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -176,9 +176,9 @@ in-toto community meetings are scheduled on the first friday of each month at 11 A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) -- [ ] **Demonstrate contributor activity and recruitment.** +- [X] **Demonstrate contributor activity and recruitment.** - +Constant contributor activity observed on devstats, and based on community meeting notes, meetings are well attended. There has been recruitments at KubeCon and other conferences including but not limited to project booth, presenting a KubeCon NA keynote and other talks related to in-toto. ## Engineering Principles From 19953114141c87274e8dc1d660ecc1422564ccfe Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:58:25 -0500 Subject: [PATCH 24/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 4edafe8a8..d48392fcd 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -315,6 +315,6 @@ This adopter interview is performed in Sept 2024 and recorded a very happy adopt This adopter interview is performed in Oct 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. -##### Adopter 3 - $COMPANY/$INDUSTRY +##### Adopter 3 - Chainguard/Software company This adopter interview is performed in Dec 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-chainguard.md) for more details. From 57a924a8b5e34a853eedb2391c0e90fcafa4635f Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 17:17:52 -0500 Subject: [PATCH 25/60] Update in-toto-graduation-dd.md WIP update to emily's comment Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index d48392fcd..a35d907bd 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -12,7 +12,7 @@ Project points of contacts: Santiago Torres, santiagotorres@purdue.edu ### Criteria Evaluation -Lin Sun (@linsun) conducted the due diligence of in-toto who applied for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: +Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: - A notable stable project with mature capabilities and a wide [adopter](https://github.com/in-toto/friends?tab=readme-ov-file#project-adopters) base. - The project has a wide range of interest across academic and cross different industries. @@ -28,13 +28,18 @@ The following actions were provided to the project that were considered blocking - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. -### Final Assessment +### Adoption Evaluation: -The TOC has found the project to have satisfied the criteria for Graduation. +The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martins and more. Every adopter I interviewed is quite happy with in-toto. Highlight some of the strength I heard: +- "Beyond the community, and diversity of others using it, the spec is also very flexible. You can add to it, or expand it or create a unique solution with it." +- "Community discussions are great and how they bring them (industry & academic & non profit OSS foundation). Really thinking ahead and anticipating needs before people need them. Continue to be an active community." +- "It's also been great to see the cross-industry and academic collaboration for in-toto and other related projects - it's a large community effort." -### Adoption Assertion +Only 1 adopter suggested 1 minor improvement, which is increased marketing effort. The other adopters seem quite happy with in-toto today. -### Criteria +### Final Assessment + +The TOC has found the project to have satisfied the criteria for Graduation. ## Application Process Principles @@ -46,20 +51,20 @@ N/A - [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** -Presentation was given to the TAG security in July 2014. +Presentation was given to the TAG security in July 2014, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). TODO: add a link to the presentation - [x] **TAG provides insight/recommendation of the project in the context of the landscape** -[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation +[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation: - [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** -Don't see any concern with vendor-neutral for in-toto project. +No issues were found during due diligence, both code and documentation are vendor neutral. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industries as well. - [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** - [x] Met during Project's application on 21-06-2024. -Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria. +I met with the project lead and went over the expectation and requirements for graduated project, as recorded [here](https://github.com/cncf/toc/pull/1162#issuecomment-2190111991). - [X] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** From 7130c2ca228f3987cc8f32a0b8bfcd77b803a714 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 17:31:39 -0500 Subject: [PATCH 26/60] Update in-toto-graduation-dd.md more updates Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 38 ++++++++++++++++++++--- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index a35d907bd..cefda7df8 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -51,7 +51,7 @@ N/A - [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** -Presentation was given to the TAG security in July 2014, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). TODO: add a link to the presentation +[Presentation](https://zoom.us/rec/share/H4AeeCUzrh7dVDzv7udMJmK-jWHvENmyWmcZvG4-1rZbVWUTn7RAByqKSfG3g9ya.OJnqcezJAXcGMce0?startTime=1721235498000) was given to the TAG security in July 2014, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). - [x] **TAG provides insight/recommendation of the project in the context of the landscape** @@ -59,7 +59,7 @@ Presentation was given to the TAG security in July 2014, which was recorded in t - [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** -No issues were found during due diligence, both code and documentation are vendor neutral. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industries as well. +No issues were found during due diligence, both code and documentation are vendor neutral. Vendor neutral is clearly mentioned twice in the governance doc. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industries as well. - [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** - [x] Met during Project's application on 21-06-2024. @@ -76,9 +76,9 @@ Note: this section may be augmented by the completion of a Governance Review fro ### 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.** +- [ ] **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.** -[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. +[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. There is very few changes to it since it was created in Feb, 2023. ### Required @@ -104,10 +104,38 @@ Documented [here](https://github.com/in-toto/community/tree/main/elections) - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) +[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: + + Santiago Torres + Email: santiagotorres@purdue.edu + GitHub username: @SantiagoTorres + + Lukas Puehringer + Email: lukas.puehringer@nyu.edu + GitHub username: @lukpueh + + Justin Cappos + Email: jcappos@nyu.edu + GitHub username: @JustinCappos + + Marina Moore + Email: mm9693@nyu.edu + GitHub username: @mnm678 + + Sebastien Awwad + Email: sebastien.awwad@nyu.edu + GitHub username: @awwad + + Aditya Sirish A Yelgundhalli + Email: aditya.sirish@nyu.edu + GitHub username: @adityasaky + +In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** +For the current cadence of changes in the project and backlog of work, the project has sufficient active maintainers to sustain its current and future momentum. Adopters I spoke to are all happy with either contributing to in-toto or getting support from the in-toto community. + - [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** The project maintains a description of different roles and their election process in its [community repository](https://github.com/in-toto/community) From 4a7ed9a3babf9a7e2cff77ec75a3218b19f53313 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 17:56:10 -0500 Subject: [PATCH 27/60] Update in-toto-graduation-dd.md more updates Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 35 ++++++++++++----------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index cefda7df8..6fadce370 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -30,12 +30,13 @@ The following actions were provided to the project that were considered blocking ### Adoption Evaluation: -The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martins and more. Every adopter I interviewed is quite happy with in-toto. Highlight some of the strength I heard: +The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martins and more. Every adopter I interviewed is quite happy with in-toto. Highlight some of the project strengths I heard during adopter interviews: + - "Beyond the community, and diversity of others using it, the spec is also very flexible. You can add to it, or expand it or create a unique solution with it." - "Community discussions are great and how they bring them (industry & academic & non profit OSS foundation). Really thinking ahead and anticipating needs before people need them. Continue to be an active community." - "It's also been great to see the cross-industry and academic collaboration for in-toto and other related projects - it's a large community effort." -Only 1 adopter suggested 1 minor improvement, which is increased marketing effort. The other adopters seem quite happy with in-toto today. +Only 1 adopter suggested 1 minor improvement, which is increased marketing effort. Other adopters seem happy with in-toto today. ### Final Assessment @@ -104,7 +105,7 @@ Documented [here](https://github.com/in-toto/community/tree/main/elections) - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: Santiago Torres Email: santiagotorres@purdue.edu @@ -146,9 +147,9 @@ Maintainers for subprojects have been managed by the ITSC and Sub-project mainta - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** -As an intentionally minimal security specification / framework, we deliberately do not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). +As an minimal security specification / framework, the project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). -Since reaching the incubation stage, the in-toto project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across our sub-projects, we have contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. +Since reaching the incubation stage, the project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across sub-projects, the project has contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. The current ITSC comprises of the following - Santiago Torres-Arias (Purdue University) @@ -157,14 +158,14 @@ The current ITSC comprises of the following - Cole Kennedy (TestifySec) - Trishank Karthik Kuppusamy (Datadog) -We have had active contributions from an array of contributors across the CNCF landscape. One way to see this is via the substantial changes that made their way into the specification. - -Changes to the in-toto standard largely come in the form of ITEs (in-toto enhancements). There is a substantial ITE, ITE-4, that standardized non-file artifact specifications for in-toto metadata. The stakeholders in it are Github, Conda, SPDX and Google's Grafeas. +- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** -Another significant ITE is [ITE-6](https://github.com/in-toto/ITE/blob/master/ITE/6/README.adoc). This enhancement introduced the in-toto Attestation Framework to record and disseminate software supply chain specific information like build provenance, code review results, test results, SBOMs, vulnerability scans, and more. in-toto attestations are now used by GitHub for NPM build provenance, OpenVEX, Docker buildx, scanners like Trivy that can generate signed SBOMs, Tekton Chains, Sigstore, GUAC, Witness, and Archivista. SolarWinds, in their next generated build system introduced after SUNBURST, also generate in-toto attestations. +On Jan 7, 2025, Justin Cappos walk through this with me during a screen sharing session where he confirmed that code and doc ownership in Github are assigned properly. -- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** - [X] **Document agreement that project will adopt CNCF Code of Conduct.** + +The project has CNCF CoC [recorded](https://github.com/in-toto/community/blob/main/CODE-OF-CONDUCT.md), which says "The in-toto community abides by the Cloud Native Computing Foundation's code of conduct." + - [X] **CNCF Code of Conduct is cross-linked from other governance documents.** The CoC and the assertion of adherence is referenced in the [GOVERNANCE.md](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#code-of-conduct). @@ -175,11 +176,13 @@ Subprojects are listed in the [README.md](https://github.com/in-toto/community/b - [X] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** -Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee. +Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee as described [here](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#onboarding-and-offboarding-all-roles). ## Contributors and Community -Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. +Governance Review from TAG Contributor Strategy is performed in Oct 2024. + +The team rated the review as "Mostly Satisfactory". The steering committee style governance is perceived favorable, along with the project's transparency in different areas such as public documentation, record, and communications. Refer to the [full review](https://github.com/cncf/tag-contributor-strategy/pull/740/files) for details. ### Suggested @@ -191,7 +194,7 @@ The contributor ladder is encoded in the [GOVERNANCE.md document](https://github - [X] **Clearly defined and discoverable process to submit issues or changes.** -A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. +A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) file. - [X] **Project must have, and document, at least one public communications channel for users and/or contributors.** @@ -199,15 +202,15 @@ Communication channels are encoded in the [website](https://in-toto.io/contact/) - [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.** -Communication channels are encoded in the [website](https://in-toto.io/contact/) +Communication channels are encoded in the [website](https://in-toto.io/contact/). Non-public communication channels are described in in-toto's [security disclosure process](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md). - [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** -in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). +The in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). - [X] **Documentation of how to contribute, with increasing detail as the project matures.** -A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) +A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) - [X] **Demonstrate contributor activity and recruitment.** From 25487e18331beea735f151ba88ef5beedbb8557c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 21:49:50 -0500 Subject: [PATCH 28/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 6fadce370..2d3ae3ba3 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -188,13 +188,13 @@ The team rated the review as "Mostly Satisfactory". The steering committee style - [X] **Contributor ladder with multiple roles for contributors.** -The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) +The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md). ### Required - [X] **Clearly defined and discoverable process to submit issues or changes.** -A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) file. +A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. - [X] **Project must have, and document, at least one public communications channel for users and/or contributors.** @@ -202,7 +202,7 @@ Communication channels are encoded in the [website](https://in-toto.io/contact/) - [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.** -Communication channels are encoded in the [website](https://in-toto.io/contact/). Non-public communication channels are described in in-toto's [security disclosure process](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md). +Communication channels are encoded in the [website](https://in-toto.io/contact/). Non-public communication channels are described in in-toto's [security disclosure process](https://github.com/in-toto/community/blob/main/SECURITY.md). - [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** @@ -210,7 +210,7 @@ The in-toto community meetings are scheduled on the first friday of each month a - [X] **Documentation of how to contribute, with increasing detail as the project matures.** -A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) +A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). I observed a few additional updates to the contribution guide this year, related to the newly added reference documentation policy and some refinement for it. - [X] **Demonstrate contributor activity and recruitment.** @@ -292,7 +292,6 @@ Note: this section may be augemented by a joint-assessment performed by TAG Secu Repositories describe the disclosure process using a [SECURITY.md file](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) - - [X] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** GitHub teams are used to provide granular access to different repositories within the organization. Protected branches are used to avoid pushes to master. Dependabot, and secret scanning is also added to all implementation repositories. @@ -325,21 +324,21 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends) +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). - [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)** -Many adopters and integrations are [documented](https://github.com/in-toto/friends). +Adopters are [documented](https://github.com/in-toto/friends). 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. - [X] **TOC verification of adopters.** -Refer to the Adoption portion of this document. +The project's adopter interviews reflect the appropriate level of adoptions demonstrating maturity of a graduation level project. Refer to the Adoption portion of this document for more details. - [X] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** -Many integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). +Integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). #### Adoption From 34018d190164b4d9a677495a207d3bfb4aa6aeb9 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 21:57:57 -0500 Subject: [PATCH 29/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 2d3ae3ba3..61e1eef3f 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -324,11 +324,11 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 2 issues to add [Lockhead Martins](https://github.com/in-toto/friends/issues/56) and [Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopters to submit PRs to resolve it. - [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)** -Adopters are [documented](https://github.com/in-toto/friends). +Adopters are [documented](https://github.com/in-toto/friends) which includes at least 3 indepdendent adopters. Adopter interviews also showed 3 independent adopters. All adopters I interviewed are using in-toto for production. 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. From 6131572ad805a425cd9dddbff390e64d518e2f05 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:15:07 -0500 Subject: [PATCH 30/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 61e1eef3f..ace7c9dd4 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -338,7 +338,7 @@ The project's adopter interviews reflect the appropriate level of adoptions demo - [X] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** -Integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). +Integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations), including a good range of popular projects/platforms such as GitHub, GitLab, GUAC, Jenkins, Sigstore etc. #### Adoption From 7b196eafec493c5779892d7c58bab45ed34b841c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:19:29 -0500 Subject: [PATCH 31/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 23 +---------------------- 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index ace7c9dd4..15c2728cd 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -220,28 +220,7 @@ Constant contributor activity observed on devstats, and based on community meeti - [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.** -One of the most pressing security problems in cloud native is software supply chain security. in-toto addresses this issue by providing a secure and trustworthy means for representing all the operations within the cloud-native pipeline and verifying that they were carried out to the letter. -A good way to understand the need for in-toto in the Cloud Native space is to understand the value of signed SBOMs vs in-toto metadata + layouts. A signed SBOM indicates that some party (whose key you presumably have a reason to trust) states what the software contains. In contrast, in-toto will have signed information about the individual steps of the supply chain cryptographically linking metadata together from various parties and validating this all against the software’s policies. As a result, their protection modes would work quite differently in many cases. For example, see the following table: - - -| Attack scenario | Signed SBOM Result | In-toto layout + metadata result | -|-----------------|----------------------|----------------------------------| -| Software manipulated after software supply chain completed | Detect and reject the malicious software | Detect and reject the malicious software | -| Attacker compromises VCS and inserts malicious (unsigned) code where signatures are required |Undetected. User compromised. | Detect and reject the malicious software | -| Attacker substitutes a malicious dependency (not signed by that dependeny’s maintainer) |Undetected. User compromised. | Detect and reject the malicious software -| Attacker provides files to the build system which did not come from the VCS | Undetected. User compromised | Detect and reject the malicious software | -| Attacker containerizes / packages binaries other than the ones the build system built | Undetected. User compromised | Detect and reject the malicious software | -| Tests are not run on the software but it is (accidentally?) released to production | Undetected. User compromised | Detect and reject the malicious software | -| The legal team has not reviewed source code licenses for included libraries | Undetected. Impact varies | Detect and reject the software | - -One important thing to note about the table above is that it isn’t impossible for someone to do many of these steps and checks before signing an SBOM. If you did all of these checks, and signed the statements saying you did them to provide stronger validation, and distributed the root of trust for your signatures in a secure way, and managed situations where signing keys need to be revoked / rotated / expired, and handled trust delegation to different parties, and linked metadata between steps together, and let people write policies to reason about those steps, and let them link metadata in from dependencies to do so, and handled all of the above in scenarios where insiders can be maliciously interfering with your, system, then you would effectively reconstruct in-toto. -We are aware of some efforts, like the Zephyr project, where project members have worked to try to reconstruct some of the guarantees of in-toto and decided to live with the gaps in their security for other portions. For groups that have done this work already this does make sense to us as a viable alternative in the short term. However, we do believe that using a common, holistic approach like in-toto will be necessary as projects continually add the missing security pieces from in-toto and want to reason more and more about each other as dependencies. - -Note that in-toto is not a substitute for having appropriately secure steps in the software supply chain. For example, if you use an insecure process of building software that just curls and builds software from a website, in-toto will happily sign metadata indicating that you did the same insecure action indicated you would. - -This is why projects like SLSA and FRSCA are built as an opinionated set of steps on top of in-toto. They specify which actions they feel are more important for software supply chain security and mandate their use. - -These projects are solving different problems at different levels. In-toto allows you to capture information about your steps, ensure policies about them are applied, handle trust of keys, etc. Frameworks like SLSA and FRSCA use in-toto as a mechanism to capture and enforce a specific set of policies that result in more secure supply chains. +This is documented well at the project's readme, under a section that describes how [in-toto differentiates in the cloud native landscape](https://github.com/in-toto/community/blob/main/README.md#how-is-in-toto-differentiated-in-the-cloud-native-landscape---what-does-it-do-differently-and-why). - [X] **Document what the project does, and why it does it - including viable cloud native use cases.** From a32267814f25e3fe0e5aea750526592b1b710848 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:20:35 -0500 Subject: [PATCH 32/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 15c2728cd..8a2723a26 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -56,7 +56,7 @@ N/A - [x] **TAG provides insight/recommendation of the project in the context of the landscape** -[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation: +[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation. - [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** From daf3f231efc39414b4f6c8e2bd7939a02d9d390f Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:26:54 -0500 Subject: [PATCH 33/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 8a2723a26..4beeb022a 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -85,7 +85,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [X] **Clear and discoverable project governance documentation.** -Able to find it easily. +I was able to find it easily. - [X] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** @@ -97,7 +97,7 @@ Vendor neutral is clearly mentioned twice in the governance doc. Steering commit - [X] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** -Documented [here](https://github.com/in-toto/community/tree/main/elections) +Election process of the steering committee is documented [here](https://github.com/in-toto/community/tree/main/elections). [Decision making](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#decision-making) and [change process](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#change-review-process) are also documented. - [X] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** From 73a42c16f007ec97aa30f80f5527d9e0c307d894 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:27:41 -0500 Subject: [PATCH 34/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 4beeb022a..b679ea93d 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -79,7 +79,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [ ] **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.** -[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. There is very few changes to it since it was created in Feb, 2023. +The [Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. There is very few changes to it since it was created in Feb, 2023. ### Required @@ -101,7 +101,7 @@ Election process of the steering committee is documented [here](https://github.c - [X] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** -[GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. +The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** From 35a14466891edd1c4e3b40ddd25399827a660853 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:30:51 -0500 Subject: [PATCH 35/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index b679ea93d..867596484 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -160,7 +160,7 @@ The current ITSC comprises of the following - [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** -On Jan 7, 2025, Justin Cappos walk through this with me during a screen sharing session where he confirmed that code and doc ownership in Github are assigned properly. +On Jan 7, 2025, Justin Cappos walk through this with me during a screen sharing session where he confirmed that code and doc ownership in Github are assigned properly with two primary groups (maintainers and steering members). The project's code and doc ownership appear to match the documented governance roles for the project. - [X] **Document agreement that project will adopt CNCF Code of Conduct.** From 4e3f4f13f984b85c3ee0a9ab22418e629562643e Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:36:18 -0500 Subject: [PATCH 36/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 867596484..0be174d07 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -105,7 +105,7 @@ The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVE - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active: Santiago Torres Email: santiagotorres@purdue.edu @@ -119,14 +119,6 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: jcappos@nyu.edu GitHub username: @JustinCappos - Marina Moore - Email: mm9693@nyu.edu - GitHub username: @mnm678 - - Sebastien Awwad - Email: sebastien.awwad@nyu.edu - GitHub username: @awwad - Aditya Sirish A Yelgundhalli Email: aditya.sirish@nyu.edu GitHub username: @adityasaky From 9cea9d52b71cd8a751f4a29e2ce7f0e3c5aabe0a Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 9 Jan 2025 09:56:51 -0500 Subject: [PATCH 37/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 0be174d07..0eeac05ce 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -27,6 +27,8 @@ The following actions were provided to the project that were considered blocking - Provide an updated roadmap document in GitHub. - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. +- Move inactive maintainers to emeritus maintainers. +- Update list of adopters to be accurate. ### Adoption Evaluation: @@ -105,7 +107,7 @@ The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVE - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active and worked with the project to move the inactive maintainers to emeritus maintainers: Santiago Torres Email: santiagotorres@purdue.edu @@ -295,7 +297,7 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 2 issues to add [Lockhead Martins](https://github.com/in-toto/friends/issues/56) and [Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopters to submit PRs to resolve it. +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 1 issue to [add Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopter to submit a PR to resolve it. - [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)** From a42d5f9afc52c0f53e2ea441a6e22e08dd9482e0 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 9 Jan 2025 09:58:03 -0500 Subject: [PATCH 38/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 0eeac05ce..1f35818c3 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -283,8 +283,7 @@ See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). - [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** -The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). As of 31st of July, 2023, there are only 23 projects in the world to have such a distinction. The only other CNCF project with a Gold Badge is the [TUF project (a graduated security project)](http://theupdateframework.io). - +The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). According to the OpenSSF Best Practices website, the in-toto project received its initial OpenSSF Best Practices badge on January 5th, 2018. ## Ecosystem From 5f3b2fc2cf1ad6e1e53641e67805ac9174039578 Mon Sep 17 00:00:00 2001 From: Ricardo Rocha Date: Tue, 7 Jan 2025 18:00:20 +0100 Subject: [PATCH 39/60] Link to adopter definition in the dd guide triage Signed-off-by: Ricardo Rocha Signed-off-by: Lin Sun --- operations/dd-toc-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/operations/dd-toc-guide.md b/operations/dd-toc-guide.md index d153da956..e4337e928 100644 --- a/operations/dd-toc-guide.md +++ b/operations/dd-toc-guide.md @@ -63,7 +63,7 @@ The issue will contain a limited set of information about the project at the tim All TOC members are expected to assist in the triaging of project applications to move levels to ensure that when a TOC member is ready to be assigned, the project is ready to be evaluated with no immediate blockers that would inhibit or delay the TOC's engagement. This light-weight triage/evaluation must cover the list below (it is not exhaustive and is a minimum triage set from the [incubation template retrieved 12 DEC 2025](https://github.com/cncf/toc/blob/c2943ffc98064dd88e9ef9c4afd5a8856898942f/.github/ISSUE_TEMPLATE/template-incubation-application.md)): -* Adoption Assertion includes the Adopters file link, and the project has an entry in the Adopter's form responses to provide 5-7 adopters to reach out to. +* Adoption Assertion includes the Adopters file link, and the project has an entry in the Adopter's form responses to provide 5-7 adopters to reach out to. [Check here](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter) for the definition of an Adopter. * Application Process Principles provides * Either: the link to the Recording, issue, and/or meeting notes from a TAG meeting where the project presented with the domain specific TAG -or- completion of the [General Technical Review (GTR)](../tags/resources/toc-supporting-guides/general-technical-questions.md) or [Domain Technical Review (DTR)](../tags/resources/toc-supporting-guides/tag-domain-technical-review-template.md) in lieu of a TAG meeting * assertion of vendor neutrality From f2ee9c813e80e24f0f2e540a33f2d169ed73d739 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 13:45:08 -0500 Subject: [PATCH 40/60] Update template-incubation-application.md Add a link to the template to ensure user review the moving level evaluation guideline Signed-off-by: Lin Sun --- .github/ISSUE_TEMPLATE/template-incubation-application.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.github/ISSUE_TEMPLATE/template-incubation-application.md b/.github/ISSUE_TEMPLATE/template-incubation-application.md index ff1dc1a9f..61d2b0136 100644 --- a/.github/ISSUE_TEMPLATE/template-incubation-application.md +++ b/.github/ISSUE_TEMPLATE/template-incubation-application.md @@ -5,6 +5,9 @@ title: "[Incubation] $PROJECT Incubation Application" labels: incubation --- +# Review Project Moving Level Evaluation +[ ] I have reviewed the project moving level evaluation guide and ensured the criterias are met for my project before opening the issue. + # $PROJECT Incubation Application v1.6 This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria. From 7c3262ebc19fdfa802fc917714057875d8425f9c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 13:56:00 -0500 Subject: [PATCH 41/60] Update .github/ISSUE_TEMPLATE/template-incubation-application.md Signed-off-by: Lin Sun --- .github/ISSUE_TEMPLATE/template-incubation-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/template-incubation-application.md b/.github/ISSUE_TEMPLATE/template-incubation-application.md index 61d2b0136..4e72d6c27 100644 --- a/.github/ISSUE_TEMPLATE/template-incubation-application.md +++ b/.github/ISSUE_TEMPLATE/template-incubation-application.md @@ -6,7 +6,7 @@ labels: incubation --- # Review Project Moving Level Evaluation -[ ] I have reviewed the project moving level evaluation guide and ensured the criterias are met for my project before opening the issue. +[ ] I have reviewed the project [moving level evaluation guide](/operations/dd-toc-guide.md#initial-triageevaluation-prior-to-assignment) and ensured the criterias are met for my project before opening the issue. # $PROJECT Incubation Application v1.6 From a20ca26fca8eaa6189f12c3f72e8501be493ff26 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:30:24 -0500 Subject: [PATCH 42/60] Update .github/ISSUE_TEMPLATE/template-incubation-application.md Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Lin Sun --- .github/ISSUE_TEMPLATE/template-incubation-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/template-incubation-application.md b/.github/ISSUE_TEMPLATE/template-incubation-application.md index 4e72d6c27..b56d09c09 100644 --- a/.github/ISSUE_TEMPLATE/template-incubation-application.md +++ b/.github/ISSUE_TEMPLATE/template-incubation-application.md @@ -6,7 +6,7 @@ labels: incubation --- # Review Project Moving Level Evaluation -[ ] I have reviewed the project [moving level evaluation guide](/operations/dd-toc-guide.md#initial-triageevaluation-prior-to-assignment) and ensured the criterias are met for my project before opening the issue. +[ ] I have reviewed the TOC's [moving level readiness triage guide](/operations/dd-toc-guide.md#initial-triageevaluation-prior-to-assignment), ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed. # $PROJECT Incubation Application v1.6 From 8509dd80e6c2f90baab0ce64197310cfd5c1c2d6 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:32:02 -0500 Subject: [PATCH 43/60] Update template-graduation-application.md Signed-off-by: Lin Sun --- .github/ISSUE_TEMPLATE/template-graduation-application.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.github/ISSUE_TEMPLATE/template-graduation-application.md b/.github/ISSUE_TEMPLATE/template-graduation-application.md index f10056a9c..041d8865b 100644 --- a/.github/ISSUE_TEMPLATE/template-graduation-application.md +++ b/.github/ISSUE_TEMPLATE/template-graduation-application.md @@ -5,6 +5,9 @@ title: "[Graduation] $PROJECT Graduation Application" labels: graduation --- +# Review Project Moving Level Evaluation +[ ] I have reviewed the TOC's [moving level readiness triage guide](/operations/dd-toc-guide.md#initial-triageevaluation-prior-to-assignment), ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed. + # $PROJECT Graduation Application v1.6 This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria. From 3dbd0deac7fb9eb3f0ef8430685c4769c2b0649d Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 9 Jan 2025 22:11:42 -0500 Subject: [PATCH 44/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 1f35818c3..1fc9e5cff 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -28,7 +28,7 @@ The following actions were provided to the project that were considered blocking - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. - Move inactive maintainers to emeritus maintainers. -- Update list of adopters to be accurate. +- Added a few missing adopters. ### Adoption Evaluation: @@ -107,7 +107,7 @@ The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVE - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active and worked with the project to move the inactive maintainers to emeritus maintainers: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active and worked with the project to move the two inactive maintainers to emeritus maintainers: Santiago Torres Email: santiagotorres@purdue.edu @@ -125,7 +125,7 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: aditya.sirish@nyu.edu GitHub username: @adityasaky -In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog. +In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** @@ -141,11 +141,11 @@ Maintainers for subprojects have been managed by the ITSC and Sub-project mainta - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** -As an minimal security specification / framework, the project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). +As an minimal security specification / framework, the in-toto project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). Since reaching the incubation stage, the project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across sub-projects, the project has contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. -The current ITSC comprises of the following +The current ITSC comprises of the following: - Santiago Torres-Arias (Purdue University) - Justin Cappos (New York University) - Jack Kelly (Control Plane) @@ -218,7 +218,7 @@ This is documented well at the project's readme, under a section that describes - [X] **Document what the project does, and why it does it - including viable cloud native use cases.** -https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and many integrations with other projects in the ecosystem. +https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and its integrations with other projects in the ecosystem. - [X] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** @@ -230,7 +230,7 @@ Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/RO - [X] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** -The [friends](https://github.com/in-toto/friends) repository outlines how Cloud-native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud-native CI/CD platforms, as well as social coding platforms and distributed buildsystems. +The [friends](https://github.com/in-toto/friends) repository outlines how cloud native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud native CI/CD platforms, as well as social coding platforms and distributed buildsystems. - [X] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** @@ -296,7 +296,7 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 1 issue to [add Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopter to submit a PR to resolve it. +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). As part of the review, I worked with the project lead to add a few missing adopters to the list. - [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)** From 69664766ac49650ad490a31e48e9d256ded3d238 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Fri, 10 Jan 2025 09:39:30 -0500 Subject: [PATCH 45/60] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 1fc9e5cff..e0133e294 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -12,7 +12,7 @@ Project points of contacts: Santiago Torres, santiagotorres@purdue.edu ### Criteria Evaluation -Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: +Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria are noteworthy to call out: - A notable stable project with mature capabilities and a wide [adopter](https://github.com/in-toto/friends?tab=readme-ov-file#project-adopters) base. - The project has a wide range of interest across academic and cross different industries. From 1da51c3d47ff9b2b9f425da110e9f456d680f34c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Fri, 10 Jan 2025 17:06:38 -0500 Subject: [PATCH 46/60] Update in-toto-graduation-dd.md adding more info related to audit and maintainers Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index e0133e294..2b2896a5c 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -21,14 +21,15 @@ Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduati - The project is not only vendor neutral but also has a very diversed set of maintainers, adopters and integrators. - The project does an excellent job of making sure that its public meetings are accessible, with notes, and easy to find meeting links. -The following actions were provided to the project that were considered blocking but have since been resolved: +The following actions were provided to the in-toto project that were considered blocking but have since been resolved: - Updating the list of subprojects in GitHub, found from the Governancy review. - Provide an updated roadmap document in GitHub. - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. - Move inactive maintainers to emeritus maintainers. -- Added a few missing adopters. +- Added a few missing adopters. +- 1 High severity issue along with a few outstanding issues that were found from the security audit in 2023 have been addressed. ### Adoption Evaluation: @@ -125,7 +126,7 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: aditya.sirish@nyu.edu GitHub username: @adityasaky -In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. +Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** @@ -141,7 +142,7 @@ Maintainers for subprojects have been managed by the ITSC and Sub-project mainta - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** -As an minimal security specification / framework, the in-toto project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). +As an minimal security specification / framework, the in-toto project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). The graduation application is only for the in-toto project itself which is the framework/specification. Since reaching the incubation stage, the project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across sub-projects, the project has contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. @@ -241,7 +242,7 @@ The [friends](https://github.com/in-toto/friends) repository outlines how cloud - [X] Artifacts included in the release. - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. -in-toto has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. +The in-toto project has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. All implementations follow semver to communicate their feature support, as well as backwards and forwards compatiblity. @@ -279,7 +280,7 @@ in-toto was the [first project to carry out a security self-assessment](https:// - [X] **Third Party Security Review.** -See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). +See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). The project has resolved the majority of findings from the security audit and created issues for resolution of any outstanding. All issues related to the in-toto framework or specification have been resolved. - [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** From d1b94ae5b4a3553ee1f3d8e65c8bb84fe8c4147c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Mon, 13 Jan 2025 17:13:44 -0500 Subject: [PATCH 47/60] Update in-toto-graduation-dd.md address more comments on active maintainers and security audit. Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 2b2896a5c..b14899a26 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -126,7 +126,7 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: aditya.sirish@nyu.edu GitHub username: @adityasaky -Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. +Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low and the current list of maintainers appears to be sufficient. The maintainers also have a few active sub-project maintainers in the core maintainer pipeline if needed to promote one of them. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** @@ -282,6 +282,8 @@ in-toto was the [first project to carry out a security self-assessment](https:// See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). The project has resolved the majority of findings from the security audit and created issues for resolution of any outstanding. All issues related to the in-toto framework or specification have been resolved. +The witness implementation still has a few [outstanding issues](https://github.com/in-toto/witness/issues/268) to be resolved. This DD doc focuses on the in-toto framework and specification, thus we consider the issues related to the witness implementation out of scope. + - [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). From cef32e555bd433c7c79ebe8e002af89052c323d1 Mon Sep 17 00:00:00 2001 From: Davanum Srinivas Date: Mon, 6 Jan 2025 09:32:48 -0500 Subject: [PATCH 48/60] Naming convention guidance for new projects Signed-off-by: Davanum Srinivas Signed-off-by: Lin Sun --- process/README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/process/README.md b/process/README.md index be1ebfd94..2af929669 100644 --- a/process/README.md +++ b/process/README.md @@ -23,6 +23,10 @@ Projects may enter the CNCF either by applying as a sandbox project or applying Evaluting projects against the criteria does take some time and the TOC has recently modified the Due Diligence process to reduce duplication of work, streamline handoffs, and provide better transparency to the project and its adopters about its conformance and implementation of the criteria. +## Naming conventions for projects + +All CNCF projects are subject to the [Trademark Usage Policies](https://www.linuxfoundation.org/legal/trademark-usage) set by Linux Foundation. Specifically, new or incoming projects should avoid use existing trademarks in their proposed project names. In addition, if they are intending to use a popular prefix/suffix of an existing project (like "kube" or "k8s"), then they should consult the leadership group of the respective project to seek their approval and document the consensus reached. Existing projects are encouraged to document their naming guidelines to make this process smooth as well to avoid lengthy deliberation process for new project names. + ### Project resources and guide posts The TOC, with support from the [Technical Advisory Groups](/tags/README.md), have a wide variety of resources available to assist projects. Current and aspiring maintainers of cloud native projects can find a lot of information and templates on [contribute.cncf.io/maintainers](https://contribute.cncf.io/maintainers/). The TOC also maintains [project Guide Posts](../docs/project_guideposts.md) - a collection of guiding points that have assisted cloud native projects as they grow and mature in the ecosystem. These are not requirements for moving levels, those may be found in the respective application issue templates ([Incubation](../.github/ISSUE_TEMPLATE/template-incubation-application.md), [Graduation](../.github/ISSUE_TEMPLATE/template-graduation-application.md)). The [Guide Posts](../docs/project_guideposts.md) are a resources for projects to leverage that is beneficial in meeting or exceeding the criteria defined. From 39fb499e9ca933711c469ac0d70d07372a5f07dd Mon Sep 17 00:00:00 2001 From: Ricardo Rocha Date: Wed, 8 Jan 2025 21:55:24 +0100 Subject: [PATCH 49/60] Add maturity level survey questions to adopter questions template As per the discussion in the TOC meeting of 2025-01-07 (https://youtu.be/dTzpAw6lUT0?t=1627), add a set of questions to the adopter interview template that will allow us to get a better picture of how adopters see and use these maturity levels. Signed-off-by: Ricardo Rocha Signed-off-by: Lin Sun --- .../toc-templates/template-adopter-questions.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/operations/toc-templates/template-adopter-questions.md b/operations/toc-templates/template-adopter-questions.md index fd6d5ff60..f801c9828 100644 --- a/operations/toc-templates/template-adopter-questions.md +++ b/operations/toc-templates/template-adopter-questions.md @@ -38,4 +38,16 @@ Expectations conveyance with interviewers: “I’ll record raw notes here, then 13. What are the overall strengths of the project? -14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. \ No newline at end of file +14. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +### 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? + +2. Is there information missing regarding the meaning of each different level? + +3. Do you rely on those levels internally in any way, and if yes how? From 6d2d7f8712f883cfa97ffe42d086ad07040200f6 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 30 Jan 2025 17:00:02 -0500 Subject: [PATCH 50/60] Update projects/in-toto/in-toto-adopter-interview-lockheedmartins.md correct typo Signed-off-by: Lin Sun --- projects/in-toto/in-toto-adopter-interview-lockheedmartins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md index 23320ab41..1351205da 100644 --- a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md +++ b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md @@ -1,4 +1,4 @@ -# In-toto Adopter Interview - GitHub +# In-toto Adopter Interview - Lockheed Martins Interviewee: Ian Dunbar-hall, Head of Open Source Program Office, Lockheed Martins Interview date: Sept 3, 2024 From a08bc0af7881c56e3ab69c811529c4be1d8c3fad Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:10:39 -0700 Subject: [PATCH 51/60] Update projects/in-toto/in-toto-adopter-interview-lockheedmartins.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-adopter-interview-lockheedmartins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md index 1351205da..5fd7ef3fa 100644 --- a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md +++ b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md @@ -7,7 +7,7 @@ Interview date: Sept 3, 2024 ### Can you give us an overview of your organization and what it does? -[Lockheed Martins](https://www.lockheedmartin.com/en-us/contact.html) is a leading aerospace and defense company. +[Lockheed Martin](https://www.lockheedmartin.com/en-us/contact.html) is a leading aerospace and defense company. ## Motivation From e957f20dfa9dae894b532bf7d192fc7a921e82fb Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:10:49 -0700 Subject: [PATCH 52/60] Update projects/in-toto/in-toto-adopter-interview-lockheedmartins.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-adopter-interview-lockheedmartins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md index 5fd7ef3fa..6ace4c9d2 100644 --- a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md +++ b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md @@ -1,4 +1,4 @@ -# In-toto Adopter Interview - Lockheed Martins +# In-toto Adopter Interview - Lockheed Martin Interviewee: Ian Dunbar-hall, Head of Open Source Program Office, Lockheed Martins Interview date: Sept 3, 2024 From d666f9249dff47ec2b904f80b2209d0aedec2e96 Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:11:00 -0700 Subject: [PATCH 53/60] Update projects/in-toto/in-toto-adopter-interview-lockheedmartins.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-adopter-interview-lockheedmartins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md index 6ace4c9d2..2a8bba451 100644 --- a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md +++ b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md @@ -1,6 +1,6 @@ # In-toto Adopter Interview - Lockheed Martin -Interviewee: Ian Dunbar-hall, Head of Open Source Program Office, Lockheed Martins +Interviewee: Ian Dunbar-hall, Head of Open Source Program Office, Lockheed Martin Interview date: Sept 3, 2024 ## Organization Intro From 7c411337290d569ac87bdde10870a2f3021b18d9 Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:11:10 -0700 Subject: [PATCH 54/60] Update projects/in-toto/in-toto-graduation-dd.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index b14899a26..ec002d1bd 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -18,7 +18,7 @@ Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduati - The project has a wide range of interest across academic and cross different industries. - The project [integrates](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations) with various other projects in the cloud native ecosystem such as GitHub, GitLab, GUAC, Tekton, etc. - Implementation of the steering committee to capture adopters' voice in the project development and roadmap. -- The project is not only vendor neutral but also has a very diversed set of maintainers, adopters and integrators. +- The project is not only vendor neutral but also has a very diverse set of maintainers, adopters and integrators. - The project does an excellent job of making sure that its public meetings are accessible, with notes, and easy to find meeting links. The following actions were provided to the in-toto project that were considered blocking but have since been resolved: From c0c11c6c9248b3ed0990a0a6da5c83946bcc58f4 Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:11:24 -0700 Subject: [PATCH 55/60] Update projects/in-toto/in-toto-graduation-dd.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index ec002d1bd..8628dab97 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -26,7 +26,7 @@ The following actions were provided to the in-toto project that were considered - Updating the list of subprojects in GitHub, found from the Governancy review. - Provide an updated roadmap document in GitHub. - Document the release process. -- Provide instructions of onboarding & offboarding members/roles in the community. +- Provide instructions for onboarding & offboarding members/roles in the community. - Move inactive maintainers to emeritus maintainers. - Added a few missing adopters. - 1 High severity issue along with a few outstanding issues that were found from the security audit in 2023 have been addressed. From 7f665976c4cff29863362814f000978cc7160e1b Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:11:39 -0700 Subject: [PATCH 56/60] Update projects/in-toto/in-toto-graduation-dd.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 8628dab97..32b27c9bf 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -33,7 +33,7 @@ The following actions were provided to the in-toto project that were considered ### Adoption Evaluation: -The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martins and more. Every adopter I interviewed is quite happy with in-toto. Highlight some of the project strengths I heard during adopter interviews: +The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martin and more. Every adopter I interviewed is quite happy with in-toto. Highlighting some of the project strengths I heard during adopter interviews: - "Beyond the community, and diversity of others using it, the spec is also very flexible. You can add to it, or expand it or create a unique solution with it." - "Community discussions are great and how they bring them (industry & academic & non profit OSS foundation). Really thinking ahead and anticipating needs before people need them. Continue to be an active community." From 8cd8265ecc9afe9d0c8b8042cc80644e2b949b64 Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:11:56 -0700 Subject: [PATCH 57/60] Update projects/in-toto/in-toto-graduation-dd.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 32b27c9bf..19bc2e87d 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -63,7 +63,7 @@ N/A - [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** -No issues were found during due diligence, both code and documentation are vendor neutral. Vendor neutral is clearly mentioned twice in the governance doc. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industries as well. +No issues were found during due diligence, both code and documentation are vendor neutral. Vendor neutral is clearly mentioned twice in the governance doc. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industry as well. - [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** - [x] Met during Project's application on 21-06-2024. From 6df61f48804389808dd241326dc72619442ad3da Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:12:05 -0700 Subject: [PATCH 58/60] Update projects/in-toto/in-toto-graduation-dd.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 19bc2e87d..c35ebbe73 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -252,7 +252,7 @@ A history of releases is [kept on our changelog](https://github.com/in-toto/in-t ## Security -Note: this section may be augemented by a joint-assessment performed by TAG Security. +Note: this section may be augmented by a joint-assessment performed by TAG Security. ### Suggested From b6635bad6225aa7ff614bc21e676994fdd45430e Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:12:15 -0700 Subject: [PATCH 59/60] Update projects/in-toto/in-toto-graduation-dd.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index c35ebbe73..f7687416c 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -189,7 +189,7 @@ The contributor ladder is encoded in the [GOVERNANCE.md document](https://github - [X] **Clearly defined and discoverable process to submit issues or changes.** -A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. +A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded in a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. - [X] **Project must have, and document, at least one public communications channel for users and/or contributors.** From 59888fc2de71591d2b6a3994491fb5b745a5b781 Mon Sep 17 00:00:00 2001 From: Karena Angell Date: Wed, 5 Feb 2025 15:12:25 -0700 Subject: [PATCH 60/60] Update projects/in-toto/in-toto-graduation-dd.md Co-authored-by: Malini Bhandaru Signed-off-by: Karena Angell --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index f7687416c..5f52aa9bf 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -55,7 +55,7 @@ N/A - [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** -[Presentation](https://zoom.us/rec/share/H4AeeCUzrh7dVDzv7udMJmK-jWHvENmyWmcZvG4-1rZbVWUTn7RAByqKSfG3g9ya.OJnqcezJAXcGMce0?startTime=1721235498000) was given to the TAG security in July 2014, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). +[Presentation](https://zoom.us/rec/share/H4AeeCUzrh7dVDzv7udMJmK-jWHvENmyWmcZvG4-1rZbVWUTn7RAByqKSfG3g9ya.OJnqcezJAXcGMce0?startTime=1721235498000) was given to the TAG security in July 2024, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). - [x] **TAG provides insight/recommendation of the project in the context of the landscape**