[Incubation] Higress Incubation Application

Start by reading the application criteria and the linked community/GOVERNANCE.md, MAINTAINERS.md, SECURITY.md, and review documents. Check the pending due-diligence, public-comment, CNCF review, and TOC decision steps, including cncf/toc#2266 and #2267. Done means the required review concerns are addressed and the TOC reaches a decision.

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.

Higress Incubation Application

v1.6

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

Project Repo(s):

• higress-group/higress, primary repository

Supporting governance and community documentation is maintained in higress-group/community. Other repositories within the project scope are listed under Sub-Projects below.

Project Site: https://higress.ai/en/

Sub-Projects: higress-console, higress-standalone, plugin-server, and wasm-go. Their scope and status are documented in GOVERNANCE.md.

Related Projects: None declared for this application. Higress integrates with and builds on CNCF projects including Kubernetes, Envoy, Istio, Prometheus, and OpenTelemetry, but does not claim those projects as Higress subprojects.

Communication: The official public and private-purpose channels are listed in COMMUNITY.md. Public channels include GitHub Issues, Pull Requests, Discussions, Discord, and the monthly Higress Community Meeting.

Project points of contact:

• Tianyi Zhang, @johnlanni, Alibaba Cloud

• Yuanxiao Zhao, @EndlessSeeker, [email protected]

• Yiquan Dong, @CH3CHO, [email protected]

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

  Not applicable at the time of application.

Incubation Criteria Summary for Higress

Application Level Assertion

• This project is currently Sandbox, accepted on 2026-04-13, and applying to Incubation.

  The Sandbox application was accepted in 2026, and project onboarding was completed on June 17, 2026.

• This project is applying to join the CNCF at the Incubation level.

  Not applicable because Higress is already a CNCF Sandbox project.

Adoption Assertion

Adopter information has been collected and submitted through the designated channel.

Application Process Principles

Suggested

• Engage with domain-specific TAG(s) to present the technical architecture of the project.

  This has not yet been completed. We are available to present the architecture if requested during review.

Required

• Complete a General Technical Review (GTR).

  The project assessment answers the Day 0 and Day 1 questions: target users and use cases, configuration interfaces, control/data-plane design, installation validation, security boundaries, enablement, upgrades, and rollback. It explicitly identifies gaps in automated upgrade/downgrade testing, compatibility-review cadence, supply-chain evidence, and control-plane privilege minimization. These are findings in the submitted assessment, not an external passing grade. The complete answers and supporting evidence are published in general-technical-review.md. The self-assessment document is also submitted in PR #2324 for direct review; CNCF verification remains pending. The external Project Reviews request is open in cncf/toc#2266 and is awaiting triage and reviewer assignment. The CNCF DD triage guide states that projects should not be blocked while CNCF associates review and upload vetted snapshots.

• Complete a Governance Review.

  The project assessment is complete and published in governance-review.md. The self-assessment document is also submitted in PR #2325 for direct review; CNCF verification remains pending. The external Project Reviews request is open in cncf/toc#2267 and is awaiting triage and reviewer assignment. The CNCF DD triage guide states that projects should not be blocked while CNCF associates review and upload vetted snapshots.

• All project metadata and resources are vendor-neutral.

  Higress can be deployed on any conformant Kubernetes cluster in public cloud, private cloud, on-premises, or local environments. It does not require an Alibaba Cloud account, API, or commercial service. Project governance gives no company a reserved seat, veto, or preferred decision weight. Alibaba Cloud's commercial Higress offering is a downstream distribution and has no special authority over the open source project. The project's vendor-neutral governance is documented in GOVERNANCE.md.

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

  Higress completed Sandbox onboarding on June 17, 2026, and acknowledges the current Incubation criteria and ongoing CNCF project obligations.

• Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.

This application requests the review. DD, public comment, resolution of concerns, and TOC decision remain to be completed.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

  Installation, operations, end-user documentation, examples, and API references are available from the Higress documentation site and the primary repository.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject if completed as a suggested item prior to application.

Suggested

• Complete a Governance Review with the Project Reviews subproject

  cncf/toc#2267 is open and awaiting triage and reviewer assignment.

• 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 documented history has concrete stages: higress#3754 established the first public project-wide maintainer roster on April 24, 2026; higress#4177 documented the lifecycle process and 2026 activity/affiliation review on July 22, 2026. That review retained all seven maintainers as active. The lifecycle history records those outcomes, and community#10 records the subsequent canonical documentation update, including the 30-day affiliation-update requirement. Policy evolution is maintained through public PRs in the community repository; these records demonstrate documentation and roster-review evolution, not an unrecorded leadership election or personnel replacement.

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

  All four software subprojects are active: higress-console provides the web management console; higress-standalone provides standalone/local packaging; plugin-server distributes plugins; wasm-go provides the Go Wasm SDK. Unless a subproject documents an additional local rule, the same project-wide governance and seven-maintainer roster apply. Contributors use each repository's public issues and PRs, with path reviews delegated through its CODEOWNERS. Adding, removing, transferring, or archiving a subproject requires a public proposal naming the repository, purpose, maintainers or code owners, contribution path, communication channels, and lifecycle status. Removed or archived entries remain listed with their final status and successor, if any. These rules and the repository inventory are in Project Scope and Subprojects; the full document is GOVERNANCE.md.

Required

• Clear and discoverable project governance documentation.

  The governance document defines Contributor, Code owner, and Maintainer roles; public decision making; vendor neutrality; subproject scope; and how function-based teams are created. It is linked from the community repository README.

  See GOVERNANCE.md.

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

  The governance model uses public lazy consensus and public issue or pull request records. Current meeting schedules and public decision-record requirements are documented in MEETINGS.md; leadership and lifecycle review evidence are in MAINTAINERS.md, and decision rules are in GOVERNANCE.md.

• Governance clearly documents vendor-neutrality of project direction.

  Roles belong to individuals, not employers. No company receives a reserved seat, veto, or extra voting weight. Maintainers must disclose material conflicts and abstain from the affected decision.

  See the Vendor Neutrality section of GOVERNANCE.md.

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

  Proposals are discussed in public issues or pull requests, using lazy consensus. If consensus cannot be reached, a simple majority of votes cast by non-conflicted maintainers decides. Significant decisions must record their rationale and outcome. If all maintainers are conflicted, the project seeks TOC guidance.

  See the Decision Making section of GOVERNANCE.md.

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

  A public governance PR must define each team's purpose, authority, membership, onboarding, conflict handling, removal, and retirement. The Security Response Team uses the maintainer roster; changes to that roster require corresponding private-access updates.

  Function-based teams are covered in GOVERNANCE.md. Security Response Team membership and responsibilities are documented in SECURITY.md.

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

  Existing maintainers may nominate sustained contributors through a public PR recording contribution history, responsibility, contact, and affiliation. The roster is reviewed at least annually. Maintainers inactive for 12 months receive at least 30 days to respond before a status change is proposed. Voluntary departure, removal, emeritus recognition, and return are documented; returning members follow the nomination process.

  Roles, nomination, annual review, affiliation updates, offboarding, removal, and emeritus status are documented in MAINTAINERS.md.

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

  The maintainer roster was formally established through higress#3754, and the lifecycle process and 2026 activity and affiliation review were documented through higress#4177. community#10, merged on September 3, 2026, records the review and its outcome in the canonical maintainer documentation. The review checked public issue/PR activity and roster information for the existing maintainers, and retained all seven as active. The Activity and roster review section documents the review criteria and supporting evidence; active status includes development, review, releases, triage, support, or governance participation within the preceding 12 months and willingness to continue. No project event required an addition, replacement, or emeritus transition, so the project did not manufacture an artificial personnel change solely for this application.

• Maintainer affiliations are current and a policy is in place requiring updates within 30 days of employment changes. (If affiliations have lapsed, document how the project identified and corrected them.)

  Current affiliations are maintained in MAINTAINERS.md. community#10, merged on September 3, 2026, added the explicit requirement that maintainers update their affiliation within 30 days of an employment or organizational affiliation change.

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

  The project maintains a canonical roster covering maintainer responsibilities, affiliations, and contact information. Individual details are not reproduced in this application; reviewers should use the established review channels for person-specific information. Maintainers hold project-wide responsibility for governance, technical direction, releases, and community stewardship, while day-to-day path review is delegated through CODEOWNERS.

  See MAINTAINERS.md and CODEOWNERS.

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

  Higress documents seven active project maintainers sharing project-wide direction, release, governance, and community responsibilities, with path-specific review delegated to code owners. The maintainer roster and annual review evidence identify the individuals and their activity; CODEOWNERS identifies delegated review coverage.

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

  Project-wide maintainers are documented in MAINTAINERS.md, while day-to-day path ownership is delegated through repository CODEOWNERS, including the primary repository rules.

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

  Higress follows the CNCF Code of Conduct. Its adopted Contributor Covenant text requires respectful, harassment-free participation and applies both in project spaces and when representing the project publicly. The CNCF policy prevails if the texts conflict. Incidents can be reported confidentially to [email protected]; the documented response expectation is three business days. See the adopted policy and reporting procedure in CODE_OF_CONDUCT.md.

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

  It is linked at the beginning of GOVERNANCE.md.

• All subprojects, if any, are listed.

  The active software subprojects are higress-console (management UI), higress-standalone (local deployment packaging), plugin-server (plugin distribution), and wasm-go (plugin SDK). The community repository is project infrastructure. Istio and Envoy forks are pinned build dependencies, not separately governed subprojects. Adding or retiring a subproject requires a public proposal documenting its purpose, ownership, contribution path, and status.

  See Project Scope and Subprojects in GOVERNANCE.md.

Contributors and Community

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

Required

• Contributor ladder with multiple roles for contributors.

  Anyone can contribute code, documentation, tests, issues, or community help. Code owners are appointed through public CODEOWNERS changes to review specific paths. Maintainers hold broader project responsibility and are nominated based on sustained contribution. Code ownership alone does not grant project-wide decision authority.

  Higress documents Contributor, Code owner, and Maintainer roles in GOVERNANCE.md and CONTRIBUTING_EN.md.

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

  Contributors first search existing issues, then use the issue templates to report bugs, request features, or propose designs, removing credentials and other sensitive information. Code and documentation changes are submitted as pull requests against main using the PR template, with reviewable commits and relevant tests. Vulnerabilities are reported privately under SECURITY.md. The guide also covers fork/clone setup, branch conventions, commit messages, and test contributions. See CONTRIBUTING_EN.md. Materially agent-assisted contributions additionally follow the documented approval, disclosure, and verification policy, including its verified-maintainer exception.

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

  Public GitHub channels, Discord, community groups, and meetings are listed in COMMUNITY.md.

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

  GitHub Issues, PRs, and Discussions hold public work and decisions; Discord and Chinese-language groups support user discussion; monthly meetings provide project updates and planning. Subprojects use their own public issue and PR trackers. Non-public channels are limited to vulnerability reports, confidential Code of Conduct reports, and private TOC escalation for conflicts. Informal or employer-internal conversations are not official decision channels; non-sensitive outcomes must be recorded publicly. The complete inventory, including each channel's purpose and joining/reporting links, is in COMMUNITY.md.

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

  The monthly schedule and joining information are documented in MEETINGS.md, with a recurring DingTalk calendar entry. Meetings are held on the third Thursday of each month, 20:00 to 21:00 Asia/Shanghai (UTC+8). Since September 2026, DingTalk has replaced LFX Zoom. Anyone may propose topics through the public agenda issue or comment asynchronously; significant decisions are recorded publicly. Meeting notes are published in the meetings directory.

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

  Contributors first search existing issues, then use the issue templates to report bugs, request features, or propose designs, removing credentials and other sensitive information. Code and documentation changes are submitted as pull requests against main using the PR template, with reviewable commits and relevant tests. Vulnerabilities are reported privately under SECURITY.md. The guide also covers fork/clone setup, branch conventions, commit messages, and test contributions. See CONTRIBUTING_EN.md. Materially agent-assisted contributions additionally follow the documented approval, disclosure, and verification policy, including its verified-maintainer exception.

• Demonstrate contributor activity and recruitment.

  Public evidence includes GitHub contributors, recent activity, CNCF DevStats, and open help wanted and good first issue issues.

Engineering Principles

Suggested

• Roadmap change process is documented.

  Anyone may propose a roadmap item through a public issue or discussion describing the user problem, expected result, scope, dependencies, and compatibility or security impact. Maintainers decide through public lazy consensus and update the version-controlled roadmap. It is reviewed during major/minor release planning and material direction changes; target dates are not delivery guarantees.

  See ROADMAP.md.

• History of regular, quality releases.

  Recent non-prerelease publications show a continuing release history: v2.2.1 on April 9, v2.2.2 on May 26, v2.2.3 on June 25, v2.2.4 on August 13, and v2.2.5 on October 4, 2026 (GitHub publication dates in UTC). Each release page provides its changes and published assets. Release history alone is not proof of runtime quality: the required review, validation, artifact checks, and smoke tests are defined in RELEASE.md. See GitHub Releases and the versioned release notes for the full record.

Required

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

  Higress combines Kubernetes Ingress, API traffic governance, and AI/LLM gateway capabilities on an Envoy/Istio foundation. Declarative configuration is delivered through xDS, while Wasm plugins and native Go filters extend request processing. This lets platform teams govern application APIs and model access through a shared gateway. The project purpose, differentiation, and use cases are documented in the project README and General Technical Review.

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

  Platform engineers use Higress to route north-south traffic, publish services through Ingress or Gateway API, and apply authentication, rate limits, and observability. AI teams use it for model-provider proxying and MCP service exposure. Operators configure resources through Kubernetes YAML, Helm, hgctl, or the optional Console; plugin developers extend gateway policies. Higress is not an identity provider, model provider, or transparent east-west service mesh. See the project README and the scope, personas, and deployment sections of the General Technical Review.

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

  The public roadmap records intended direction and target versions on the project website, with its source maintained in version control. Maintainers review it during major/minor release planning and material direction changes; accepted changes link to public discussion, and completed work is recorded in release notes. Dates are planning targets rather than delivery guarantees. See the roadmap policy and published roadmap.

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

  Operators configure routes and policies through Kubernetes resources and supported service registries. The controller translates that configuration into xDS updates for the Envoy-based gateway. Envoy routes requests and applies configured filters; Wasm plugins and native Go filters extend the request path. This separates configuration management from traffic processing.

  See docs/architecture.md and the General Technical Review.

• Document the project's release process.

  A maintainer release manager records scope, version, timing, validation, and blockers in a public tracking issue. At least one other unconflicted maintainer approves the release PR. Version metadata and dependencies must agree, and applicable checks must pass before tagging the reviewed commit. Managed plugin releases also require exact-commit readiness checks for the plugin snapshot, promoted artifacts, plugin-server, and Console dependency. Publishing workflows produce images, charts, CLI archives, CRDs, and release notes. The release manager verifies the published artifacts and smoke-tests installation and gateway traffic before announcing readiness. Published tags are not moved: failed releases are corrected with a new candidate or patch. See RELEASE.md for authorization, validation, security releases, rollback, and correction procedures.

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance if completed as a suggested item prior to application.

Suggested

• Complete a joint security assessment with TAG Security and Compliance

  This has not been completed. The Security Self-Assessment has been reviewed and approved in cncf/toc#2268, and Higress is available for a joint assessment if requested.

Required

• Clearly defined and discoverable process to report security issues.

  GitHub Private Security Advisories are the required and sufficient private reporting channel. Alibaba ASRC is optional. Reports should include reproduction steps and impact, and must not disclose vulnerability details in public issues. The policy targets acknowledgement within three business days and triage within 14 days, followed by coordinated fixing and disclosure.

  See SECURITY.md.

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

  The protected main branch requires one approval, a Code Owner review, and successful license/cla, build, lint, and Analyze (go) checks against the current base branch. Force pushes and branch deletion are disabled. These settings were checked through the authenticated main-branch protection API on October 12, 2026; this endpoint may require repository permission, so it is not a universally accessible public evidence page. The publicly readable build/test workflow, CodeQL workflow, and CODEOWNERS show the implementation and review ownership, but do not by themselves prove enforcement of repository settings. This answer does not assert organization-wide 2FA or signed-commit enforcement.

• Document assignment of security response roles and how reports are handled. (This is distinct from the security reporting process above - document who is responsible for triaging and responding to reports, not just where to send them. For reference, see the Kubernetes Security Response Committee as a model for named membership, documented responsibilities, and a clear escalation path.)

  The Security Response Team comprises the current project maintainers, with membership controlled by the canonical maintainer roster; individual details are not reproduced here. For each case, the triage coordinator acknowledges the report, assigns severity, maintains reporter contact, and tracks deadlines; the fix lead reproduces and remediates the defect; the reviewer/release lead independently checks the fix and verifies supported-version artifacts; the disclosure lead prepares the advisory, any CVE request, credits, and coordinated communication. Assignments and decisions are recorded in the private advisory. Confirmed vulnerabilities require at least two unconflicted members. Conflicted members recuse; missed timelines are escalated to the team, and insufficient unconflicted membership is escalated privately to the TOC.

  Named Security Response Team membership, triage, fix, review, release, disclosure, conflict, and escalation responsibilities are documented in SECURITY.md.

• Document Security Self-Assessment.

  The project copy is published in security-self-assessment.md. The CNCF copy was merged on September 25, 2026 in cncf/toc#2268 and is available as self-assessment.md. Its threat model covers unauthorized configuration changes (HG-TM-01), secret exposure (HG-TM-02), malicious plugins (HG-TM-03), xDS/SDS compromise (HG-TM-04), resource exhaustion (HG-TM-05), cross-tenant route attachment (HG-TM-06), and data disclosure to integrations (HG-TM-07). For example, an installed Wasm plugin can still observe or modify traffic exposed by the filter API: matchRules scope intended execution but are not a security boundary against malicious plugin code. Kubernetes enforces operator-defined RBAC and resource limits; Higress/Envoy enforce configured routes and request policy. The assessment records incomplete project-wide SBOM/signature/provenance coverage, broad controller permissions, and missing dedicated fuzzing/DAST and upgrade/downgrade testing as gaps in that assessment, not as independently verified current guarantees. See the Threat Model and Known Gaps for mitigations and residual risks. The operator guide explains permissions, resource limits, configuration review, and trusted plugin/image selection. A merged self-assessment is not an independent audit or completed joint assessment.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge. (Link to your bestpractices.dev project page below.)

  Higress has a current OpenSSF Best Practices Passing badge, with all Passing-level criteria reported as complete.

Ecosystem

Suggested

N/A

Required

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

  Adopter information has been collected and submitted through the designated channel.

• 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)

  Adopter information has been collected and submitted through the designated channel.

• TOC verification of adopters.

  Adopter information has been collected and submitted through the designated channel.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

  Kubernetes supplies declarative resources and access control; Ingress and Gateway API supply route configuration APIs; Istio supplies control-plane/xDS building blocks; Envoy processes traffic. Prometheus-compatible metrics and OpenTelemetry tracing connect the gateway to monitoring systems. OCI registries distribute plugin artifacts. Optional Nacos, Consul, Eureka, and ZooKeeper integrations supply service discovery, while configured model providers supply AI upstreams. These are distinct integration roles, not a claim of universal version compatibility. The General Technical Review, especially its Usability and Design sections, describes how operators select them; architecture documentation explains the configuration and traffic paths.

Specification Project Information (if applicable)

Not applicable. Higress is a software project and does not define normative behavior intended for independent third-party implementation.

Additional Information

The following CNCF review artifacts are already available or in progress:

• General Technical Review request, cncf/toc#2266
• Governance Review request, cncf/toc#2267
• Security Self-Assessment PR, cncf/toc#2268, merged on September 25, 2026

The project is ready to answer reviewer questions, join Project Reviews meetings, and provide additional evidence during due diligence.

Review coordination

The technical and governance documents are submitted in #2324 and #2325. They are project self-assessments awaiting CNCF review; their submission does not mean the reviews have passed.

Adopter information has been collected and submitted through the designated channel.

This application currently has no assigned reviewer. Once a TOC sponsor or reviewer is assigned, the project contacts listed above will proactively confirm the review channel, outstanding questions, and next steps; provide linked evidence in responses; and follow up on agreed actions. Non-confidential review outcomes will be recorded in this application and the linked technical review request or governance review request. DD, adopter verification, public comment, and the TOC decision remain pending.