[Graduation] Kyverno Graduation Application

[realshuting]

Review Project Moving Level Evaluation

• [x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

Kyverno Graduation Application

v1.6 This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

Kyverno has previously applied for Graduation, completed all reviews, including security audits, fuzzing audits, and end-user interviews. Here is the link to the previous application. We withdrew the application due to maintainer organization changes. Since then we have onboarded maintainers from several organizations, and we would like to reopen the Graduation process.

Project Repo(s): https://github.com/kyverno/kyverno Project Site: http://kyverno.io Sub-Projects: Kyverno JSON, Kyverno Authz Server, Kyverno Chainsaw, Policy Reporter, Kyverno Backstage Plugin

Communication:

• Kubernetes Slack

  • #kyverno (end‑user channel): https://slack.k8s.io/#kyverno
  • #kyverno-dev (contributor channel): https://slack.k8s.io/#kyverno-dev
  • #kyverno-chainsaw: https://kubernetes.slack.com/archives/C067LUFL43U

• CNCF Slack

  • #kyverno: https://cloud-native.slack.com/#kyverno

• Mailing list: kyverno group (https://groups.google.com/g/kyverno)

• GitHub discussions: github.com/kyverno/kyverno/discussions

• Weekly community meeting: Wednesdays @7:30 AM PST

• Weekly maintainer meeting: Tuesdays @7:30 AM PST

Project points of contacts: Jim Bugwadia ([email protected]) and Shuting Zhao ([email protected]), maintainer mailing list (cncf‑kyverno‑[email protected])

• [ ] (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Graduation Criteria Summary for $PROJECT

Application Level Assertion

• [x] This project is currently Incubating, accepted on 2022/07/13, and applying to Graduate.

Adoption Assertion

Kyverno is widely deployed across industries for policy enforcement, mutation, generation, and image verification.

The public adopters list includes major telecommunications providers (Vodafone, Deutsche Telekom), financial institutions (Saxo Bank), technology companies (LinkedIn, Spotify), e‑commerce platforms (Wayfair, Amazon EKS Best Practice Guides), government and defense (US DoD Platform One), cloud providers (OVHcloud), manufacturers (VELUX), and many others.

Additional adopters such as Censhare, Coinone, Davidson Consulting, InfraCloud, North IT, Corestream, Tigera, KubriX, X3M Ads, tails.com, ONZACK AG, SingleStore, and Kubermatic contribute to a deep ecosystem. Several organizations have shared detailed success stories, and many more use Kyverno internally but cannot publicly disclose their names. This demonstrates broad adoption in production by at least three independent organizations, satisfying the adoption requirement.

Application Process Principles

Suggested

N/A

Required

• [x] Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
  • Kyverno maintainers have presented to the CNCF TAG Security & Compliance and TAG App Delivery. Meeting Recording can be discovered at here (Kyverno presentation starts at 34 mins). A joint security assessment was opened in May 2025 to coordinate a comprehensive TAG Security review.

• [x] All project metadata and resources are vendor-neutral.

  • Kyverno’s governance document explicitly states that the project follows the CNCF vendor‑neutrality guidelines. Maintainers are from multiple organizations (Nirmata, Chainguard, Kuaishou Technology, VELUX), and sub‑projects have their own diverse maintainer groups. Governance, code ownership, and decision‑making processes are documented and implemented in public GitHub repositories, ensuring neutrality.

  • In addition, the Kyverno project is in the process of establishing a Kyverno Steering and Oversight Committee that will be responsible for roadmap and governance: https://github.com/kyverno/community/pull/72.

• [x] Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
  • Kyverno acknowledged these expectations during its application to the CNCF in 2020 and subsequent move to incubating in 2022/02/09 through PR #784. The team actively participates in CNCF programs and maintains regular communication with the TOC.

• [ ] 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.

  • Kyverno provides comprehensive user documentation (installation guides, configuration, API reference), policy samples, and tutorials on http://kyverno.io.
  • The Releases page explains versioning, branch strategies, and release cadence, while the Roadmap file links to release tracker boards and design proposals.
  • Sample policies are hosted in a dedicated repository and rendered on the website.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• [x] Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

  • Kyverno’s governance has been refined multiple times since incubation to incorporate feedback from contributors and adopters. For example, the contributor ladder and progression requirements have been updated to reflect community growth. Kyverno will continue refining governance as the project matures.
  • The project has also requested a governance review. Addition of Contributor Ladder. Addition of Steering & Oversight Committee.

Required

• [x] Clear and discoverable project governance documentation.
  • The governance document is publicly available and outlines principles, roles, contribution ladder, meeting processes, conflict resolution, and how changes are made. The community page links directly to governance.

• [x] Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

  • The GOVERNANCE.md includes current meeting schedules (community and maintainer meetings) and aligns with how maintainers operate. Roles and responsibilities for contributors, reviewers, and maintainers are clearly defined.

• [x] Governance clearly documents vendor-neutrality of project direction.

  • The governance explicitly states that Kyverno follows CNCF vendor neutrality guidelines.
  • The project is in the process of establishing a vendor neutral Steering and Oversight Committee that will be responsible for roadmap and governance: https://github.com/kyverno/community/pull/72.

• [x] Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

  • The governance defines a contributor ladder with promotion criteria and describes how maintainers are nominated and approved. It also explains how governance changes are proposed and ratified.

• [x] Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

  • Sub‑project maintainers are listed in the MAINTAINERS.md file. Each sub‑project (e.g., Chainsaw, Policy Reporter,) has its own maintainers and onboarding/offboarding processes. Emeritus maintainers are acknowledged.

• [x] Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

  • The GOVERNANCE.md defines progression from contributor to maintainer and details off‑boarding guidance. Maintainer lifecycle is demonstrated through the emeritus list and new maintainer additions.

• [x] Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

  • The MAINTAINERS.md file shows active maintainers from multiple organizations; emeritus maintainers have been moved off the list. New maintainers (e.g., Shubham Gupta, Liang Deng , Ammar Yasser, Jonas Beck, Jacob Lorenzen, Luc Chmielowski) have been added to sub‑projects.

• [x] Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

  • The MAINTAINERS.md file lists each maintainer, their GitHub ID, and affiliation. Sub‑project maintainers are similarly documented.

• [x] A number of active maintainers which is appropriate to the size and scope of the project.

  • Kyverno has active maintainers across four organizations (Nirmata, Chainguard, Kuaishou Technology, VELUX). Sub‑projects add additional maintainers, ensuring sustainability. Please check the MAINTAINERS.md file for up-to-date information.

• [x] Project maintainers from at least 2 organizations that demonstrates survivability.

  • Maintainers from Nirmata, Chainguard, Kuaishou Technology, and VELUX satisfy this requirement.

• [x] Code and Doc ownership in Github and elsewhere matches documented governance roles.

  • GitHub teams manage repositories corresponding to sub‑projects (e.g., kyverno‑maintainers, kyverno‑json‑maintainers). Each has clear maintainers listed in the MAINTAINERS.md file. Documented roles correspond to actual code and documentation ownership.
  • Each repository has its own CODEOWNERS file. For example, here is the CODEOWNERS file in kyverno/kyverno repository.

• [x] Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.

  • Kyverno’s governance lists the CNCF Code of Conduct and states that the project adheres to it. The CoC is cross‑linked from multiple documents and from the community site.

• [x] CNCF Code of Conduct is cross-linked from other governance documents.

  • The CoC link appears in both the governance document and the community site.
  • CNCF Code of Conduct linked here.

• [x] All subprojects, if any, are listed.

  • Subprojects are listed in the Kyverno documentation as well as on the main GitHub organization page.
  • The MAINTAINERS.md file lists maintainers for Chainsaw, Policy Reporter, Website, Sample Policies, Envoy plugin, Backstage Policy Reporter, etc., thereby enumerating all sub‑projects.

• [x] If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

  • Each sub‑project’s maintainers are identified here. New maintainers are added via PRs after nomination and consensus; emeritus maintainers are removed accordingly.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• [x] Contributor ladder with multiple roles for contributors.

  • Kyverno’s governance defines a contributor ladder, progressing from New Contributor to Contributor, Reviewer, and Maintainer with clear requirements and privileges.

Required

• [x] Clearly defined and discoverable process to submit issues or changes.

  • The CONTRIBUTING.md describes how to open issues and pull requests.

• [x] Project must have, and document, at least one public communications channel for users and/or contributors.

  • Kyverno maintains public Slack channels and a mailing list. Meetings are recorded and notes are published via shared agendas. We have recently added our meetings to the new CNCF calendar with the below agenda documents included: Kyverno Maintainers Meeting, Kyverno Community Meetings.

• [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 community page details Slack channels, mailing lists, GitHub Discussions, weekly meetings, and the adopters program. Sub‑projects use the same channels, and specific projects (e.g., Chainsaw) have dedicated Slack threads.

• [x] Up-to-date public meeting schedulers and/or integration with CNCF calendar.

  • The community page lists meeting times and links to agendas stored on Google Docs.

• [x] Documentation of how to contribute, with increasing detail as the project matures.

  • Contribution guidelines, developer documentation, and good‑first issues are linked from the community site.

• [x] Demonstrate contributor activity and recruitment.

  • Kyverno continues to attract new contributors. The Kyverno 1.14 release merged 744 changes from 60+ contributors, including over 40 first‑time contributors. The Kyverno 1.15 release merged over 850 changes from 70+ contributors, including many first‑timers. These metrics show a growing and healthy contributor community.

Engineering Principles

• [x] Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review.

  • Kyverno’s documentation explains that it is a Kubernetes‑native policy engine for validation, mutation, generation, and image verification, designed to provide declarative policy management using familiar YAML syntax, differentiating it from general‑purpose policy engines. The project addresses policy management and governance gaps in Kubernetes by offering simpler syntax and built-in controllers.

• [x] Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.

  • The documentation and numerous blog posts explain Kyverno’s purpose and use cases (admission control, mutating resources, generating resources, and verifying supply chain). Use cases range from multi‑tenant cluster isolation to enforcing pod security standards, injecting sidecars, and automating secret management. Use cases can be discovered at Kyverno Due Diligence completed at July 2022.

• [x] Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

  • The ROADMAP.md file points to a Release Tracker board and Kyverno Design Proposals and GitHub milestones. This enables the community to track upcoming features and plan contributions.

• [x] Roadmap change process is documented.

  • Roadmap changes are discussed in maintainer meetings and tracked via GitHub issues and milestones. Major features follow the Kyverno Design Proposal process.

• [x] Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

  • Kyverno’s documentation describes the architecture (policy controller, admission webhooks, background scan controller) and provides diagrams explaining how it interacts with Kubernetes. The new policy types (ValidatingPolicy, ImageValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy) are explained in release blogs and documentation.

• [x] Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • [x] Release expectations (scheduled or based on feature implementation)
    • The releases page explains that Kyverno follows Semantic Versioning and details the cadence: major releases roughly once per year; minor releases approximately every three months; patch releases for critical bug fixes or about once a month.
  • [x] Tagging as stable, unstable, and security related releases
  • [x] Information on branch and tag strategies
    • branching strategies is documented here.
  • [x] Branch and platform support and length of support
    • Kyverno follows the same support policy as the Kubernetes project N-2 policy in which the current release and the previous two minor versions are maintained.
  • [x] Artifacts included in the release.
    • Release notes and assets are available on GitHub at release pages.
  • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

• [x] History of regular, quality releases.

  • Kyverno consistently delivers releases. Recent minor releases include v1.15.0 (August 30 2025) and v1.16.0 (November 10 2025), each introducing major new features and performance improvements. Patch releases are issued for security and bug fixes according to policy.

Security

The project maintains a security guidance and recommendations at https://kyverno.io/docs/security/ including:

• Security Disclosure Process
• Security Guidelines & Best Practices
• Admission Controller Threat Model and Mitigations

In addition, the project has requested a joint assessment with TAG Security:

CNCF TAG-Security and Compliance: Kyverno Security Self Assessment (October 2025)

Suggested

• [ ] Achieving OpenSSF Best Practices silver or gold badge.

Currently Kyverno has an OpenSSF Best Practices Passing badge. The maintainers plan to work toward the silver badge and will update the application when completed.

Required

• [x] Clearly defined and discoverable process to report security issues.

  • The SECURITY.md file and security page describe how to report vulnerabilities via email to [email protected], what information to include, and expected response timelines.

• [x] Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

  • All repositories enforce branch protections and require two‑factor authentication. GitHub pull requests require approval from reviewers and maintainers before merging.

• [x] Document assignment of security response roles and how reports are handled.

  • The SECURITY.md file explains that the Kyverno security team will respond within 3–5 days and plan a fix within 7–28 days based on severity. Maintainers manage security releases and coordinate disclosure.

• [x] Document Security Self-Assessment.

  • Kyverno completed a security self-assessment.
  • A joint security assessment is currently in progress: CNCF TAG-Security and Compliance: Kyverno Security Self Assessment (October 2025).

• [x] Third Party Security Review.

  • [x] Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

  • A comprehensive third‑party security audit was conducted by Ada Logics in collaboration with the Open Source Technology Improvement Fund and funded by the CNCF. The audit defined a threat model, manually reviewed code, assessed fuzzing coverage, and evaluated supply‑chain security. Ten issues were found (including six CVEs) and promptly fixed in releases v1.10.6 and v1.11.1. The audit concluded that Kyverno complies with SLSA level 3 and found no policy bypasses. A joint security assessment with TAG Security is ongoing.

  • Kyverno Third-Party Security Audit.

  • Kyverno Fuzzing Security Audit.

• [x] Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

  • Kyverno has achieved the OpenSSF Best Practices Passing badge.

Ecosystem

Suggested

N/A

Required

• [x] Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

  • The ADOPTERS.md file lists dozens of organizations using Kyverno, with descriptions of their use cases (production, dev/trial). Examples include Vodafone enforcing policies and automation, Deutsche Telekom enforcing security rules, and VELUX using Kyverno for security and best practices. Additional adopters from finance, cloud providers, media, telecom, and government demonstrate broad production usage.

• [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.

• Adoption examples above include at least three independent production users across diverse industries, satisfying this criterion.

• [ ] 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.

Kyverno maintains comprehensive documentation demonstrating integrations and compatibility with both CNCF and non-CNCF projects and platforms:

• Integrates with Kubernetes as an admission controller for policy enforcement and validation
• Integrates with Istio, Envoy Gateway, and agentgateway using Envoy External Authorization

Platform specific notes are listed on the installation instructions page.

Adoption

4/6 interviews have been completed during our last attempt for graduation. The Kyverno team has previously submitted multiple adopter interview contact details and would be happy to share additional adopter contact information if needed.

Adopter 1 - Bloomberg

Feb ’22

Adopter 2 - LinkedIn

May ’23

Adopter 3 - Saxo Bank

Jun ’22

Adopter 4 - DE-CIX

Apr ’23

Adopter 5 - FinTech company

Jul ’24

Adopter 6 - Global e-commerce marketplace

Sep ’22

[angellk]

Thank you @realshuting for re-submitting the Graduation issue with the current template.

ref: #1217

[angellk]

Quiet period for the TOC has ended 🙂

I have:

• Set up a new slack channel for this graduation DD
• Scheduled 2/5 adopter interviews for Friday, December 5, 2025
• Started the Due Diligence

[angellk]

@GenPage to open a Tech Review issue