From f373651615cbc146e2bf94ab593c4e3a50d6a315 Mon Sep 17 00:00:00 2001
From: Emily Fox <themoxiefoxatwork@gmail.com>
Date: Tue, 27 Aug 2024 13:55:44 -0400
Subject: [PATCH 1/7] initialized DD in new template

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
---
 proposals/incubation/kubescape.md | 274 ++++++++++++++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 proposals/incubation/kubescape.md

diff --git a/proposals/incubation/kubescape.md b/proposals/incubation/kubescape.md
new file mode 100644
index 000000000..f077eced6
--- /dev/null
+++ b/proposals/incubation/kubescape.md
@@ -0,0 +1,274 @@
+# Kubescape Incubation Due Diligence
+
+- Link to [Incubation application issue](https://github.com/cncf/toc/issues/1291)
+
+<!-- This template provides the TOC with the outline for completing due diligence of a project to move levels. This universal template is designed to capture all criteria so the TOC may ensure prior level criteria do not regress. As part of completing the due diligence, the TOC member should update the template to convey the level the project applied for the criteria by bolding the level indicated where the criteria is relevant. -->
+
+## Incubation Evaluation Summary for Kubescape
+
+### Criteria Evaluation
+
+_Emily Fox (@TheFoxAtWork) conducted the due diligence of Kubescape who applied for Incubation Level. The project [has/has not] completed the criteria that show its maturity at Incubation lelve. The following criteria implementations are noteworthy to call out... $NOTABLES. The following actions were provided to the project that were considered blocking but since resolved... $BLOCKERS. The following recommendations were provided to the project that are non-blocking in the TOC's assessment but should be completed by the project to ensure continued viability of the project... $RECOMMENDATIONS._
+
+### Adoption Evaluation
+
+_The adopter interviews reflect a project [in use/too early] for the level which the project applied. They show ... $INTERVIEWSUMMARY._
+
+### Final Assessment
+
+_[The TOC has found the project to have satisfied the criteria for $LEVEL/ The TOC's evaluation of the project shows a needed focus to complete the outstanding blockers and reapply when the following conditions are met ... $CONDITIONS]._
+
+## Application Process Principles
+
+### Suggested
+
+N/A
+
+### Required
+
+- [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness**
+  - This was completed and occurred on 10-JULY-2024, and can be discovered at the [TAG's meeting notes for that session](https://docs.google.com/document/d/1XDmNG1P1YRnidQJEuZFKufaXaIenNHiY-TdYMlt0Un4/edit#heading=h.cbsth4x8m975) and the [issue link for that presentation](https://github.com/cncf/tag-security/issues/1262).
+
+The Project presented to TAG Security on 10-JULY-2024 and provided the community with an update on new capabilities of the project, feedback by the community and the TAG was engaging and did not appear to raise any concerns with the project.
+
+- [X] **TAG provides insight/recommendation of the project in the context of the landscape**
+
+At the July 10th, 2024 presentation to TAG Security, Kubescape was provided the following recommendations: 
+
+> Recommendation for the project to engage with the End User TAB for seeking feedback on these features.
+
+> Recommendation to look at existing open source projects (SIG-infra, etc.) with substantial infrastructure (build systems for instance) to see if they are willing to test out those features.
+
+"Features" referring to several new capabilities that allows the project to auto-generate policies/configuration that support its goals to provide a runtime-powered k8s security platform.  To provide all k8s security needs under a single project.
+
+- [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).**
+
+The project's communications, planning, and docs align with CNCF stated guidelines for project neutrality. It is noted that the project does maintain a providers file, for which ARMO is the only one listed. However, any contributor is welcome to submit a PR to add additional providers in accordance with the information provided on the [project's docs page for providers](https://kubescape.io/docs/providers/).
+
+- [X] **Review and acknowledgement of expectations for [Sandbox](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.**		
+- Met during Project's [initial application on 13-DEC-2022 to CNCF](https://github.com/cncf/toc/issues/978) and reflected through initial application to [Incubation on 13-NOV-2023](https://github.com/cncf/toc/pull/1209) and subsequent [application in the updated format on 4-APR-2024](https://github.com/cncf/toc/issues/1291)
+
+- [ ] **Due Diligence Review.**
+
+Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.
+
+- [ ] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.**
+
+The project provides adopters with appropriate documentation for installation and configuration of Kubescape, to include necessary prerequisites, 
+
+## Governance and Maintainers
+
+Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
+
+### Suggested
+
+- [ ] **Clear and discoverable project governance documentation.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **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.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Governance clearly documents [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+### Required
+
+- [ ] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.**
+
+Kubescape maintains its list of maintainers for the core repository at https://github.com/kubescape/kubescape/blob/master/MAINTAINERS.md. This file has been changed 6 times since its creation on 06-JAN-2022.
+
+The project has the following additional respositories with Maintainer files:
+* Helm-charts: https://github.com/kubescape/helm-charts/blob/main/MAINTAINERS.md
+* regolibrary: https://github.com/kubescape/regolibrary/blob/master/MAINTAINERS.md - added 05-NOV-2023, no changes since. No roles defined, clear association with regolibrary
+
+- [ ] **A number of active maintainers which is appropriate to the size and scope of the project.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document agreement that project will adopt CNCF Code of Conduct.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **CNCF Code of Conduct is cross-linked from other governance documents.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **All subprojects, if any, are listed.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+## Contributors and Community
+
+Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
+
+### Suggested
+
+- [ ] **Contributor ladder with multiple roles for contributors.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+### Required
+
+- [ ] **Clearly defined and discoverable process to submit issues or changes.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Project must have, and document, at least one public communications channel for users and/or contributors.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **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.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Documentation of how to contribute, with increasing detail as the project matures.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Demonstrate contributor activity and recruitment.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+## Engineering Principles
+
+### Suggested
+
+- [ ] **Roadmap change process is documented.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **History of regular, quality releases.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+### Required 
+
+- [ ] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document what the project does, and why it does it - including viable cloud native use cases.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document the project's release process.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+## Security
+
+Note: this section may be augemented by a joint-assessment performed by TAG Security.
+
+### Suggested
+
+N/A
+
+### Required
+
+- [ ] **Clearly defined and discoverable process to report security issues.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document assignment of security response roles and how reports are handled.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Document Security Self-Assessment.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+## Ecosystem
+
+### Suggested
+
+N/A
+
+### Required
+
+- [ ] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [ ] **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)**
+
+<!-- (TOC Evaluation goes here) --> 
+
+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.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+Refer to the Adoption portion of this document.
+
+- [ ] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+#### Adoption
+
+##### Adopter 1 - $COMPANY/$INDUSTRY
+
+_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._
+MONTH YEAR
+
+##### Adopter 2 - $COMPANY/$INDUSTRY
+
+_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._
+MONTH YEAR
+
+##### Adopter 3 - $COMPANY/$INDUSTRY
+
+_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._
+MONTH YEAR

From 6df068b40d5c93323ab042fc0ec9bf6cc56bc6e6 Mon Sep 17 00:00:00 2001
From: Emily Fox <themoxiefoxatwork@gmail.com>
Date: Mon, 28 Oct 2024 13:11:08 -0400
Subject: [PATCH 2/7] What: Initial draft Kubescape Incubation DD

Why:
 * capture the current near-final DD, pending updates from maintainers

This change address the need by:
 * establishes the DD document for the project.

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
---
 .../kubescape-incubation-proposal.md          | 355 ++++++++++++++++++
 1 file changed, 355 insertions(+)
 create mode 100644 projects/kubescape/kubescape-incubation-proposal.md

diff --git a/projects/kubescape/kubescape-incubation-proposal.md b/projects/kubescape/kubescape-incubation-proposal.md
new file mode 100644
index 000000000..d5babfb95
--- /dev/null
+++ b/projects/kubescape/kubescape-incubation-proposal.md
@@ -0,0 +1,355 @@
+# Kubescape Incubation Due Diligence
+
+- Link to [Incubation application issue](https://github.com/cncf/toc/issues/1291)
+
+## Incubation Evaluation Summary for Kubescape
+
+### Criteria Evaluation
+
+_Emily Fox (@TheFoxAtWork) conducted the due diligence of Kubescape who applied for Incubation Level. The project has completed the criteria that show its early maturity at Incubation level. While the project meets the expectations of an early-stage Incubating level project, it could greatly benefit from a dedicated focus on its community, documentation, and overall governance.
+
+The following actions were provided to the project that were considered blocking but since resolved:
+* Completion of the self-assessment
+* Document the project's release 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:
+* Reorganization/improvided structure and interlinking of the documentation, repos, and files
+* Increased detail and robustness of the existing community, contributing, and governance documentation that provides better focus for potential contributors
+* Provide a contributor ladder and improve the clarity around how contributors become committers and eventually maintainers. This should also include details about how and when maintainers and committers are removed from their roles
+* Engage with TAG Contributor Strategy for a comprehensive Governance Review and discussion on community engagement and expansion to increase company diveristy and variety of contributors to the project and complete the recommendations detailed in the governance and maintainer section as bullets and as full text to prior to initiating that engagement
+* Provide tutorials that walk through and explain how the project is used and removes assumptions in the Getting Started guide
+* Detail the sub-projects and repos of Kubescape to include a brief descriptor of what they are, if they are core to the project, their status, and who is responsbile for maintaining them
+
+### Adoption Evaluation
+
+The adopter interviews reflect a project in appropriate use for the level which the project applied. Interviews with Adopters commend the project's ease of use, breadth of capability, and friendliness of its maintainers.
+
+### Final Assessment
+
+The TOC has found the project to have satisfied the criteria for Incubation Level.
+
+The project could greatly benefit from several recommendations detailed throughout this Due Diligence, much of which would be addressed by reorganizing the project's website documentation, removing duplicative or out-of-date content, and establishing a dedicated area for governance, contributions, and community items for easier discoverability. It appears the structure for this has been started but not completed.
+
+## Application Process Principles
+
+### Suggested
+
+N/A
+
+### Required
+
+- [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness**
+  - This was completed and occurred on 10-JULY-2024, and can be discovered at the [TAG's meeting notes for that session](https://docs.google.com/document/d/1XDmNG1P1YRnidQJEuZFKufaXaIenNHiY-TdYMlt0Un4/edit#heading=h.cbsth4x8m975) and the [issue link for that presentation](https://github.com/cncf/tag-security/issues/1262).
+
+The Project presented to TAG Security on 10-JULY-2024 and provided the community with an update on new capabilities of the project, feedback by the community and the TAG was engaging and did not appear to raise any concerns with the project.
+
+- [X] **TAG provides insight/recommendation of the project in the context of the landscape**
+
+At the July 10th, 2024 presentation to TAG Security, Kubescape was provided the following recommendations: 
+
+> Recommendation for the project to engage with the End User TAB for seeking feedback on these features.
+
+> Recommendation to look at existing open source projects (SIG-infra, etc.) with substantial infrastructure (build systems for instance) to see if they are willing to test out those features.
+
+"Features" referring to several new capabilities that allows the project to auto-generate policies/configuration that support its goals to provide a runtime-powered k8s security platform.  To provide all k8s security needs under a single project.
+
+- [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).**
+
+The project's communications, planning, and docs align with CNCF stated guidelines for project neutrality. It is noted that the project does maintain a providers file, for which ARMO is the only one listed. However, any contributor is welcome to submit a PR to add additional providers in accordance with the information provided on the [project's docs page for providers](https://kubescape.io/docs/providers/).
+
+- [X] **Review and acknowledgement of expectations for [Sandbox](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.**		
+- Met during Project's [initial application on 13-DEC-2022 to CNCF](https://github.com/cncf/toc/issues/978) and reflected through initial application to [Incubation on 13-NOV-2023](https://github.com/cncf/toc/pull/1209) and subsequent [application in the updated format on 4-APR-2024](https://github.com/cncf/toc/issues/1291)
+
+- [ ] **Due Diligence Review.**
+
+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.**
+
+The project provides adopters with appropriate documentation for installation and configuration of Kubescape given its maturity level, to include necessary [prerequisites](https://kubescape.io/docs/install-operator/), however it is important to note that the docs may introduce some confusion for adopters looking to get started as the [Getting Started guide](https://kubescape.io/docs/getting-started/) has different instructions than [the client](https://kubescape.io/docs/install-cli/) and [cluster install](https://kubescape.io/docs/install-operator/). 
+
+It is recommended the project convert the Getting Started page to be more tutorial-oriented. The getting started page makes several assumptions, such as access to a machine already running a cluster. In order to more efffectively allow potential adopters to try out Kubescape, providing them a tutorial they can run locally that expands on the Overview section, and potentially suggests how the output of Kubescape can be releveraged for achieving security outcomes (i.e. continuous monitoring for compliance with CIS benchmarks) with existing dashboards, tools, and other monitoring and visibility solutions (i.e. linking to the [preometheus operator instructions](https://kubescape.io/docs/operator/prometheus-integration/) or the[ VEX document generation](https://kubescape.io/docs/operator/generating-vex/#what-is-vex)).
+
+## Governance and Maintainers
+
+Note: This section was completed leveraging TAG Contributor Strategy's Governance Review template and was conducted on the project's governance document from the following commit: [accc8a38347297ef41d72deef617af5a8995d22b](https://github.com/kubescape/kubescape/commit/accc8a38347297ef41d72deef617af5a8995d22b).
+
+The following items are considered non-blocking for Incubation level but if unresolved will see the community stagnate and the project fail to meet criteria for Graduation.
+* Cross link appropriate files, contributing, maintainers, and governance are all related topics and content and should be appropriately linked to answer community questions and provide a complete understanding of how the project operates and how individuals may grow, progress, and advance the project.
+* The maintainer file needs updated to reflect the correct maintainers and their affiliation
+* The governance should be updated to:
+  * reduce duplication of content, 
+  * ensure all names roles are held to the same expectations of conduct and adherence to governance, 
+  * define how and when decisions are made by the maintainers, 
+  * define a contributor ladder which leverages existing merit of contributions (such as committer role) for maintainership eligibility, 
+  * update security-insights to correctly reflect the maintainers of the project
+* Create a clear focus for community engagement
+  * Ensure the meeting DAY of the week and meeting notes are linked under ##Community on the read me as well as in the contributor guide.
+  * Determine appropriate scope for slack channels and actively promote that usage for those channels (within them and within the project docs/repo)
+  * Define the use of “ideas” versus proposals and issues for the project, make better use of the [proposals folder structure](https://github.com/kubescape/kubescape/tree/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/proposals) and define this as part of the contributing file.
+
+The maintainers file (https://github.com/kubescape/kubescape/commit/74bfb57d3a135645f1c9ea9ab0e78d718dbf76f9) is complete with 5 individuals listed but is out of date as one maintainer currently works at Kaleido. The governance describes the expectations of maintainers and the requirements for consideration as maintainer. It also describes the conditions under which a maintainer is removed, this is limited to their activities on project work within a 12 month window. The governance also details a role known as committer and the method for proposing contributors to become committers. There is no contingency to be a committer prior to application as a maintainer.
+
+The governance details how changes are proposed and how conflicts are resolved with some duplication and additional information on roles and responsibilities of maintainers, committers, and community members. Not all expectations are shared equally among the roles, notably the community members only have a call out to abide by the code of conduct and project governance. This should be updated to ensure equal expectations.
+
+The project maintains a brief CONTRIBUTING file (https://github.com/kubescape/kubescape/commit/33577139034d2d9d248741dd83496c20a86e204b) that details two types of contributions to appropriately guide contributors on how contributions are made, but does not reference the Ideas category of discussions on the repo as a mechanism for proposing changes. The contributions file includes a link to instructions on building and testing locally which directs users to a Wiki on the project repo and additional transitive links to getting-started docs. The contributing file does not provide any information on communications channels or community meetings and should be updated to do so.
+
+The project does not have a contributor ladder independent of or as part of their contributing guide or governance document. It is recommended the project establish one.
+
+The governance does not detail how decision making by the maintainers occurs nor the manner by which submitted proposals warrant decisions by maintainers. The governance should be updated to incorporate these.
+
+The project does maintain a security.md file (https://github.com/kubescape/kubescape/commit/accc8a38347297ef41d72deef617af5a8995d22b)  that details how security issues are reported and responded. The project also has a security-insights file (https://github.com/kubescape/kubescape/commit/915d5d993b389c2243e0d6295c805f6a6fb5c358 ) for adopters and contributors to understand the security practices the project employs.
+
+Meetings are recorded and uploaded to Youtube. The meeting notes link was previously buried in a comment on a Kubescape discussion and has since been added to the README for the projec and linked in the Contributor guide. The meeting notes are titled "Kubescape Developer Sync", with the regular meeting attendees typically not more than two individuals who both employed by ARMO. The meeting notes document only goes back to February of 2024 with gaps in frequency.
+
+The project’s slack channel’s are active, notable the #kubescape primary channel is used by potential adopters and contributors to ask questions of how the project operates or any issues/bugs/challenges experienced. The Kubescape-dev channel does get reminder notifications of the upcoming community meeting but it and the meeting notes document seem more focused on the development of the project which may deter some interested contributors as not being approachable (not devs of the project ergo the meeting may not be appropriate for them to attend). This channel also overlaps in troubleshooting and project functionality discussions which occur in the Kubescape channel generally.
+
+### Suggested
+
+- [X] **Clear and discoverable project governance documentation.**
+
+The Governance document is located in the primary Kubescape repo (kubescape/kubescape/GOVERNANCE.md) It does not contain links or references to other documents. For individuals looking to discovery governance of the project, it is fairly straightforward to find. The project’s website does not provide links to or reference’s the project’s governance. The file is clearly named, and does not appear to be linked from the project’s other repositories. While the current governance is simple and clear, improvements are encouraged.
+
+- [ ] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.**
+
+The governance appears largely unchanged since being added.
+
+- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.**
+
+The Governance shows some small drift and deviation but is not considered substantial. Improvements are recommended to bring the current governance execution into alignment with the next maturity level beyond Incubation.
+
+- [ ] **Governance clearly documents [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.**
+
+While the governance is not explicit in calling out neutrality, the overall structure does support vendor-neutrality.
+
+- [ ] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.**
+
+The governance does detail how the projects makes _some_ decisions on leadership but improvements could be made to ensure clarity of this process and its expectations. Contribution acceptance, requests, and changes to governance and goals should also be added.
+
+- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).**
+
+The project does not currently have this.
+
+- [ ] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).**
+
+The project does not define a maintainer lifecycle beyond activity within a 12-month window for the maintainer to remain in role.
+
+- [ ] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.**
+
+Not demonstrable with the current governance.
+
+- [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.**
+
+The project does have several components but their leadership and governance relationship with the core project is not detailed.
+
+### Required
+
+- [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.**
+
+Kubescape maintains its list of maintainers for the core repository at https://github.com/kubescape/kubescape/blob/master/MAINTAINERS.md. This file has been changed 6 times since its creation on 06-JAN-2022.
+
+The project has the following additional respositories with Maintainer files:
+* Helm-charts: https://github.com/kubescape/helm-charts/blob/main/MAINTAINERS.md
+* regolibrary: https://github.com/kubescape/regolibrary/blob/master/MAINTAINERS.md - added 05-NOV-2023, no changes since. No roles defined, clear association with regolibrary
+
+- [X] **A number of active maintainers which is appropriate to the size and scope of the project.**
+
+The project has 5 maintainers listed on the main repo, 1 appears to be reasonably active within the past year, with additional 'committers' supporting the project. Overall activity of the repo appears to have slowed in the past year, with fewer new PRs at an increased rate of merging, indicative of increasing maturity and focus on stability of the project.
+
+- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.**
+
+The project's code and doc ownership appear to match the documented governance roles for the project, however several repos under the project are lacking maintainer and contributing files or links to the overarching files for the project.
+
+- [X]] **Document agreement that project will adopt CNCF Code of Conduct.**
+
+[The project has adopted the CNCF Code of Conduct.](https://github.com/kubescape/kubescape/commit/0eb27389daeff7dc545258cfe0f488c6b8c7a2f4)
+
+- [X] **CNCF Code of Conduct is cross-linked from other governance documents.**
+
+The Code of Conduct is linked in the [Contributing file](https://github.com/kubescape/kubescape/blob/1cad446fe65f470add1ec68fdc602f1f4c144740/CONTRIBUTING.md?plain=1#L16) and the [Governance file](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/GOVERNANCE.md?plain=1#L7) for the project.
+
+- [X] **All subprojects, if any, are listed.**
+
+The project's organization contains repos for all sub-projects, but does not have a comprehensive singular listing of each and their purpose or status.
+
+The project should inventory its org and provide a navigation guide of its sub-projects, any maintainers of the sub-projects, the intent and focus of the project, as well as its state/status. With 55 repos, it is not immediately clear to contributors and adopters what is and is not supported. Additionally, the .github repo appears to be an initial attempt to move community and governance material to a dedicated area, highly recommend finalizing this.
+
+## Contributors and Community
+
+Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
+
+### Suggested
+
+- [ ] **Contributor ladder with multiple roles for contributors.**
+
+It is recommended the project establish a contributor ladder that aligns with the roles described in the governance document.
+
+### Required
+
+- [X] **Clearly defined and discoverable process to submit issues or changes.**
+
+The Contributing file provides information for community members on suggesting changes but could be improved.
+
+- [X] **Project must have, and document, at least one public communications channel for users and/or contributors.**
+
+The project lists its slack channels on its [README under Community](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/README.md?plain=1#L98). They are also included in the Contributing file.
+
+- [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 project has listed all their communication channels. 
+
+- [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.**
+
+The project has regular meetings as reflected in the README and an automated notice of the meeting in their slack channel. Community members have recently requested adding the project meeting to the CNCF calendar, and the project is working towards this.
+
+- [X] **Documentation of how to contribute, with increasing detail as the project matures.**
+
+The project provides a simple and straightforward contributing guide that is sufficient for a project just entering incubation, however it is recommended this be developed further to be more robust and cover all aspects of contributing to the project, to include triage, PR reviews, etc. The project would benefit from linking the [third party dependency policy](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/environment-dependencies-policy.md) with the Contributing file and the Governance file.
+
+- [X] **Demonstrate contributor activity and recruitment.**
+
+The project's slack channels are active with community members asking questions and the project's regular meetings are leveraged to serve as encouragement for more contributions. The project would greatly benefit from more active outreach to community members to take up open issues on the repo.
+
+## Engineering Principles
+
+### Suggested
+
+- [ ] **Roadmap change process is documented.**
+
+The project does not currently have a change process for its Roadmap documented and  does not appear to use milestones or appear to associate issues or PRs with planned releases. This will be essential to the project moving forward in order to not only facillitate more clear direction for the project, but encourage more participation by potential contributors.
+
+- [ ] **History of regular, quality releases.**
+
+Since 2022, the project has been increasing the rigor of their release process, providing better detail post-release and no adopters have reported any issues. The current release cadence does not appear to be set yet, but is approaching some normalcy.
+
+### 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.**
+
+The project's goals are detailed in their README and in the project's documentation and provides its focus within the cloud native landscape.
+
+- [X] **Document what the project does, and why it does it - including viable cloud native use cases.**
+
+The project's README and docs describe what the project does and why. It also includes information on how the project is to be used in cloud native environments for achieving security outcomes like runtime threat detection and compliance.
+
+- [X] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.**
+
+The project maintains a [ROADMAP](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/roadmap.md) but is difficult to find. It is recommended the project make this file easier to find both in the Project's website docs as well as in the repo.
+
+- [X] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
+
+The project maintains an older [architecture document](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/architecture.md) but should be updated to more appropriately reflects the current capabilities of the project and its sub-projects to match the more recent version of the [architecture located in the project's README](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/README.md#architecture).
+
+- [ ] **Document the project's release process.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+## Security
+
+Note: this section may be augemented by a joint-assessment performed by TAG Security.
+
+### Suggested
+
+N/A
+
+### Required
+
+- [X] **Clearly defined and discoverable process to report security issues.**
+
+The project maintains a SECURITY.md file which contains the process for reporting security issues.
+
+- [X] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)**
+
+The project's maintainer accounts are protected with 2FA.
+
+- [X] **Document assignment of security response roles and how reports are handled.**
+
+The SECURITY.md file includes
+
+- [ ] **Document Security Self-Assessment.**
+
+<!-- (TOC Evaluation goes here) --> 
+
+- [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.**
+
+The project maintains the [OpenSSF's best practices badge at the Passing level.](https://www.bestpractices.dev/en/projects/6944)
+
+## Ecosystem
+
+### Suggested
+
+N/A
+
+### Required
+
+- [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)**
+
+The project's current [ADOPTER.md](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/ADOPTERS.md) file lists the publicly known adopters. As this project provides security functionality for adopters, it is highly probable that more organizations are using the project than indicated publicly as many organizations do not disclose what tools they use to achieve security outcomes.
+
+- [X] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)**
+
+The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.
+
+- [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.**
+
+The project's architecture and [README's "under the hood" section](https://github.com/kubescape/kubescape/blob/master/README.md#under-the-hood) list other open source projects Kubescape leverages as part of its capabilities.
+
+#### Adoption
+
+##### Adopter 1 - Bitnami/Broadcom
+
+_Carlos Rodriguez-Hernandez_
+SEPTEMBER 2024
+
+Binami, a catalog which provides packages of open source projects, has packaged and provided the Kubescape project for about a year and a half to its users. Committed to open source projects, Kubescape was identified by Bitnami to add a container security insights tool into their catalog that went beyond singular cloud native security capabilities.
+
+Bitnami’s adoption and integration into their packaging and tooling pipeline for publication into the catalog was seamless and the team did not report any issues with it. It is currently available in their production catalog instance for users. Bitnami uses Kubescape as part of its security assessment and remediation process for packaged open source projects it provides in its catalog. Results of Kubescape’s scanning and reporting are provided to users alongside additional security analysis results to allow users to reason about the security posture of the packaged project.
+
+As soon as new features and capabilities are reported in the Kubescape change log, the Bitnami team evaluates those changes to ascertain potential value for their users. When complete, the Bitnami team employs a delayed update process that allows them to update to the latest version of Kubescape after appropriate stability, testing, and integration is completed; approximately 30 days. Bitnami did not report any challenges or issues with adoption and integration of the project, by themselves or reported by their users, citing it “...was super easy to integrate in the CI/CD pipelines, the service and the tool is very easy to deploy, the output is easy to consume and leverage as an input to other tools…” in their environment.They further mentioned that in completing the proof of concept, Kubescape required no modifications and just worked out of the box.
+
+Bitnami found the project’s documentation and repository to be well organized and easy to navigate, with robust information that did not require them to engage the project for clarification or assistance. The team has collaborated with the Kubescape project to increase awareness of Kubescape’s impact on Bitnami’s Helm charts through blogs that reflect the results of adopting Kubescape (April 2024) as well as Bitnami’s selection of Kubescape for those their catalog (July 2024).
+
+Bitnami points out that the only thing holding the project back from more rampant adoption is the current lack of visibility and awareness to other potential adopters and plans to continue collaborating with the project to increase awareness.
+
+##### Adopter 2 - KYOS Energy Consulting
+
+_Zois Pagoulatos_
+OCTOBER 2024
+
+Note: This Adopter uses the Kubescape project through ARMO’s cloud security platform, a vendor offering which provides additional integrations and enrichment on top of Kubescape. This interview focuses on the benefits and experience of the underlying Kubescape project and not on capabilities exclusive to ARMO’s offering. 
+
+KYOS Energy Consulting has been using the Kubescape project for just over a year; March 2023. As part of their cloud-native journey, KYOS began experimenting with Kubernetes to move workloads. As with more organizations early in such digital transformation, KYOS Energy Consulting was looking to scale their security expertise in this new technology area, particularly around configuration security as it continues to be one of the top weaknesses contributing to incidents. They evaluated several projects but needed a solution that was more inclusive of all aspects of Kubernetes Security, instead of point solutions limited to singular capabilities like vulnerability scanning or network policy security alone. After watching an online demo of Kubescape, KYOS Energy Consulting tried out the project in their Kubernetes environment. In the course of their integration, the only challenge cited was in the combination of Kubescape and ArgoCD. An adopter of GitOps, KYOS Energy Consulting engaged the Kubescape team to resolve the drift they were experiencing.  The team was very responsive, and the installation was smooth.
+
+Deployed in production, KYOS Energy Consulting has had positive engagement with the maintainers, deep diving into resource utilization challenges in the cluster, unique and custom applications and technology resulting in interesting notifications, and general debugging.
+
+Through their experience, KYOS Energy Consulting has been quite happy with their choice of Kubescape, citing the project provides nearly all their needs for security in Kubernetes, continuously adding features and capabilities they didn't know they needed, contributing positively to not only the security of their clusters but also allowing their engineers to gain confidence in their adoption of cloud-native technologies and in particular the value of Kubernetes. Kubescape has reduced the volume of false positives, and the network policy suggestions are extremely helpful. The team reviews suggestions from Kubescape prior to applying them to confirm their accuracy and viability in their environment which has relieved pressure on the engineering team in developing and managing such policies. KYOS Energy Consulting further commented on their satisfaction in the integrity of the project, as a small team they plan to continue using the project even if they weren't leveraging the vendor offering. They currently contribute to the Kubescape project unofficially, and are working on transitioning from another cloud provider. They’ve already added new clusters to Kubescape and are excited at the upcoming features under development by the project.
+
+
+##### Adopter 3 - Anonymous Finance
+
+_Adopter and organization are anonymous_
+OCTOBER 2024
+
+Adopter 3 has been using the Kubescape project for approximately 3 years. The Interviewee had familiarity and experience with using Kubescape at their previous employer and had been satisfied with its ability to address the security of their clusters, making introduction of the project to Adopter 3 a clear choice. 
+
+Adopter 3’s motivation in adopting Kubescape was to address the need of shifting operational cluster security left in the development lifecycle, allowing the team to test and verify the security of their clusters before they become operational in production. Their workflow includes a staggered deployment pipeline that leverages Kubescape to scan clusters in a non-prod environment, test and verify the recommendation changes based on scan results from Kubescape, and then deploy those changes in their production environment. This workflow reduces the likelihood that a recommended change from Kubescape regarding their cluster security posture will adversely impact their production workloads, allowing them to catch problematic changes before the impact is realized.
+
+Each time Adopter 3’s pipeline runs, it checks for and pulls the most recent version of Kubescape available, this ensures they are getting updated vulnerability information as part of their workflow. Adopter 3 uses the Kubescape Helm charts for installation, maintaining their Kubescape Manifests in a repo for installation as part of their pipeline. They also execute push based scans in their pipeline, finding the overall experience of installation and integration of Kubescape as simple as Grafana.
+
+Adopter 3 uses the Kubescape core feature set (posture management, configuration, compliance, hardening) in all their environments. They are not currently using Kubescape to provide runtime security monitoring due to their workflow to reduce the risk of production issues. Adopter 3 is leveraging the application profile rule set in a limited capacity at this time, fully testing it before developing plans to roll this out further.
+
+The Kubescape project was early for its time, and when adopted by Adopter 3, was the only tool with clear community support and provided the most complete feature set for managing cluster security which addressed Adopter 3’ s requirements. Adopter 3’s use of Kubescape has provided immeasurable value, as a multi-cloud and multi-cluster entity, Adopter 3 loves the agnostic support of cloud service providers that Kubescape provides, particularly capacity to support their GitOps flow via Flux. Of particular value to Adopter 3, is the speed at which they are able to deploy new, compliant clusters into their production environments. They have shared clusters, production and non-production per region with node pool isolation which leverage canary deploys to roll out compliant clusters. While they have other tools they must actively troubleshoot, their use of Kubescape with Helm and Flux just works.
+
+While Kubescape does not fully encompass needs for multi-layer security at this time, its capacity to facilitate posture management and misconfiguration was noted by Adopter 3 as one of the best. Adopter 3 believes their use of the Kubescape project has contributed meaningfully to their current “zero breach streak”. 
+
+It has been always clear what the project does as the documentation and repo is very complete and well organized. Adopter 3 has a dedicated communication channel with the project to facilitate quick fixes, such as Helm chart backwards compatibility. Adopter 3 has been particularly pleased with the separation between the Vendor which contributed the project to CNCF (Armo), it’s enterprise offering, and the Kubescape community – while separate, there is focus on alignment of capabilities which allows Adopter 3 to continue using the open source project with optionality to pursue an enterprise offering in the future that will work with their existing architecture should they need it.
+
+Over the years of using the Kubescape project, Adopter 3 has developed a friendship with the project, engaging in discussion regarding features and providing feedback to the project on areas of improvement or capabilities and has participated in a presentation regarding functionality of Kubescape at a previous CNCF conference. 
+
+Adopter 3 believes the Kubescape project could do more with an expanded scope but did not cite any particular features they wanted from the project, having an existing positive engagement to field those with the project. They did note the potential for the project to become a fully featured CNAPP solution, a goal they believe Kubescape is pursuing.
+
+Regarding their future plans with Kubescape, Adopter 3 is looking into a way they could create application profiles in their non-production environment; providing coverage of runtime security. Their current path is to build once and deploy many so each deployment matches, this will likely require them to keep the eBPF component in their non-production environment and apply the created profiles in production without having to execute the learning in production environments. Adopter 3 noted the additional overhead of alert management in production will require focus on false-positive noise suppression as one of several reasons to keep this within their non-production environments.

From 9aa3280247d8c9202ea5826941fda52334496b50 Mon Sep 17 00:00:00 2001
From: Emily Fox <themoxiefoxatwork@gmail.com>
Date: Mon, 28 Oct 2024 13:16:38 -0400
Subject: [PATCH 3/7] What: update with correct links/spelling

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
---
 projects/kubescape/kubescape-incubation-proposal.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/projects/kubescape/kubescape-incubation-proposal.md b/projects/kubescape/kubescape-incubation-proposal.md
index d5babfb95..02570bd71 100644
--- a/projects/kubescape/kubescape-incubation-proposal.md
+++ b/projects/kubescape/kubescape-incubation-proposal.md
@@ -6,7 +6,7 @@
 
 ### Criteria Evaluation
 
-_Emily Fox (@TheFoxAtWork) conducted the due diligence of Kubescape who applied for Incubation Level. The project has completed the criteria that show its early maturity at Incubation level. While the project meets the expectations of an early-stage Incubating level project, it could greatly benefit from a dedicated focus on its community, documentation, and overall governance.
+Emily Fox (@TheFoxAtWork) conducted the due diligence of Kubescape who applied for Incubation Level. The project has completed the criteria that show its early maturity at Incubation level. While the project meets the expectations of an early-stage Incubating level project, it could greatly benefit from a dedicated focus on its community, documentation, and overall governance.
 
 The following actions were provided to the project that were considered blocking but since resolved:
 * Completion of the self-assessment
@@ -68,7 +68,7 @@ Completion of this due diligence document, resolution of concerns raised, and pr
 
 The project provides adopters with appropriate documentation for installation and configuration of Kubescape given its maturity level, to include necessary [prerequisites](https://kubescape.io/docs/install-operator/), however it is important to note that the docs may introduce some confusion for adopters looking to get started as the [Getting Started guide](https://kubescape.io/docs/getting-started/) has different instructions than [the client](https://kubescape.io/docs/install-cli/) and [cluster install](https://kubescape.io/docs/install-operator/). 
 
-It is recommended the project convert the Getting Started page to be more tutorial-oriented. The getting started page makes several assumptions, such as access to a machine already running a cluster. In order to more efffectively allow potential adopters to try out Kubescape, providing them a tutorial they can run locally that expands on the Overview section, and potentially suggests how the output of Kubescape can be releveraged for achieving security outcomes (i.e. continuous monitoring for compliance with CIS benchmarks) with existing dashboards, tools, and other monitoring and visibility solutions (i.e. linking to the [preometheus operator instructions](https://kubescape.io/docs/operator/prometheus-integration/) or the[ VEX document generation](https://kubescape.io/docs/operator/generating-vex/#what-is-vex)).
+It is recommended the project convert the Getting Started page to be more tutorial-oriented. The getting started page makes several assumptions, such as access to a machine already running a cluster. In order to more efffectively allow potential adopters to try out Kubescape, providing them a tutorial they can run locally that expands on the Overview section, and potentially suggests how the output of Kubescape can be releveraged for achieving security outcomes (i.e. continuous monitoring for compliance with CIS benchmarks) with existing dashboards, tools, and other monitoring and visibility solutions (i.e. linking to the [prometheus operator instructions](https://kubescape.io/docs/operator/prometheus-integration/) or the[ VEX document generation](https://kubescape.io/docs/operator/generating-vex/#what-is-vex)).
 
 ## Governance and Maintainers
 
@@ -88,17 +88,17 @@ The following items are considered non-blocking for Incubation level but if unre
   * Determine appropriate scope for slack channels and actively promote that usage for those channels (within them and within the project docs/repo)
   * Define the use of “ideas” versus proposals and issues for the project, make better use of the [proposals folder structure](https://github.com/kubescape/kubescape/tree/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/proposals) and define this as part of the contributing file.
 
-The maintainers file (https://github.com/kubescape/kubescape/commit/74bfb57d3a135645f1c9ea9ab0e78d718dbf76f9) is complete with 5 individuals listed but is out of date as one maintainer currently works at Kaleido. The governance describes the expectations of maintainers and the requirements for consideration as maintainer. It also describes the conditions under which a maintainer is removed, this is limited to their activities on project work within a 12 month window. The governance also details a role known as committer and the method for proposing contributors to become committers. There is no contingency to be a committer prior to application as a maintainer.
+The [maintainers file](https://github.com/kubescape/kubescape/commit/74bfb57d3a135645f1c9ea9ab0e78d718dbf76f9) is complete with 5 individuals listed but is out of date as one maintainer currently works at Kaleido. The governance describes the expectations of maintainers and the requirements for consideration as maintainer. It also describes the conditions under which a maintainer is removed, this is limited to their activities on project work within a 12 month window. The governance also details a role known as committer and the method for proposing contributors to become committers. There is no contingency to be a committer prior to application as a maintainer.
 
 The governance details how changes are proposed and how conflicts are resolved with some duplication and additional information on roles and responsibilities of maintainers, committers, and community members. Not all expectations are shared equally among the roles, notably the community members only have a call out to abide by the code of conduct and project governance. This should be updated to ensure equal expectations.
 
-The project maintains a brief CONTRIBUTING file (https://github.com/kubescape/kubescape/commit/33577139034d2d9d248741dd83496c20a86e204b) that details two types of contributions to appropriately guide contributors on how contributions are made, but does not reference the Ideas category of discussions on the repo as a mechanism for proposing changes. The contributions file includes a link to instructions on building and testing locally which directs users to a Wiki on the project repo and additional transitive links to getting-started docs. The contributing file does not provide any information on communications channels or community meetings and should be updated to do so.
+The project maintains a brief [CONTRIBUTING file](https://github.com/kubescape/kubescape/commit/33577139034d2d9d248741dd83496c20a86e204b) that details two types of contributions to appropriately guide contributors on how contributions are made, but does not reference the Ideas category of discussions on the repo as a mechanism for proposing changes. The contributions file includes a link to instructions on building and testing locally which directs users to a Wiki on the project repo and additional transitive links to getting-started docs. The contributing file does not provide any information on communications channels or community meetings and should be updated to do so.
 
 The project does not have a contributor ladder independent of or as part of their contributing guide or governance document. It is recommended the project establish one.
 
 The governance does not detail how decision making by the maintainers occurs nor the manner by which submitted proposals warrant decisions by maintainers. The governance should be updated to incorporate these.
 
-The project does maintain a security.md file (https://github.com/kubescape/kubescape/commit/accc8a38347297ef41d72deef617af5a8995d22b)  that details how security issues are reported and responded. The project also has a security-insights file (https://github.com/kubescape/kubescape/commit/915d5d993b389c2243e0d6295c805f6a6fb5c358 ) for adopters and contributors to understand the security practices the project employs.
+The project does maintain a [security.md file](https://github.com/kubescape/kubescape/commit/accc8a38347297ef41d72deef617af5a8995d22b)  that details how security issues are reported and responded. The project also has a [security-insights file](https://github.com/kubescape/kubescape/commit/915d5d993b389c2243e0d6295c805f6a6fb5c358 ) for adopters and contributors to understand the security practices the project employs.
 
 Meetings are recorded and uploaded to Youtube. The meeting notes link was previously buried in a comment on a Kubescape discussion and has since been added to the README for the projec and linked in the Contributor guide. The meeting notes are titled "Kubescape Developer Sync", with the regular meeting attendees typically not more than two individuals who both employed by ARMO. The meeting notes document only goes back to February of 2024 with gaps in frequency.
 
@@ -146,7 +146,7 @@ The project does have several components but their leadership and governance rel
 
 - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.**
 
-Kubescape maintains its list of maintainers for the core repository at https://github.com/kubescape/kubescape/blob/master/MAINTAINERS.md. This file has been changed 6 times since its creation on 06-JAN-2022.
+Kubescape maintains its list of [maintainers for the core repository](https://github.com/kubescape/kubescape/blob/master/MAINTAINERS.md). This file has been changed 6 times since its creation on 06-JAN-2022 as of October 2024.
 
 The project has the following additional respositories with Maintainer files:
 * Helm-charts: https://github.com/kubescape/helm-charts/blob/main/MAINTAINERS.md

From c7f46bc31645ed68c46f44980b8687ec8b268784 Mon Sep 17 00:00:00 2001
From: Emily Fox <themoxiefoxatwork@gmail.com>
Date: Wed, 30 Oct 2024 14:05:22 -0400
Subject: [PATCH 4/7] What: small corrections to spelling & readability

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
---
 .../kubescape/kubescape-incubation-proposal.md    | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/projects/kubescape/kubescape-incubation-proposal.md b/projects/kubescape/kubescape-incubation-proposal.md
index 02570bd71..99cc63124 100644
--- a/projects/kubescape/kubescape-incubation-proposal.md
+++ b/projects/kubescape/kubescape-incubation-proposal.md
@@ -9,20 +9,21 @@
 Emily Fox (@TheFoxAtWork) conducted the due diligence of Kubescape who applied for Incubation Level. The project has completed the criteria that show its early maturity at Incubation level. While the project meets the expectations of an early-stage Incubating level project, it could greatly benefit from a dedicated focus on its community, documentation, and overall governance.
 
 The following actions were provided to the project that were considered blocking but since resolved:
-* Completion of the self-assessment
+* Completion of the security self-assessment
 * Document the project's release 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:
-* Reorganization/improvided structure and interlinking of the documentation, repos, and files
+* Reorganization/improved structure and interlinking of the documentation, repos, and files
 * Increased detail and robustness of the existing community, contributing, and governance documentation that provides better focus for potential contributors
 * Provide a contributor ladder and improve the clarity around how contributors become committers and eventually maintainers. This should also include details about how and when maintainers and committers are removed from their roles
-* Engage with TAG Contributor Strategy for a comprehensive Governance Review and discussion on community engagement and expansion to increase company diveristy and variety of contributors to the project and complete the recommendations detailed in the governance and maintainer section as bullets and as full text to prior to initiating that engagement
-* Provide tutorials that walk through and explain how the project is used and removes assumptions in the Getting Started guide
-* Detail the sub-projects and repos of Kubescape to include a brief descriptor of what they are, if they are core to the project, their status, and who is responsbile for maintaining them
+* Engage with TAG Contributor Strategy for a comprehensive Governance Review and discussion on community engagement and expansion to increase company diversity and variety of contributors to the project.
+  * Complete the recommendations detailed in the governance and maintainer section (bullets and as full text) prior to initiating that engagement with TAG Contributor Strategy
+* Provide tutorials that walk through and explain how the project is used and removes implicit assumptions in the Getting Started guide, recommend reaching out to new adopters and new community members/contributors for feedback and improvements that could be made
+* Detail the sub-projects and repos of Kubescape to include a brief descriptor of what they are, if they are core to the project, their status, and who is responsbile for maintaining them, linking appropriately to the overall project governance
 
 ### Adoption Evaluation
 
-The adopter interviews reflect a project in appropriate use for the level which the project applied. Interviews with Adopters commend the project's ease of use, breadth of capability, and friendliness of its maintainers.
+The adopter interviews reflect a project in appropriate use for the level which the project applied. Interviews with Adopters commend the project's ease of use, breadth of capability, and friendliness of its maintainers as well as continually cite the comprehensiveness of its capabilities in supporting organizations looking to secure their clusters. 
 
 ### Final Assessment
 
@@ -160,7 +161,7 @@ The project has 5 maintainers listed on the main repo, 1 appears to be reasonabl
 
 The project's code and doc ownership appear to match the documented governance roles for the project, however several repos under the project are lacking maintainer and contributing files or links to the overarching files for the project.
 
-- [X]] **Document agreement that project will adopt CNCF Code of Conduct.**
+- [X] **Document agreement that project will adopt CNCF Code of Conduct.**
 
 [The project has adopted the CNCF Code of Conduct.](https://github.com/kubescape/kubescape/commit/0eb27389daeff7dc545258cfe0f488c6b8c7a2f4)
 

From 22d9118c94a01f3cbdd77910432c142d18436a3c Mon Sep 17 00:00:00 2001
From: Emily Fox <themoxiefoxatwork@gmail.com>
Date: Thu, 19 Dec 2024 17:07:41 -0500
Subject: [PATCH 5/7] What: Finalize the DD for the project

Why:
 * Project completed several recommendations worth capturing
 * Project completed the outstanding blockers

This change address the need by:
 * finalizing the DD and TOC evaluation

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
---
 .../kubescape-incubation-proposal.md          | 121 ++++++++++--------
 1 file changed, 65 insertions(+), 56 deletions(-)

diff --git a/projects/kubescape/kubescape-incubation-proposal.md b/projects/kubescape/kubescape-incubation-proposal.md
index 99cc63124..a6cc13e8d 100644
--- a/projects/kubescape/kubescape-incubation-proposal.md
+++ b/projects/kubescape/kubescape-incubation-proposal.md
@@ -9,17 +9,30 @@
 Emily Fox (@TheFoxAtWork) conducted the due diligence of Kubescape who applied for Incubation Level. The project has completed the criteria that show its early maturity at Incubation level. While the project meets the expectations of an early-stage Incubating level project, it could greatly benefit from a dedicated focus on its community, documentation, and overall governance.
 
 The following actions were provided to the project that were considered blocking but since resolved:
-* Completion of the security self-assessment
+* Complete the project's Security Self-Assessment
+ * Completed with [PR #1424](https://github.com/cncf/tag-security/pull/1424)
+* Ensure the maintainers file is up to date and reflects the current affiliation of the maintainers
+ * Fully completed with [Commit 5a0b97a](https://github.com/kubescape/project-governance/commit/5a0b97a374b630483e123dc8a37d787f8e556b63)
 * Document the project's release process
+ * Completed with [Commit d938389](https://github.com/kubescape/project-governance/commit/d938389e639db99544e0cc43ecd30d1a5dc47e28)
 
 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:
 * Reorganization/improved structure and interlinking of the documentation, repos, and files
-* Increased detail and robustness of the existing community, contributing, and governance documentation that provides better focus for potential contributors
+  * Captured for work and completed through the [project's pre-incubation board](https://github.com/orgs/kubescape/projects/7/views/1)
+* Improve the contributing guidelines to better explain how contributors can get involved and understand expectations
+ * Completed with [PR #23](https://github.com/kubescape/project-governance/pull/23)
+* Improve the project's Roadmap and cadence of planning to support project activities, like planning for moving levels, such that these boards are referenceable and understandable in the [Roadmap document](https://github.com/kubescape/project-governance/blob/main/ROADMAP.md) such that contributors can see what work is currently underway versus planned later.
+* Ensure the Kubescape site is updated to reflect the current capabilities of the project and provides adopters with clear information on getting started and engaging with the project.
+ * Completed with [PR #79](https://github.com/kubescape/kubescape.io/pull/79/files)
+* Clarify information on how contributors can become maintainers
+ * The [updated governance file](https://github.com/kubescape/project-governance/blob/main/GOVERNANCE.md) for the project provides information on decision making and how maintainers are added to the project.
+* Provide a high-level architecture diagram of each of the components, and how they work together, with links to their repos be provided on the Kubescape website and in the project's primary or project-governance repos to improve discovery. There are numerous architecture diagrams identified during the DD that cover various aspects of the project.
+* The [Security-Insights file has also been updated](https://github.com/kubescape/kubescape/commit/e87bf7b723fdad67037f0db741777cb1b721d50f) to reflect the listing of maintainers
+* Ensure the [project's OpenSSF Scorecard accurately reflects the security posture of the project's repositories](https://scorecard.dev/viewer/?uri=github.com%2Fkubescape%2Fkubescape) and for items that are incomplete, work to address them. Security projects are expected to be the exemplar of good security practices and security hygiene - to include ensuring existing reporting tools correctly reflect their posture
+ * Make additional improvements to its repository security posture by enforcing branch protection, ensuring code-reviews are performed on pull requests and changes are not committed directly to the project without review from a second individual who is not the author of the commit.
+ * It is noted that the best practices badging in the scorecard is inaccurately recorded as there appears to be an additional record being pulled.
 * Provide a contributor ladder and improve the clarity around how contributors become committers and eventually maintainers. This should also include details about how and when maintainers and committers are removed from their roles
 * Engage with TAG Contributor Strategy for a comprehensive Governance Review and discussion on community engagement and expansion to increase company diversity and variety of contributors to the project.
-  * Complete the recommendations detailed in the governance and maintainer section (bullets and as full text) prior to initiating that engagement with TAG Contributor Strategy
-* Provide tutorials that walk through and explain how the project is used and removes implicit assumptions in the Getting Started guide, recommend reaching out to new adopters and new community members/contributors for feedback and improvements that could be made
-* Detail the sub-projects and repos of Kubescape to include a brief descriptor of what they are, if they are core to the project, their status, and who is responsbile for maintaining them, linking appropriately to the overall project governance
 
 ### Adoption Evaluation
 
@@ -29,7 +42,7 @@ The adopter interviews reflect a project in appropriate use for the level which
 
 The TOC has found the project to have satisfied the criteria for Incubation Level.
 
-The project could greatly benefit from several recommendations detailed throughout this Due Diligence, much of which would be addressed by reorganizing the project's website documentation, removing duplicative or out-of-date content, and establishing a dedicated area for governance, contributions, and community items for easier discoverability. It appears the structure for this has been started but not completed.
+The Kubescape project is considered a very early Incubation level project which meets the minimum expectations and criteria, with a few areas of increasing maturity. The project could greatly benefit from more comprehensive documentation and activity captures/messages of what specifically is transpiring, completed, and why. The current operations of the project indicate a closely knit group of maintainers which often operates with implicit knowledge and understanding that would provide substantial value to potential community members not in the group if properly captured in the repo as well-linked documents, as PRs linked and referenced in open issues which demonstrate clear, transparent, and reasoned paths to resolution: problem --> implementation --> closure, and include additional comments and decisions that make assumptions and project knowledge explicit to the uninformed community member.
 
 ## Application Process Principles
 
@@ -61,34 +74,26 @@ The project's communications, planning, and docs align with CNCF stated guidelin
 - [X] **Review and acknowledgement of expectations for [Sandbox](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.**		
 - Met during Project's [initial application on 13-DEC-2022 to CNCF](https://github.com/cncf/toc/issues/978) and reflected through initial application to [Incubation on 13-NOV-2023](https://github.com/cncf/toc/pull/1209) and subsequent [application in the updated format on 4-APR-2024](https://github.com/cncf/toc/issues/1291)
 
-- [ ] **Due Diligence Review.**
+- [X] **Due Diligence Review.**
 
-Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.
+Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies 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.**
 
-The project provides adopters with appropriate documentation for installation and configuration of Kubescape given its maturity level, to include necessary [prerequisites](https://kubescape.io/docs/install-operator/), however it is important to note that the docs may introduce some confusion for adopters looking to get started as the [Getting Started guide](https://kubescape.io/docs/getting-started/) has different instructions than [the client](https://kubescape.io/docs/install-cli/) and [cluster install](https://kubescape.io/docs/install-operator/). 
+The project provides adopters with appropriate documentation for installation and configuration of Kubescape given its maturity level, to include necessary [prerequisites](https://kubescape.io/docs/install-operator/). 
 
-It is recommended the project convert the Getting Started page to be more tutorial-oriented. The getting started page makes several assumptions, such as access to a machine already running a cluster. In order to more efffectively allow potential adopters to try out Kubescape, providing them a tutorial they can run locally that expands on the Overview section, and potentially suggests how the output of Kubescape can be releveraged for achieving security outcomes (i.e. continuous monitoring for compliance with CIS benchmarks) with existing dashboards, tools, and other monitoring and visibility solutions (i.e. linking to the [prometheus operator instructions](https://kubescape.io/docs/operator/prometheus-integration/) or the[ VEX document generation](https://kubescape.io/docs/operator/generating-vex/#what-is-vex)).
+The project recently made changes to their getting started page to provide greater clarity to individuals unfamiliar with the project and the documentation also includes three tutorials to assist individuals in becoming familiar with Kubescape, how to harden a cluster, and using kubescape to enforce security policies on github repositories.
 
 ## Governance and Maintainers
 
 Note: This section was completed leveraging TAG Contributor Strategy's Governance Review template and was conducted on the project's governance document from the following commit: [accc8a38347297ef41d72deef617af5a8995d22b](https://github.com/kubescape/kubescape/commit/accc8a38347297ef41d72deef617af5a8995d22b).
 
 The following items are considered non-blocking for Incubation level but if unresolved will see the community stagnate and the project fail to meet criteria for Graduation.
-* Cross link appropriate files, contributing, maintainers, and governance are all related topics and content and should be appropriately linked to answer community questions and provide a complete understanding of how the project operates and how individuals may grow, progress, and advance the project.
-* The maintainer file needs updated to reflect the correct maintainers and their affiliation
-* The governance should be updated to:
-  * reduce duplication of content, 
-  * ensure all names roles are held to the same expectations of conduct and adherence to governance, 
-  * define how and when decisions are made by the maintainers, 
-  * define a contributor ladder which leverages existing merit of contributions (such as committer role) for maintainership eligibility, 
-  * update security-insights to correctly reflect the maintainers of the project
+* Define a contributor ladder which leverages existing merit of contributions (such as committer role) for maintainership eligibility, 
 * Create a clear focus for community engagement
-  * Ensure the meeting DAY of the week and meeting notes are linked under ##Community on the read me as well as in the contributor guide.
-  * Determine appropriate scope for slack channels and actively promote that usage for those channels (within them and within the project docs/repo)
   * Define the use of “ideas” versus proposals and issues for the project, make better use of the [proposals folder structure](https://github.com/kubescape/kubescape/tree/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/proposals) and define this as part of the contributing file.
 
+
 The [maintainers file](https://github.com/kubescape/kubescape/commit/74bfb57d3a135645f1c9ea9ab0e78d718dbf76f9) is complete with 5 individuals listed but is out of date as one maintainer currently works at Kaleido. The governance describes the expectations of maintainers and the requirements for consideration as maintainer. It also describes the conditions under which a maintainer is removed, this is limited to their activities on project work within a 12 month window. The governance also details a role known as committer and the method for proposing contributors to become committers. There is no contingency to be a committer prior to application as a maintainer.
 
 The governance details how changes are proposed and how conflicts are resolved with some duplication and additional information on roles and responsibilities of maintainers, committers, and community members. Not all expectations are shared equally among the roles, notably the community members only have a call out to abide by the code of conduct and project governance. This should be updated to ensure equal expectations.
@@ -101,7 +106,7 @@ The governance does not detail how decision making by the maintainers occurs nor
 
 The project does maintain a [security.md file](https://github.com/kubescape/kubescape/commit/accc8a38347297ef41d72deef617af5a8995d22b)  that details how security issues are reported and responded. The project also has a [security-insights file](https://github.com/kubescape/kubescape/commit/915d5d993b389c2243e0d6295c805f6a6fb5c358 ) for adopters and contributors to understand the security practices the project employs.
 
-Meetings are recorded and uploaded to Youtube. The meeting notes link was previously buried in a comment on a Kubescape discussion and has since been added to the README for the projec and linked in the Contributor guide. The meeting notes are titled "Kubescape Developer Sync", with the regular meeting attendees typically not more than two individuals who both employed by ARMO. The meeting notes document only goes back to February of 2024 with gaps in frequency.
+Meetings are recorded and uploaded to Youtube. The meeting notes link was previously buried in a comment on a Kubescape discussion and has since been added to the README for the project and linked in the Contributor guide. The meeting notes are titled "Kubescape Developer Sync", with the regular meeting attendees typically not more than two individuals who both employed by ARMO. The meeting notes document only goes back to February of 2024 with gaps in frequency.
 
 The project’s slack channel’s are active, notable the #kubescape primary channel is used by potential adopters and contributors to ask questions of how the project operates or any issues/bugs/challenges experienced. The Kubescape-dev channel does get reminder notifications of the upcoming community meeting but it and the meeting notes document seem more focused on the development of the project which may deter some interested contributors as not being approachable (not devs of the project ergo the meeting may not be appropriate for them to attend). This channel also overlaps in troubleshooting and project functionality discussions which occur in the Kubescape channel generally.
 
@@ -109,15 +114,15 @@ The project’s slack channel’s are active, notable the #kubescape primary cha
 
 - [X] **Clear and discoverable project governance documentation.**
 
-The Governance document is located in the primary Kubescape repo (kubescape/kubescape/GOVERNANCE.md) It does not contain links or references to other documents. For individuals looking to discovery governance of the project, it is fairly straightforward to find. The project’s website does not provide links to or reference’s the project’s governance. The file is clearly named, and does not appear to be linked from the project’s other repositories. While the current governance is simple and clear, improvements are encouraged.
+The project's governance file is linked from the main project repository to a dedicated project-governance repo.  It contains sufficient information on how the project is governed for an early stage incubating project. The project could improve the current governance by linking their official resolutions and Maintainer Meeting notes in the governance so they are more readily discoverable (note they only exist in the [community.md file](https://github.com/kubescape/project-governance/blob/fda8a8122d1a0c0133d5bf216cae6ec092adb290/COMMUNITY.md?plain=1#L27)). It is also recommended the project evaluate existing governance templates (such as the [maintainer council template](https://contribute.cncf.io/maintainers/templates/governance-maintainer/)) to improve how the project is governed and formally develop a [contributor ladder](https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md).
 
 - [ ] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.**
 
 The governance appears largely unchanged since being added.
 
-- [ ] **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.**
 
-The Governance shows some small drift and deviation but is not considered substantial. Improvements are recommended to bring the current governance execution into alignment with the next maturity level beyond Incubation.
+The governance file was updated to reflect quarterly Maintainer Meetings (of which only 1 meeting is recorded in the notes), and the current Maintainer Meeting notes references discoverable activities that show the application of its governance (i.e. [proposals for new maintainers](https://github.com/kubescape/project-governance/issues?q=label%3Aproject-candidacy+is%3Aclosed))
 
 - [ ] **Governance clearly documents [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.**
 
@@ -125,7 +130,7 @@ While the governance is not explicit in calling out neutrality, the overall stru
 
 - [ ] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.**
 
-The governance does detail how the projects makes _some_ decisions on leadership but improvements could be made to ensure clarity of this process and its expectations. Contribution acceptance, requests, and changes to governance and goals should also be added.
+The [governance file](https://github.com/kubescape/project-governance/blob/main/GOVERNANCE.md) partially covers these items, specifically calling out how new maintainers are approved and how changes are proposed to the project and its governance.
 
 - [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).**
 
@@ -141,39 +146,33 @@ Not demonstrable with the current governance.
 
 - [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.**
 
-The project does have several components but their leadership and governance relationship with the core project is not detailed.
+The project does have several components which fall under the overall project governance but the project does not include any add/remove process for these components.
 
 ### Required
 
 - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.**
 
-Kubescape maintains its list of [maintainers for the core repository](https://github.com/kubescape/kubescape/blob/master/MAINTAINERS.md). This file has been changed 6 times since its creation on 06-JAN-2022 as of October 2024.
-
-The project has the following additional respositories with Maintainer files:
-* Helm-charts: https://github.com/kubescape/helm-charts/blob/main/MAINTAINERS.md
-* regolibrary: https://github.com/kubescape/regolibrary/blob/master/MAINTAINERS.md - added 05-NOV-2023, no changes since. No roles defined, clear association with regolibrary
+Kubescape maintains its list of maintainers for the core repository at https://github.com/kubescape/kubescape/blob/master/MAINTAINERS.md. This file has been changed 8 times since its creation on 06-JAN-2022.
 
 - [X] **A number of active maintainers which is appropriate to the size and scope of the project.**
 
-The project has 5 maintainers listed on the main repo, 1 appears to be reasonably active within the past year, with additional 'committers' supporting the project. Overall activity of the repo appears to have slowed in the past year, with fewer new PRs at an increased rate of merging, indicative of increasing maturity and focus on stability of the project.
+The project's maintainer listing was refreshed with review dates. The project's level of activity show a reasonable distribution of 2 active maintainers and 1 active committer (per the project's governance documentation).
 
 - [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.**
 
-The project's code and doc ownership appear to match the documented governance roles for the project, however several repos under the project are lacking maintainer and contributing files or links to the overarching files for the project.
+In November 2024, the project [reviewed their access controls and made changes](https://github.com/kubescape/project-governance/issues/14) to ensure ownership and access is carried by two primary groups. 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.**
 
-[The project has adopted the CNCF Code of Conduct.](https://github.com/kubescape/kubescape/commit/0eb27389daeff7dc545258cfe0f488c6b8c7a2f4)
+[The project has adopted the CNCF Code of Conduct.](https://github.com/kubescape/kubescape/commit/0eb27389daeff7dc545258cfe0f488c6b8c7a2f4) The project also has included an [additional modifier that is NOT in conflict with the CNCF CoC](https://github.com/kubescape/project-governance/blob/main/CODE_OF_CONDUCT.md)
 
 - [X] **CNCF Code of Conduct is cross-linked from other governance documents.**
 
-The Code of Conduct is linked in the [Contributing file](https://github.com/kubescape/kubescape/blob/1cad446fe65f470add1ec68fdc602f1f4c144740/CONTRIBUTING.md?plain=1#L16) and the [Governance file](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/GOVERNANCE.md?plain=1#L7) for the project.
+The project's code of conduct, which links to CNCF's, is cross-linked through several project documents, to include the [governance file](https://github.com/kubescape/project-governance/blob/fda8a8122d1a0c0133d5bf216cae6ec092adb290/GOVERNANCE.md?plain=1#L9), the [README](https://github.com/kubescape/project-governance/blob/fda8a8122d1a0c0133d5bf216cae6ec092adb290/README.md?plain=1#L24) for project-governance, and the [contributing file](https://github.com/kubescape/project-governance/blob/fda8a8122d1a0c0133d5bf216cae6ec092adb290/CONTRIBUTING.md?plain=1#L20)
 
 - [X] **All subprojects, if any, are listed.**
 
-The project's organization contains repos for all sub-projects, but does not have a comprehensive singular listing of each and their purpose or status.
-
-The project should inventory its org and provide a navigation guide of its sub-projects, any maintainers of the sub-projects, the intent and focus of the project, as well as its state/status. With 55 repos, it is not immediately clear to contributors and adopters what is and is not supported. Additionally, the .github repo appears to be an initial attempt to move community and governance material to a dedicated area, highly recommend finalizing this.
+The Kubescape project does not have any known subprojects. The project does [maintain a listing of repositories in its org that are subject to its governance](https://github.com/kubescape/project-governance/blob/main/repositories-under-governance.json). These repositories contain components necessary for interoperability with other cloud native projects, installation tools, actions, and other elements essential to the project.
 
 ## Contributors and Community
 
@@ -183,33 +182,39 @@ Note: this section may be augmented by the completion of a Governance Review fro
 
 - [ ] **Contributor ladder with multiple roles for contributors.**
 
-It is recommended the project establish a contributor ladder that aligns with the roles described in the governance document.
+While the project defines several roles for contributors, additional enhancements would greatly improve understanding and actionability for how an individual may progressively become more involved in the project through the defined roles.
 
 ### Required
 
 - [X] **Clearly defined and discoverable process to submit issues or changes.**
 
-The Contributing file provides information for community members on suggesting changes but could be improved.
+The project's contributing file contains a variety of information on how to get started, however the [Community file](https://github.com/kubescape/project-governance/blob/main/COMMUNITY.md#github-issues) and [Governance file](https://github.com/kubescape/project-governance/blob/main/GOVERNANCE.md#processes) contain specific information on opening issues and proposing changes to the project.
 
 - [X] **Project must have, and document, at least one public communications channel for users and/or contributors.**
 
-The project lists its slack channels on its [README under Community](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/README.md?plain=1#L98). They are also included in the Contributing file.
+The project's [README](https://github.com/kubescape/kubescape?tab=readme-ov-file#community) and [project-governance/community file](https://github.com/kubescape/project-governance/blob/main/COMMUNITY.md) contain links to both the users and developers channel for the project. The project could benefit by linking the [kubescape-dev slack channel on the contributing file](https://github.com/kubescape/project-governance/blob/fda8a8122d1a0c0133d5bf216cae6ec092adb290/CONTRIBUTING.md?plain=1#L68).
 
 - [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 project has listed all their communication channels. 
+The project has listed and documented all communications channels in their relevant files of the repo. See the previous criteria evaluation for more information. There are no known non-public project communication channels.
 
 - [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.**
 
-The project has regular meetings as reflected in the README and an automated notice of the meeting in their slack channel. Community members have recently requested adding the project meeting to the CNCF calendar, and the project is working towards this.
+The project regularly holds public meetings, with [public notes](https://github.com/kubescape/project-governance/blob/main/COMMUNITY.md#community-meetings) and [recordings](https://www.youtube.com/channel/UCgf472-CiLXkfeoPWBmh5hg). Information on meeting schedule is [available in the community file](https://www.youtube.com/channel/UCgf472-CiLXkfeoPWBmh5hg).
 
 - [X] **Documentation of how to contribute, with increasing detail as the project matures.**
 
 The project provides a simple and straightforward contributing guide that is sufficient for a project just entering incubation, however it is recommended this be developed further to be more robust and cover all aspects of contributing to the project, to include triage, PR reviews, etc. The project would benefit from linking the [third party dependency policy](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/environment-dependencies-policy.md) with the Contributing file and the Governance file.
 
+The project's original contributing file had been modified 14 times since it was initially committed. After migrating the content to the project-governance/contributing file, it has been modified an additional 3 times. Through each iteration, the robustness and clarity in detail has been improved.
+
 - [X] **Demonstrate contributor activity and recruitment.**
 
-The project's slack channels are active with community members asking questions and the project's regular meetings are leveraged to serve as encouragement for more contributions. The project would greatly benefit from more active outreach to community members to take up open issues on the repo.
+In the past year, the project's contributor activity has decreased by approximately 31% (per LFX Insights query dtd 19 DEC 2024). Further analysis into the project shows fewer new contributors since June 2024, which show drift indicative of slowed activity and recruitment - likely the result of the project's current focus on stability, performance, and scaling improvements as these activities require more indepth understanding of the project's current capabilities. Looking into 8knot, the Kubescape project  receives the vast majority of contributions through repeat contributors, with first time contributors and contributor activity increasing annually in October before steadily decreasing again towards July on an annual basis.
+
+
+It is worth noting that the project calls out new contributors in addition to all contributors that contributed to a given release, with the [3.0.19 release (12 NOV 2024)](https://github.com/kubescape/kubescape/releases/tag/v3.0.19) being the most recent with a new contributor to the project.
+
 
 ## Engineering Principles
 
@@ -221,29 +226,31 @@ The project does not currently have a change process for its Roadmap documented
 
 - [ ] **History of regular, quality releases.**
 
-Since 2022, the project has been increasing the rigor of their release process, providing better detail post-release and no adopters have reported any issues. The current release cadence does not appear to be set yet, but is approaching some normalcy.
+Since 2022, the project has been increasing the rigor of their release process, providing better detail post-release and no adopters have reported any issues. The current release cadence does not appear to be fixed yet, with documentation citing 6-8 weeks between releases and the release history showing more frequent releases than this.
 
 ### 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.**
 
-The project's goals are detailed in their README and in the project's documentation and provides its focus within the cloud native landscape.
+The project's goals and objectives are documented through it's website: _... offers hardening, posture management, and runtime security to ensure robust protection for Kubernetes environments. The project's website also describes additional open source projects in use by Kubescape and how they are used within the project to for specific use cases (i.e. image scanning with Grype, OPA for security control posture verification, etc.).
 
 - [X] **Document what the project does, and why it does it - including viable cloud native use cases.**
 
-The project's README and docs describe what the project does and why. It also includes information on how the project is to be used in cloud native environments for achieving security outcomes like runtime threat detection and compliance.
+The project's website provides adopters and contributors with information about aspects of the project, what they do, and why. An overview for each of project's components is located on each readme and provides information on how it is used to achieve a targeted cloud native security outcome (image scanning, triggering actions from events, etc.)
 
 - [X] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.**
 
-The project maintains a [ROADMAP](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/roadmap.md) but is difficult to find. It is recommended the project make this file easier to find both in the Project's website docs as well as in the repo.
+The project has [a primary documented public roadmap](https://github.com/kubescape/project-governance/blob/main/ROADMAP.md) and an [older roadmap](https://github.com/kubescape/kubescape/blob/e1db7f3704199441724a85c16786bbf85ec76948/docs/roadmap.md) that needs replaced or provide reference to the current one ([captured in issue #1777](https://github.com/kubescape/kubescape/issues/1777)). The Project has linked the current Roadmap in their README to improve discovery of it, and has created several project boards that show forward looking planning. It is recommended the project establish a practice to review the roadmap at least annually and leverage project boards to track defined goals and objectives to completion.
 
 - [X] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
 
-The project maintains an older [architecture document](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/architecture.md) but should be updated to more appropriately reflects the current capabilities of the project and its sub-projects to match the more recent version of the [architecture located in the project's README](https://github.com/kubescape/kubescape/blob/d82e8daa25d616a8ea2ac75e6e723a29805db727/README.md#architecture).
+The project has two locations of architecture diagrams that demonstrate how components of the Kubescape work together and lower level detail how each work. The first architecture file is in the [kubescape/kubescape repo](https://github.com/kubescape/kubescape/blob/master/docs/architecture.md) and is two years old. It covers the general component architecture, the Kubescape CLI with the OPA engine, and the Operator. The second architecture diagram is a series of diagrams located in the [helm-charts for the kubescape-operator's readme's section on in-cluster components](https://github.com/kubescape/helm-charts/blob/main/charts/kubescape-operator/README.md#in-cluster-components-overview) and is far more expansive on content specific to the operator (the primary method to run Kubescape as a set of microservices inside a kubernetes cluster for cluster compliance and vulnerability management). An overview of the Kubescape architecture which references the operator, storage, and other components in the context of a cluster provides additional information. It is worth noting that [additional diagrams on the CLI and Operator are stored in the security self-assessment for the project](https://github.com/cncf/tag-security/blob/main/community/assessments/projects/kubescape/self-assessment.md#actors).
 
-- [ ] **Document the project's release process.**
+It is recommended the project ensure that a high-level architecture diagram of each of the components, and how they work together, with links to their repos be provided on the Kubescape website and in the project's primary or project-governance repos to improve discovery.
 
-<!-- (TOC Evaluation goes here) --> 
+- [X] **Document the project's release process.**
+
+The project's release process is documented in the [release file](https://github.com/kubescape/project-governance/blob/main/RELEASE.md) of the project-governance repo. It includes the release schedule, steps with links to actions workflows, and items to be performed post-release. While the release process explains a schedule of every 6-8 weeks, the project issues releases more frequently.
 
 ## Security
 
@@ -257,23 +264,25 @@ N/A
 
 - [X] **Clearly defined and discoverable process to report security issues.**
 
-The project maintains a SECURITY.md file which contains the process for reporting security issues.
+The project maintains a [centralized security.md](https://github.com/kubescape/project-governance/blob/main/SECURITY.md) file which includes a straightforward process to report security issues and is linked to by other project repo's security.md files.
 
 - [X] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)**
 
-The project's maintainer accounts are protected with 2FA.
+The project performed a [review of its access controls](https://github.com/kubescape/project-governance/issues/14) as well as evaluated[ enforcement of 2FA on the project's maintainer accounts](https://github.com/kubescape/project-governance/issues/13).
+
+The project should make additional improvements to its repository security posture by enforcing branch protection, ensuring code-reviews are performed on pull requests and changes are not committed directly to the project without review from a second individual who is not the author of the commit.
 
 - [X] **Document assignment of security response roles and how reports are handled.**
 
-The SECURITY.md file includes
+The [central SECURITY.md](https://github.com/kubescape/project-governance/blob/main/SECURITY.md) file explains that maintainers are responsbile for responding to reported vulnerabilities and will test to confirm the existence of the reported vulnerability. They further detail the issuance of Security advisory after confirmed and the expected timelines for disclosure.
 
 - [ ] **Document Security Self-Assessment.**
 
-<!-- (TOC Evaluation goes here) --> 
+The project [completed its security self-assessment](Completed with [PR #1424](https://github.com/cncf/tag-security/pull/1424)) and it is [available on the CNCF TAG Security's repo](https://github.com/cncf/tag-security/blob/main/community/assessments/projects/kubescape/self-assessment.md).
 
 - [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.**
 
-The project maintains the [OpenSSF's best practices badge at the Passing level.](https://www.bestpractices.dev/en/projects/6944)
+The project has [achieved OpenSSF's best practices badge at the passing level](https://www.bestpractices.dev/en/projects/6944), however it appears an additional record is referenced by OpenSSF scorecards that does not accurately reflect its badge.
 
 ## Ecosystem
 

From f25319feb5dd7708b0882371fe3a451eed9c8b6d Mon Sep 17 00:00:00 2001
From: Emily Fox <themoxiefoxatwork@gmail.com>
Date: Thu, 19 Dec 2024 17:13:22 -0500
Subject: [PATCH 6/7] What: correct the governance and maintainers summary with
 resolved items

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
---
 .../kubescape-incubation-proposal.md          | 21 ++++---------------
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/projects/kubescape/kubescape-incubation-proposal.md b/projects/kubescape/kubescape-incubation-proposal.md
index a6cc13e8d..0f33ca617 100644
--- a/projects/kubescape/kubescape-incubation-proposal.md
+++ b/projects/kubescape/kubescape-incubation-proposal.md
@@ -8,6 +8,10 @@
 
 Emily Fox (@TheFoxAtWork) conducted the due diligence of Kubescape who applied for Incubation Level. The project has completed the criteria that show its early maturity at Incubation level. While the project meets the expectations of an early-stage Incubating level project, it could greatly benefit from a dedicated focus on its community, documentation, and overall governance.
 
+The following was notable for the project and worth calling out here:
+* Project engaged the TOC sponsor for DD to ensure they were aware of the expectations for Incubation level projects and could begin taking steps to positions itself for successful graduation in the future.
+* During this DD the TOC sponsor found several areas of the project that while meeting the minimum criteria, did not fully meet the intent of the criteria. The project worked to improved their implementation in several areas and focused to improve its governance, community, and project documentation. The project is in a much better place as a result of leaning-into these changes and if continued, should foster a thriving, vibrant and open community.
+
 The following actions were provided to the project that were considered blocking but since resolved:
 * Complete the project's Security Self-Assessment
  * Completed with [PR #1424](https://github.com/cncf/tag-security/pull/1424)
@@ -93,23 +97,6 @@ The following items are considered non-blocking for Incubation level but if unre
 * Create a clear focus for community engagement
   * Define the use of “ideas” versus proposals and issues for the project, make better use of the [proposals folder structure](https://github.com/kubescape/kubescape/tree/d82e8daa25d616a8ea2ac75e6e723a29805db727/docs/proposals) and define this as part of the contributing file.
 
-
-The [maintainers file](https://github.com/kubescape/kubescape/commit/74bfb57d3a135645f1c9ea9ab0e78d718dbf76f9) is complete with 5 individuals listed but is out of date as one maintainer currently works at Kaleido. The governance describes the expectations of maintainers and the requirements for consideration as maintainer. It also describes the conditions under which a maintainer is removed, this is limited to their activities on project work within a 12 month window. The governance also details a role known as committer and the method for proposing contributors to become committers. There is no contingency to be a committer prior to application as a maintainer.
-
-The governance details how changes are proposed and how conflicts are resolved with some duplication and additional information on roles and responsibilities of maintainers, committers, and community members. Not all expectations are shared equally among the roles, notably the community members only have a call out to abide by the code of conduct and project governance. This should be updated to ensure equal expectations.
-
-The project maintains a brief [CONTRIBUTING file](https://github.com/kubescape/kubescape/commit/33577139034d2d9d248741dd83496c20a86e204b) that details two types of contributions to appropriately guide contributors on how contributions are made, but does not reference the Ideas category of discussions on the repo as a mechanism for proposing changes. The contributions file includes a link to instructions on building and testing locally which directs users to a Wiki on the project repo and additional transitive links to getting-started docs. The contributing file does not provide any information on communications channels or community meetings and should be updated to do so.
-
-The project does not have a contributor ladder independent of or as part of their contributing guide or governance document. It is recommended the project establish one.
-
-The governance does not detail how decision making by the maintainers occurs nor the manner by which submitted proposals warrant decisions by maintainers. The governance should be updated to incorporate these.
-
-The project does maintain a [security.md file](https://github.com/kubescape/kubescape/commit/accc8a38347297ef41d72deef617af5a8995d22b)  that details how security issues are reported and responded. The project also has a [security-insights file](https://github.com/kubescape/kubescape/commit/915d5d993b389c2243e0d6295c805f6a6fb5c358 ) for adopters and contributors to understand the security practices the project employs.
-
-Meetings are recorded and uploaded to Youtube. The meeting notes link was previously buried in a comment on a Kubescape discussion and has since been added to the README for the project and linked in the Contributor guide. The meeting notes are titled "Kubescape Developer Sync", with the regular meeting attendees typically not more than two individuals who both employed by ARMO. The meeting notes document only goes back to February of 2024 with gaps in frequency.
-
-The project’s slack channel’s are active, notable the #kubescape primary channel is used by potential adopters and contributors to ask questions of how the project operates or any issues/bugs/challenges experienced. The Kubescape-dev channel does get reminder notifications of the upcoming community meeting but it and the meeting notes document seem more focused on the development of the project which may deter some interested contributors as not being approachable (not devs of the project ergo the meeting may not be appropriate for them to attend). This channel also overlaps in troubleshooting and project functionality discussions which occur in the Kubescape channel generally.
-
 ### Suggested
 
 - [X] **Clear and discoverable project governance documentation.**

From fdcfe5a6461b71cb37a553f6903fc3f2d776f66b Mon Sep 17 00:00:00 2001
From: Emily Fox <themoxiefoxatwork@gmail.com>
Date: Thu, 19 Dec 2024 17:14:38 -0500
Subject: [PATCH 7/7] What: correct missing checkbox

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
---
 projects/kubescape/kubescape-incubation-proposal.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/projects/kubescape/kubescape-incubation-proposal.md b/projects/kubescape/kubescape-incubation-proposal.md
index 0f33ca617..26f7177b0 100644
--- a/projects/kubescape/kubescape-incubation-proposal.md
+++ b/projects/kubescape/kubescape-incubation-proposal.md
@@ -263,7 +263,7 @@ The project should make additional improvements to its repository security postu
 
 The [central SECURITY.md](https://github.com/kubescape/project-governance/blob/main/SECURITY.md) file explains that maintainers are responsbile for responding to reported vulnerabilities and will test to confirm the existence of the reported vulnerability. They further detail the issuance of Security advisory after confirmed and the expected timelines for disclosure.
 
-- [ ] **Document Security Self-Assessment.**
+- [X] **Document Security Self-Assessment.**
 
 The project [completed its security self-assessment](Completed with [PR #1424](https://github.com/cncf/tag-security/pull/1424)) and it is [available on the CNCF TAG Security's repo](https://github.com/cncf/tag-security/blob/main/community/assessments/projects/kubescape/self-assessment.md).