docs: add CNCF incubation review artifacts (#4177)

Signed-off-by: EndlessSeeker <1766508902@qq.com>

docs/cncf/general-technical-review.md

@@ -0,0 +1,409 @@
+# General Technical Review — Higress / Incubation
+
+- **Project:** Higress
+- **Project version:** v2.2.3
+- **Website:** <https://higress.ai/en/>
+- **Date updated:** 2026-07-21
+- **Template version:** CNCF General Technical Review v1.0
+- **Review state:** Project working draft; maintainer approval and CNCF Project
+  Reviews verification pending
+- **Evidence branch:**
+  [`higress-group/higress@main`](https://github.com/higress-group/higress/tree/main)
+- **Intended TOC snapshot:** `projects/higress/tech-review/YYYY-MM-DD.md`
+- **Description:** Higress is a cloud-native API gateway built on Envoy and
+  Istio. It supports Kubernetes Ingress and Gateway API and is extensible with
+  Wasm plugins and native Go filters.
+
+This document answers all Day 0 and Day 1 questions required for an Incubation
+review. It follows the current CNCF TOC
+[General Technical Review questionnaire](https://github.com/cncf/toc/blob/main/toc_subprojects/project-reviews-subproject/general-technical-questions.md).
+Statements that are not yet backed by a project guarantee are identified as
+gaps rather than treated as completed controls.
+
+This is the project-maintained working copy. For formal Due Diligence, a CNCF
+reviewer or associate verifies it and archives a dated snapshot in `cncf/toc`.
+The reviewer should freeze evidence links to the reviewed revision when that
+snapshot is archived.
+
+## Project Self-Assessment Summary
+
+Higress has substantive evidence for every Day 0 and Day 1 question, but this
+document does not assign the project an external technical-review rating. The
+strongest Day 1 gaps are the absence of an automated
+upgrade→downgrade→upgrade matrix, a published compatibility-review cadence,
+and complete release supply-chain attestations. Broad control-plane RBAC also
+requires minimization and documented justification. These findings should be
+tracked during Due Diligence rather than hidden by marking the questionnaire
+complete.
+
+Day 2 questions are not required for an Incubation application and are not
+answered in this snapshot. Operational evidence that already exists may be
+added during CNCF review, but it is not needed to make the Day 0 and Day 1
+scope complete.
+
+## Day 0 — Planning Phase
+
+### Scope
+
+**How are roadmap scope and mid- to long-term features determined, and how does
+that map to contributions and the maintainer ladder?**
+
+Forward-looking goals and target versions are maintained in the public
+[`ROADMAP.md`](https://github.com/higress-group/higress/blob/main/ROADMAP.md),
+which links the version-controlled website roadmap. Feature scope and roadmap
+changes are discussed through public GitHub issues, discussions, and pull
+requests. Maintainers use lazy consensus, as documented in
+[`GOVERNANCE.md`](https://github.com/higress-group/higress/blob/main/GOVERNANCE.md),
+to accept project-direction changes.
+Contributors implement accepted work through pull requests, may receive
+delegated path-review responsibility as code owners, and may be nominated as
+maintainers after sustained contribution under
+[`MAINTAINERS.md`](https://github.com/higress-group/higress/blob/main/MAINTAINERS.md).
+Objective progression expectations for the intermediate code-owner role remain
+a project-maturity gap.
+
+**Who are the target personas?**
+
+- Platform and gateway engineers operating shared application entry points.
+- Application teams publishing APIs through Ingress or Gateway API.
+- AI platform teams governing access to LLM and MCP services.
+- Plugin developers extending request and response processing.
+- Security and SRE teams configuring policy, telemetry, and reliability.
+
+**What are the primary, additional, and unsupported use cases?**
+
+The primary use case is routing and governing north-south API traffic. Other
+supported use cases include Kubernetes Ingress and Gateway API, service
+registry integration, AI/LLM proxying, MCP server exposure, authentication,
+rate limiting, observability, and standalone development installations.
+
+Higress is not a transparent east-west service mesh, identity provider, model
+provider, general-purpose application runtime, secrets manager, or substitute
+for an organization's PKI, security governance, and incident response.
+
+**Which organizations benefit from adoption?**
+
+Organizations operating Kubernetes platforms, microservices, public or
+partner APIs, multi-provider AI platforms, or centralized platform-engineering
+services can benefit. Public examples are listed in
+[`ADOPTERS.md`](https://github.com/higress-group/higress/blob/main/ADOPTERS.md).
+
+**What end-user research has been completed?**
+
+The project records adopter names and use cases in `ADOPTERS.md` and receives
+feedback through GitHub and Discord. No independent end-user research report or
+published structured interview set is currently available. Adopter interviews
+for CNCF Incubation remain to be completed through the official TOC process.
+
+### Usability
+
+**How do target personas interact with the project?**
+
+Cluster administrators install Higress with Helm. Platform teams configure it
+with Kubernetes Ingress, Gateway API, Higress and Istio custom resources, the
+`hgctl` CLI, or the optional console. Application teams normally submit routes
+and policies rather than operate the data plane directly. Plugin developers use
+the Wasm SDKs or native filter interfaces.
+
+**What are the UX and UI?**
+
+The primary interface is declarative Kubernetes YAML and Helm values. The
+optional Higress Console provides browser-based management of routes, services,
+certificates, and plugins. `hgctl` provides command-line operations. Runtime
+behavior is observed through logs, metrics, traces, Kubernetes status, and
+Envoy administration data where enabled.
+
+**How does Higress integrate with production environments?**
+
+Higress integrates with Kubernetes, Envoy, Istio APIs, Gateway API,
+Prometheus-compatible monitoring, OpenTelemetry tracing, OCI registries,
+certificate issuers, and service registries such as Nacos, Consul, Eureka, and
+ZooKeeper. AI deployments may integrate with identity services, Redis, and
+model providers. Except for Kubernetes in the standard Helm deployment, these
+integrations are optional and selected by the adopter.
+
+### Design
+
+**What design principles and practices are followed?**
+
+- Declarative, versioned APIs and reconciliation.
+- Separation of control plane and Envoy-based data plane.
+- xDS dynamic updates without gateway configuration reloads.
+- Standard Kubernetes Ingress and Gateway API where possible.
+- Independently versioned extensions, with Wasm used as an isolation boundary.
+- Compatibility and regression coverage through unit, race, conformance, and
+  end-to-end tests.
+
+The component architecture and data flow are documented in
+[`docs/architecture.md`](https://github.com/higress-group/higress/blob/main/docs/architecture.md).
+
+**What differs between proof-of-concept, development, test, and production?**
+
+The all-in-one image or a minimal single-cluster Helm installation is suitable
+for evaluation. CI uses ephemeral kind clusters. Production operators should
+pin versions, use multiple gateway replicas, define resource sizing, configure
+PodDisruptionBudgets and topology placement, use production PKI, and monitor
+traffic and xDS health. The chart defaults to one controller replica and does
+not constitute a production high-availability guarantee.
+
+**Which services are required in the cluster?**
+
+The Kubernetes deployment requires the Kubernetes API and DNS. Higress
+controller/discovery supplies xDS to the gateway. The console, external service
+registries, Redis, certificate issuers, observability backends, OCI registries,
+and AI providers are optional.
+
+**How is identity and access management implemented?**
+
+Kubernetes ServiceAccounts and RBAC authorize control-plane access to cluster
+resources. TokenReview and SubjectAccessReview APIs are used by inherited Istio
+control-plane functions. Gateway-facing identity and policy are configured with
+TLS and plugins such as JWT, OIDC, key-auth, HMAC, and basic-auth. Higress does
+not operate an identity provider.
+
+**How is sovereignty addressed?**
+
+Higress does not transmit project usage telemetry by default. Operators choose
+their image/plugin registries, model providers, observability destinations,
+certificate authorities, and data locations. Request data is nevertheless
+processed by every configured gateway plugin and upstream provider; operators
+are responsible for selecting integrations that meet residency requirements.
+
+**Which compliance requirements are addressed?**
+
+The open-source project does not claim PCI-DSS, SOC 2, ISO 27001, GDPR, or other
+regulatory certification. It is Apache-2.0 licensed and CI includes source and
+dependency license checks. Deployers must assess their full environment and
+configuration.
+
+**What are the high-availability requirements?**
+
+Gateway availability requires multiple replicas or nodes, adequate capacity,
+health probes, and failure-domain placement. Controller unavailability stops
+new configuration but existing Envoy processes may continue serving their last
+accepted configuration. Production control-plane availability requires
+multiple appropriately configured replicas and Kubernetes leader-election
+behavior. The default single controller is a gap operators must address.
+
+**What are the CPU, network, memory, and storage requirements?**
+
+Current Helm defaults request 500m CPU and 2 GiB memory for the controller and
+2 CPU and 2 GiB memory per gateway. Actual requirements depend on route count,
+plugin set, configuration churn, request rate, payload sizes, connections, and
+telemetry. Operators must size from load tests. Traffic bandwidth and
+connection count drive network and socket consumption.
+
+Configuration and certificates are stored as Kubernetes API objects. Gateway
+and controller runtime files are ephemeral. The optional console and configured
+integrations may introduce separate persistence requirements.
+
+**What is the API design?**
+
+- **Topology and conventions:** Kubernetes Ingress, Gateway API, Istio
+  networking APIs, and versioned Higress CRDs under `networking.higress.io` and
+  `extensions.higress.io` are reconciled into xDS resources.
+- **Defaults:** Helm defaults create controller/discovery and gateway
+  deployments, ServiceAccounts, RBAC, Services, and CRDs. Gateway service type
+  defaults to `LoadBalancer`; automatic HTTPS is enabled in chart values.
+- **Additional configuration:** Production use normally requires explicit
+  resource sizing, exposure, TLS, replicas, credentials, monitoring, and route
+  policy.
+- **New/changed calls:** Enabling registry, certificate, identity, OCI, Redis,
+  or AI integrations causes calls to the endpoints explicitly configured by
+  the operator. Enabling Gateway API or inference support causes the controller
+  to watch and reconcile those API groups.
+- **Kubernetes compatibility:** Compatibility is tested with kind and Gateway
+  API conformance. CRD and Kubernetes-version requirements are carried in Helm
+  packaging and release dependencies.
+- **Versioning and breaking changes:** CRDs have explicit API versions. Stable
+  breaking changes require migration guidance, deprecation notice, and release
+  notes. Alpha Gateway API and inference capabilities are explicitly enabled
+  and do not have the same stability promise as stable APIs.
+
+**What is the release process?**
+
+Higress uses semantic version tags, including release-candidate suffixes when
+needed. A `v*.*.*` tag triggers workflows that build controller, pilot and
+gateway images, attach generated CRDs, build multi-platform `hgctl` archives,
+and generate release notes. Versions are recorded in `VERSION`, Helm chart
+metadata, dependency metadata, and `release-notes/`. The normative
+[`RELEASE.md`](https://github.com/higress-group/higress/blob/main/RELEASE.md)
+defines planning, two-person approval, validation, tagging, publishing,
+verification, rollback/correction, security releases, and supported-version
+changes.
+
+### Installation
+
+**How is the project installed and initialized?**
+
+```console
+helm repo add higress.io https://higress.io/helm-charts
+helm repo update
+helm install higress -n higress-system higress.io/higress --create-namespace
+```
+
+The chart installs CRDs, controller/discovery, gateway, Services,
+ServiceAccounts, and RBAC. Operators then apply routes and policies or use the
+optional console.
+
+**How does an adopter validate installation?**
+
+Check the Helm release and Ready state of controller and gateway pods, apply a
+sample backend and route, then send an HTTP request through the gateway and
+inspect status, logs, and metrics. CI performs the same class of installation
+in ephemeral clusters and runs Gateway API and Higress conformance traffic.
+
+### Security
+
+**Where is the cloud-native security self-assessment?**
+
+[`docs/cncf/security-self-assessment.md`](./security-self-assessment.md)
+
+**How does Higress address the Cloud Native Security Tenets?**
+
+- **Secure by default:** gateway containers use non-root and restricted
+  settings on supported Kubernetes platforms, TLS and private Secret delivery
+  are supported, and optional integrations require explicit configuration.
+- **Least privilege:** separate ServiceAccounts and RBAC exist for controller
+  and gateway. The controller's broad ClusterRole and empty default container
+  security context are known exceptions requiring improvement.
+- **Defense in depth:** Kubernetes RBAC, TLS/SDS, Envoy validation, Wasm
+  isolation, authentication/policy plugins, and network controls provide
+  distinct layers.
+- **Explicit trust and boundaries:** Kubernetes administrators, xDS,
+  certificate sources, plugins, registries, identity providers, and upstreams
+  are separate trust boundaries described in the security self-assessment.
+- **Secure lifecycle:** public review, automated tests, license checks, weekly
+  CodeQL, private advisories, and coordinated disclosure are in place, with
+  SBOM/signing/dynamic-analysis gaps disclosed.
+
+Operators can loosen security by overriding pod/container security contexts,
+using privileged or host networking modes, expanding RBAC, exposing admin
+ports, disabling TLS/policy, or installing third-party/native plugins. These
+settings should be treated as risk acceptances and tested in the adopter's
+threat model.
+
+**What security hygiene is maintained, and which features are high risk if not
+maintained?**
+
+The project uses required review, build and unit tests with Go race detection,
+Gateway API/Higress conformance, plugin tests, license checks, weekly CodeQL,
+versioned dependencies, Private Security Advisories, and coordinated
+disclosure. Certificate handling, RBAC reconciliation, xDS generation and
+validation, parsers/routing, authentication and authorization plugins, plugin
+loading, and release artifacts are treated as security-critical boundaries.
+
+**What privileges are required?**
+
+The gateway reads Kubernetes Secrets for SDS. The controller watches and
+reconciles ingress, Gateway API, Higress/Istio, discovery, certificate,
+admission, and leader-election resources and performs TokenReview and
+SubjectAccessReview calls. Several controller rules are cluster-wide and use
+broad resource or verb sets. These are functional requirements of the current
+implementation, but the project has not demonstrated that every permission is
+minimal.
+
+**How are certificates rotated?**
+
+Gateway certificates are delivered through SDS. Automatic HTTPS can request
+and renew ACME certificates, and Kubernetes Secrets can be updated without
+gateway configuration reload. Operators remain responsible for issuer trust,
+renewal monitoring, emergency rotation, and external certificate systems.
+
+**How is the software supply chain secured?**
+
+Source and dependency licenses are checked; dependencies and submodule commits
+are versioned; changes are reviewed and tested; release artifacts are produced
+by GitHub Actions from version tags. Some workflow actions are commit-pinned.
+Project-generated release SBOMs, universal immutable action pinning, artifact
+signatures, and verifiable build provenance are not currently present and are
+recorded as gaps in the security self-assessment.
+
+## Day 1 — Installation and Deployment Phase
+
+### Project Installation and Configuration
+
+**What do installation and configuration look like?**
+
+Helm installs the project resources. Values select watched namespaces, replica
+counts, resources, autoscaling, Service exposure, security contexts,
+observability, Gateway API features, image/plugin registries, and optional
+integrations. Operators should pin a chart/application version and keep reviewed
+values in version control. Routes, services, credentials, and plugin policy are
+then applied as Kubernetes resources or through the console.
+
+### Project Enablement and Rollback
+
+**How is Higress enabled or disabled in a live cluster, and is downtime
+required?**
+
+Install the chart and direct selected IngressClasses, GatewayClasses, routes,
+DNS, or load-balancer traffic to Higress. Workloads do not require sidecars.
+With sufficient replicas, ordinary controller and gateway rolling updates are
+designed not to require application downtime. Capacity loss, incompatible
+configuration, or a single-replica deployment can cause interruption.
+
+Disable Higress by first moving traffic and route ownership to another entry
+point, then uninstalling the Helm release. Existing workload behavior changes
+only when traffic or resources select Higress.
+
+**How are enablement and disablement tested?**
+
+Pull-request CI installs Higress into kind and executes conformance and E2E
+traffic. There is no dedicated automated migration test that moves live traffic
+from another gateway to Higress and back; this is a gap.
+
+**How are created resources cleaned up, including CRDs?**
+
+`helm uninstall` removes chart-owned namespaced and cluster-scoped resources
+managed by the release. CRDs and user-authored custom resources must be
+inventoried and removed deliberately because automatic deletion could destroy
+configuration data.
+
+### Rollout, Upgrade and Rollback Planning
+
+**How is compatibility with Kubernetes and orchestration tools maintained?**
+
+The project updates Kubernetes, Gateway API, Istio, and Envoy dependencies and
+uses build, kind, conformance, and E2E workflows on ongoing changes. Supported
+versions are communicated through chart/dependency metadata, documentation,
+and releases. No fixed public compatibility-review cadence is documented.
+
+**How are rollbacks performed, and how can they fail?**
+
+Operators retain the previous Helm revision, values, configuration, and pinned
+images, then use `helm rollback <release> <revision>`. CRD storage/schema
+changes, incompatible user configuration, unavailable old images, RBAC changes,
+certificate changes, or external dependency changes may prevent a complete
+rollback. Control-plane failure may leave existing gateways serving their last
+accepted xDS state; data-plane rollout, plugin load failure, or invalid
+fail-closed policy can affect live traffic.
+
+**Which metrics should trigger rollback?**
+
+Readiness failures, xDS rejection/NACKs, HTTP 4xx/5xx changes, latency and
+timeout regression, gateway/controller restart rate, certificate errors,
+plugin load failures, connection failures, and CPU/memory/socket saturation
+should be compared with the pre-rollout baseline.
+
+**How are upgrade→downgrade→upgrade paths tested?**
+
+The repository tests clean installation and current-version conformance but
+does not contain a dedicated automated upgrade→downgrade→upgrade version
+matrix. This is a known Day 1 gap; operators must validate their exact source
+and target versions in a non-production cluster.
+
+**How are deprecations and removals communicated?**
+
+They are communicated through GitHub releases, versioned release notes,
+documentation, and API/version changes. `RELEASE.md` requires migration and
+deprecation guidance in the release pull request and announcement. The project
+does not currently define a universal minimum deprecation period for all API
+types, which remains a process improvement.
+
+**How are alpha and beta capabilities used during rollout?**
+
+Alpha Gateway API and inference capabilities are selected through explicit
+chart values and API versions. Operators should enable them first in a test or
+canary environment, monitor the rollback signals above, and avoid relying on
+their stability as if they were stable APIs.

docs/cncf/governance-review.md

@@ -0,0 +1,274 @@
+# Higress Governance Review
+
+This is the Higress project's self-assessed Governance Review for its CNCF
+Incubation application. It follows the current CNCF TOC
+[Governance Review Template](https://github.com/cncf/toc/blob/main/toc_subprojects/project-reviews-subproject/governance-review-template.md).
+A CNCF Project Reviews reviewer may amend the assessment and findings during
+the public review.
+
+- **Review state:** Project working draft; maintainer approval and CNCF Project
+  Reviews verification pending
+- **Evidence branch:**
+  [`higress-group/higress@main`](https://github.com/higress-group/higress/tree/main)
+- **Template verified:** 2026-07-21 against `cncf/toc` `main`
+- **Intended TOC snapshot:**
+  `projects/higress/governance-review/YYYY-MM-DD.md`
+
+This is the project-maintained working copy. CNCF reviewers may revise the
+status and findings before a dated snapshot is archived in `cncf/toc`.
+The reviewer should freeze evidence links to the reviewed revision when that
+snapshot is archived.
+
+## Summary and Assessment
+
+**Status: Mostly Satisfactory**
+
+Higress has discoverable governance, maintainer, code-owner, contribution,
+community, security, and Code of Conduct documents. The project defines
+project-wide maintainer responsibility, delegated code ownership, subproject
+scope, vendor-neutral decisions, maintainer lifecycle, communication channels,
+and security-response roles. The maintainer list includes seven publicly active
+people affiliated with four organizations.
+
+The documentation and public evidence satisfy all Governance Review criteria
+except one Incubation-required item: Higress does not currently publish an
+up-to-date public meeting scheduler or integrate its meetings with the CNCF
+calendar. The project should establish that real public meeting infrastructure
+before asserting that the Governance Review has no remaining Must-Fix item.
+
+### Executing the Assessment
+
+The self-assessment reviewed the following repository evidence as it exists on
+2026-07-21:
+
+- [`GOVERNANCE.md`](https://github.com/higress-group/higress/blob/main/GOVERNANCE.md)
+- [`MAINTAINERS.md`](https://github.com/higress-group/higress/blob/main/MAINTAINERS.md)
+- [`CODEOWNERS`](https://github.com/higress-group/higress/blob/main/CODEOWNERS)
+- [`CONTRIBUTING_EN.md`](https://github.com/higress-group/higress/blob/main/CONTRIBUTING_EN.md)
+- [`CODE_OF_CONDUCT.md`](https://github.com/higress-group/higress/blob/main/CODE_OF_CONDUCT.md)
+- [`COMMUNITY.md`](https://github.com/higress-group/higress/blob/main/COMMUNITY.md)
+- [`SECURITY.md`](https://github.com/higress-group/higress/blob/main/SECURITY.md)
+- [`README.md`](https://github.com/higress-group/higress/blob/main/README.md)
+- Git history for the governance, maintainer, and ownership files
+
+The review distinguishes documented policy from observed repository evidence.
+It does not infer private processes or settings that are not publicly recorded.
+
+### Must-Fix Items
+
+The following issues need to be resolved before the Higress Incubation
+application asserts completion of its Governance Review:
+
+1. Publish an up-to-date public meeting scheduler and/or integrate the project
+   meetings with the CNCF calendar.
+
+### Points of Excellence
+
+- The maintainer roster is public and shows affiliation diversity across
+  Alibaba Cloud, Trip.com, XinYe Technology, and NVIDIA, with linked public
+  activity evidence for every listed maintainer.
+- Governance distinguishes delegated code ownership from project-wide
+  maintainer authority and defines role and subproject lifecycle processes.
+- The project publishes an authoritative channel inventory and separates
+  public project decisions from narrowly scoped confidential reporting.
+- The named Security Response Team has defined incident roles, independent
+  review, conflict handling, and escalation.
+- Governance explicitly protects vendor-neutral direction through individual
+  seats, equal voting weight, and conflict disclosure.
+
+### Areas for Improvement
+
+The following are non-blocking at Incubation but would improve long-term
+governance maturity:
+
+- Record governance evolution and link decisions to issues or pull requests.
+- Publish examples demonstrating the maintainer lifecycle in practice.
+- Add objective progression expectations for appointment to the code-owner
+  role.
+- Extend `CODEOWNERS` or equivalent ownership records to each active
+  subproject and periodically audit coverage.
+- Track contributor growth and recruitment trends using the linked CNCF
+  DevStats metrics, not only point-in-time activity.
+
+---
+
+## Review
+
+This review audits the project's current governance evidence. The project's
+Incubation application has not yet been opened; this file is the project's
+self-assessment to accompany that application.
+
+### Governance Summary
+
+Higress uses maintainer-led lazy consensus. Significant decisions are recorded
+in public issues or pull requests. When consensus cannot be reached,
+non-conflicted maintainers may vote publicly and a simple majority of votes
+cast decides. Governance defines contributor, code-owner, and maintainer
+authority; the maintainer and subproject lifecycles; vendor neutrality; and
+function-based teams. Confidential security work is handled by a named
+Security Response Team under a public mandate.
+
+### Governance Evolution
+
+**Incubating: Suggested — Partially satisfied.**
+
+`GOVERNANCE.md` and `MAINTAINERS.md` were introduced in April 2026, and
+`CODEOWNERS` has changed repeatedly since 2022. This demonstrates change over
+time, but the repository does not explain why governance evolved or connect
+those changes to project experience and outcomes.
+
+### Discoverability
+
+**Incubating: Suggested — Satisfied.**
+
+The README links the governance, maintainer, contribution, Code of Conduct, and
+security documents from its Community section.
+
+### Accuracy and Clarity
+
+**Governance reflects actual activities — Incubating: Suggested — Satisfied.**
+
+Public issue/PR collaboration and lazy consensus are consistent with the
+repository workflow. Code-owner authority, security-team operation, and the
+absence of a current recurring public meeting are documented without claiming
+unobserved processes.
+
+**Vendor-neutral direction — Incubating: Suggested — Satisfied.**
+
+Governance states that roles are held by individuals, prohibits guaranteed
+employer seats, vetoes, or preferred decision weight, requires material
+conflict disclosure, and evaluates contributions and integrations on community
+and technical merit.
+
+### Decisions and Role Assignments
+
+**Leadership, contribution, CNCF, governance, and goal decisions — Incubating:
+Suggested — Satisfied.**
+
+Governance applies public lazy consensus and non-conflicted maintainer voting
+to leadership, contribution acceptance, goals, requests to CNCF, subproject
+scope, and governance changes. The contribution guide and `CODEOWNERS` provide
+the day-to-day change-review path.
+
+**Function-based teams — Incubating: Suggested — Satisfied.**
+
+Governance defines the creation and retirement requirements for function-based
+teams. `SECURITY.md` names the Security Response Team and defines onboarding,
+offboarding, incident assignments, conflicts, independent review, and
+escalation.
+
+### Maintainers and Maintainer Lifecycle
+
+**Complete lifecycle — Incubating: Suggested — Satisfied.**
+
+The project documents nomination, public activity review, voluntary departure,
+inactivity, removal, emeritus status, and return.
+
+**Lifecycle demonstrated — Incubating: Suggested — Not demonstrated.**
+
+The maintainer file has only one introducing commit in the available history.
+No public example of adding, replacing, or moving a maintainer to emeritus is
+linked.
+
+**Names, contact, responsibility, affiliation — Incubating: Required —
+Satisfied.**
+
+The roster provides names, GitHub contacts, project-wide responsibility
+domains, and affiliations for all maintainers.
+
+**Appropriate number of active maintainers — Incubating: Required —
+Satisfied.**
+
+Seven maintainers cover the project and its four subprojects. The roster
+defines active status and annual public review, and its 2026 review links
+public issue and pull-request activity for every listed maintainer during the
+preceding 12 months.
+
+**Maintainers from at least two organizations — Incubating: N/A, but met.**
+
+The roster names four affiliations.
+
+### Ownership
+
+**Code and documentation ownership matches governance roles — Incubating:
+Required — Satisfied.**
+
+Governance defines code owners as delegated path reviewers, documents their
+authority and public appointment/removal process, and makes clear that code
+ownership neither grants project-wide governance authority nor limits a
+maintainer's project-wide responsibility. This matches `CODEOWNERS`, which
+includes maintainers and additional area reviewers.
+
+### Code of Conduct
+
+**Adoption and adherence — Incubating: Required — Satisfied as documented.**
+
+The project adopts the CNCF Code of Conduct in `CODE_OF_CONDUCT.md` and links it
+from the README and governance.
+
+**Cross-link from governance — Incubating: Required — Satisfied.**
+
+`GOVERNANCE.md` links both the CNCF Code of Conduct and the project copy.
+
+### Subprojects
+
+**All subprojects listed — Incubating: Required — Satisfied.**
+
+Governance identifies the primary repository and lists `higress-console`,
+`higress-standalone`, `plugin-server`, and `wasm-go` as active subprojects. It
+also distinguishes upstream forks, integrations, examples, websites, and
+other organization repositories from the CNCF project scope.
+
+**Subproject lifecycle — Incubating: Suggested — Satisfied.**
+
+Governance applies the project-wide maintainer roster and public decision
+process to subprojects, records each repository's responsibility and status,
+and requires leadership, contribution, communication, and lifecycle details
+when a subproject is added, removed, transferred, or archived.
+
+### Contributors and Community
+
+**Contributor ladder — Incubating: Suggested — Partially satisfied.**
+
+Governance defines contributor, delegated code-owner, and project-wide
+maintainer roles. The contribution and maintainer documents define how
+contributors participate and how sustained contributors progress to
+maintainership; code-owner assignments are changed publicly through
+`CODEOWNERS`. Objective progression expectations for the intermediate
+code-owner role can be made more explicit.
+
+**Issue and change submission — Incubating: Required — Satisfied.**
+
+`CONTRIBUTING_EN.md`, issue templates, and the pull-request template document
+the process.
+
+**At least one public communication channel — Incubating: Required —
+Satisfied.**
+
+GitHub Issues, pull requests, and Discord are publicly documented.
+
+**All public/private channels documented — Incubating: Required — Satisfied.**
+
+`COMMUNITY.md` is the authoritative inventory for project and subproject GitHub
+channels, Discord, mailing and localized community channels, documentation,
+and narrowly scoped private security and Code of Conduct reporting. It states
+that informal or employer-internal conversations are not project decision
+channels and requires public decision records.
+
+**Public meeting scheduler/CNCF calendar — Incubating: Required — Not
+satisfied.**
+
+No current public meeting scheduler or CNCF calendar integration is linked from
+the reviewed repository documents.
+
+**Contribution documentation — Incubating: Required — Satisfied.**
+
+The contribution guide covers issues, pull requests, branches, commits, tests,
+style, and AI-assisted contribution requirements.
+
+**Contributor activity and recruitment — Incubating: Required — Satisfied.**
+
+`COMMUNITY.md` links continuously updated GitHub contributor and repository
+activity, CNCF DevStats, active-maintainer evidence, `help wanted` and `good
+first issue` recruitment queues, the contribution path, and public mentoring
+channels.

docs/cncf/incubation-application.md

@@ -0,0 +1,218 @@
+# Higress CNCF Incubation Application — Working Draft
+
+This working draft follows the CNCF TOC
+[Project Incubation Application v1.6](https://github.com/cncf/toc/blob/main/.github/ISSUE_TEMPLATE/template-incubation-application.md),
+verified on 2026-07-21. It is not ready to file while any item labelled
+**BLOCKED** below remains unresolved.
+
+## Review Project Moving Level Evaluation
+
+- [ ] I have reviewed the TOC moving-level readiness triage guide, ensured the
+  criteria are met before opening the issue, and understand that unmet criteria
+  will result in closure.
+
+This box remains unchecked because the public meeting, access-control evidence,
+OpenSSF Passing badge, adopter interviews/verification, and remaining
+vendor-neutral resource work are incomplete.
+
+## Project information
+
+- **Project repositories:**
+  [`higress`](https://github.com/higress-group/higress),
+  [`higress-console`](https://github.com/higress-group/higress-console),
+  [`higress-standalone`](https://github.com/higress-group/higress-standalone),
+  [`plugin-server`](https://github.com/higress-group/plugin-server), and
+  [`wasm-go`](https://github.com/higress-group/wasm-go)
+- **Project site:** <https://higress.ai/en/>
+- **Subprojects:** `higress-console`, `higress-standalone`, `plugin-server`,
+  and `wasm-go`; authoritative scope is in
+  [`GOVERNANCE.md`](https://github.com/higress-group/higress/blob/main/GOVERNANCE.md)
+- **Related projects:** confirm before submission whether any project point of
+  contact operates a technically related project in another foundation
+- **Communication:**
+  [`COMMUNITY.md`](https://github.com/higress-group/higress/blob/main/COMMUNITY.md)
+- **Project points of contact:** Yuanxiao Zhao and Yiquan Dong; **TODO:** confirm
+  direct contact emails before filing (public community contact:
+  [higress@googlegroups.com](mailto:higress@googlegroups.com))
+
+## Incubation Criteria Summary
+
+### Application Level Assertion
+
+- [x] Higress is currently Sandbox, accepted on 2026-03-15, and is applying to
+  Incubation.
+- [ ] Higress is applying to join CNCF directly at Incubation level. Not
+  applicable; remove this option from the filed issue.
+
+### Adoption Assertion
+
+Public production adopters in
+[`ADOPTERS.md`](https://github.com/higress-group/higress/blob/main/ADOPTERS.md)
+include Ant Digital, Kuaishou, Trip.com, Vipshop, and Labring.
+
+- [ ] **BLOCKED — Adopter interviews:** submit 5–7 willing adopters through the
+  official CNCF Adopter Interview Questionnaire before DD assignment. This
+  requires adopter consent and current contact details; a repository edit
+  cannot complete it.
+
+## Application Process Principles
+
+### Suggested
+
+- [ ] Engage with the appropriate domain-specific TAG(s) to present the
+  technical architecture. This is suggested, not a filing prerequisite in
+  v1.6. A future presentation should be linked here if completed.
+
+### Required
+
+- [x] Complete a General Technical Review. The project self-assessment is in
+  [`general-technical-review.md`](https://github.com/higress-group/higress/blob/main/docs/cncf/general-technical-review.md);
+  maintainer approval and CNCF Project Reviews verification are requested.
+- [ ] Complete a Governance Review. The self-assessment is in
+  [`governance-review.md`](https://github.com/higress-group/higress/blob/main/docs/cncf/governance-review.md),
+  but its public-meeting Must-Fix remains open.
+- [ ] **BLOCKED — All project metadata and resources are vendor-neutral.**
+  Governance and the primary README now document vendor-neutral direction and
+  no longer promote a single commercial product, but release images remain
+  hosted only on Alibaba Cloud registry domains, the historical Go module path
+  contains `github.com/alibaba`, the website roadmap still includes a
+  single-vendor enterprise mapping, and the security policy requires duplicate
+  submission to the vendor-operated Alibaba Security Response Center. The
+  application needs a maintainer/CNCF-reviewed compatibility and infrastructure
+  plan.
+- [x] Review and acknowledgement of Sandbox expectations and maturity-level
+  requirements. Higress was accepted as a Sandbox project on 2026-03-15 and
+  this application explicitly acknowledges the current requirements.
+- [ ] Due Diligence Review. This is completed through CNCF review, resolution
+  of concerns, and public comment after a ready application is filed.
+- [x] Appropriate installation, end-user, reference, and sample documentation
+  is linked from the project README and website.
+
+## Governance and Maintainers
+
+### Suggested
+
+- [ ] Complete the Governance Review with the CNCF Project Reviews subproject;
+  external verification is pending.
+- [x] Governance is discoverable and version controlled.
+- [x] Governance documents actual public decision, leadership, role, and
+  security-team processes without claiming a recurring meeting that does not
+  exist.
+- [x] Governance documents vendor-neutral project direction and conflicts.
+- [x] Leadership, contribution, CNCF request, governance, goal, and subproject
+  decisions use a public process.
+- [x] Function-based team assignment, onboarding, removal, conflicts, and
+  retirement are documented.
+- [x] The complete maintainer lifecycle is documented.
+- [ ] Demonstrate a completed maintainer lifecycle event. Suggested; no public
+  addition, replacement, or emeritus transition is yet linked.
+- [x] Subproject scope, leadership model, contribution, status, and lifecycle
+  are documented.
+
+### Required
+
+- [x] Current maintainers include names, GitHub contact, responsibility domain,
+  and affiliation in
+  [`MAINTAINERS.md`](https://github.com/higress-group/higress/blob/main/MAINTAINERS.md).
+- [x] Seven active maintainers are appropriate to the primary repository and
+  four subprojects; the annual activity review links public evidence for each.
+- [x] Code and documentation ownership matches the documented code-owner and
+  maintainer roles.
+- [x] The CNCF Code of Conduct is adopted and linked.
+- [x] The Code of Conduct is cross-linked from governance.
+- [x] All current subprojects are listed in governance.
+
+## Contributors and Community
+
+### Suggested
+
+- [x] Contributor, code-owner, and maintainer roles form a contributor ladder;
+  objective code-owner progression criteria remain an improvement item.
+
+### Required
+
+- [x] Issue and change submission are documented.
+- [x] Public GitHub and Discord communication channels are documented.
+- [x] All official project, subproject, and narrowly scoped non-public channels
+  are inventoried in `COMMUNITY.md`.
+- [ ] **BLOCKED — Public meeting scheduler/CNCF calendar.** Higress does not
+  currently publish an up-to-date public meeting scheduler or integrate its
+  meetings with the CNCF calendar. A real schedule or calendar integration must
+  be established rather than represented by documentation alone.
+- [x] Contribution documentation is maintained.
+- [x] Contributor activity and recruitment are demonstrated through GitHub,
+  DevStats, contribution labels, and maintainer activity links.
+
+## Engineering Principles
+
+### Suggested
+
+- [x] The roadmap change process is documented in
+  [`ROADMAP.md`](https://github.com/higress-group/higress/blob/main/ROADMAP.md).
+- [x] Regular release history is public in GitHub Releases and versioned
+  release notes.
+
+### Required
+
+- [x] Project goals, differentiation, need, and cloud-native use cases are
+  documented in the README and GTR.
+- [x] What Higress does and why it exists are documented in the README and GTR.
+- [x] A maintained public roadmap and change process are linked from
+  `ROADMAP.md`.
+- [x] Architecture and software design are documented in
+  [`docs/architecture.md`](https://github.com/higress-group/higress/blob/main/docs/architecture.md)
+  and the GTR.
+- [x] The release process is documented in
+  [`RELEASE.md`](https://github.com/higress-group/higress/blob/main/RELEASE.md).
+
+## Security
+
+### Suggested
+
+- [ ] Complete a joint assessment with CNCF TAG Security and Compliance. This
+  is suggested, not a v1.6 filing prerequisite.
+
+### Required
+
+- [x] Vulnerability reporting is documented in
+  [`SECURITY.md`](https://github.com/higress-group/higress/blob/main/SECURITY.md).
+- [ ] **BLOCKED — Enforced repository access-control evidence.** Public files
+  do not prove organization 2FA, least-privilege team access, protected default
+  branch/rulesets, required non-author review, or protected release
+  environments. An organization owner must verify/configure these settings and
+  publish reviewable evidence appropriate for CNCF DD.
+- [x] Named security-response membership, incident roles, two-person review,
+  conflicts, report handling, and escalation are documented.
+- [x] The Security Self-Assessment is documented in
+  [`security-self-assessment.md`](https://github.com/higress-group/higress/blob/main/docs/cncf/security-self-assessment.md).
+- [ ] **BLOCKED — OpenSSF Best Practices Passing badge.** The public entry is
+  currently 96%. Warning enforcement/remediation, static-analysis frequency,
+  confirmed CodeQL alert disposition, and project-level dynamic analysis remain
+  before the badge can be certified as Passing.
+
+## Ecosystem
+
+### Required
+
+- [x] The public adopter list records organizations, contacts, environment, and
+  use cases.
+- [x] At least three independent adopters report production use; five are
+  publicly listed.
+- [ ] **BLOCKED — TOC adopter verification.** Complete the official interviews
+  and allow CNCF/TOC reviewers to verify the adopter evidence.
+- [x] Integrations and compatibility with Kubernetes, Gateway API, Envoy,
+  Istio, Prometheus/OpenTelemetry, OCI, service registries, and model providers
+  are documented in the GTR, architecture, README, and user documentation.
+
+## Current filing decision
+
+**Do not file yet.** The top-level readiness attestation would be false while
+the following required items remain open:
+
+1. a real public meeting scheduler and/or CNCF calendar integration;
+2. enforced repository access-control evidence;
+3. OpenSSF Best Practices Passing, including warning enforcement, analysis
+   frequency, alert disposition, and dynamic analysis;
+4. vendor-neutral resource/website remediation or an accepted migration plan;
+5. 5–7 adopter interview submissions and later TOC verification; and
+6. direct project point-of-contact emails confirmed for the issue.

docs/cncf/security-self-assessment.md

@@ -0,0 +1,282 @@
+# Higress Security Self-Assessment
+
+## Metadata
+
+| | |
+| --- | --- |
+| Assessment stage | Complete working draft, pending maintainer approval; updated 2026-07-21 |
+| Software | <https://github.com/higress-group/higress> |
+| Review state | Prepared from public project evidence; no independent security review or audit |
+| Evidence branch | [`higress-group/higress@main`](https://github.com/higress-group/higress/tree/main) |
+| Assessment outline | [CNCF TAG Security Self-Assessment](https://tag-security.cncf.io/community/assessments/guide/self-assessment/) |
+| Intended TOC snapshot | `projects/higress/security-assessment/self-assessment.md` |
+| Security provider | No. Higress provides security features, but its primary function is API gateway traffic management. |
+| Languages | Go, C++, Rust, AssemblyScript, shell, and Helm/YAML |
+| SBOM | Not generated for release artifacts. Go module files, Cargo lock data, and container build files provide dependency inputs. |
+
+### Security Links
+
+| Document | Location |
+| --- | --- |
+| Vulnerability reporting and response | [`SECURITY.md`](https://github.com/higress-group/higress/blob/main/SECURITY.md) |
+| Architecture | [`docs/architecture.md`](https://github.com/higress-group/higress/blob/main/docs/architecture.md) |
+| Helm defaults | [`helm/core/values.yaml`](https://github.com/higress-group/higress/blob/main/helm/core/values.yaml) |
+| OpenSSF Best Practices | <https://www.bestpractices.dev/projects/12667> |
+
+This is the project-maintained working copy. For formal Due Diligence, a vetted
+snapshot must be archived at the path above in `cncf/toc`. The reviewer should
+freeze evidence links to the reviewed revision when that snapshot is archived.
+
+## Overview
+
+Higress translates declarative ingress, Gateway API, service discovery, and
+plugin configuration into xDS consumed by an Envoy-based gateway. It accepts
+untrusted downstream traffic, selects upstream services, applies traffic and
+security policy, and proxies requests and responses.
+
+### Actors and Actions
+
+- **Cluster administrator:** installs/upgrades Higress, grants RBAC, configures
+  exposure, certificates, registries, and security contexts.
+- **Gateway operator/platform engineer:** creates routes, services, policies,
+  plugins, credentials, and observability configuration.
+- **Application owner:** requests routes/policy and operates upstream services.
+- **End user/client:** sends potentially hostile network requests.
+- **Plugin author/provider:** supplies code that executes in the gateway's Wasm
+  sandbox or native filter boundary.
+- **External provider/registry:** supplies service discovery data, plugins,
+  identity metadata, certificates, or AI/model APIs when configured.
+- **Project maintainer/release manager:** reviews changes, responds to reports,
+  and publishes releases.
+
+### Background
+
+Higress combines the Envoy data plane and Istio-derived control plane with
+Ingress/Gateway API translation and an extensible plugin ecosystem. The
+control plane watches configuration and discovery sources and generates xDS;
+the data plane accepts untrusted network traffic and applies that configuration.
+
+### Architecture and Data Flow
+
+The security-relevant flow is:
+
+1. An authenticated Kubernetes user or automation writes Ingress, Gateway API,
+   Higress/Istio, Secret, and policy resources to the Kubernetes API.
+2. Higress controller and discovery components watch authorized resources,
+   optional service registries, and certificate sources, then translate the
+   desired state into xDS and SDS configuration.
+3. Gateway pilot agents and Envoy processes receive configuration and secret
+   material. Existing gateways may retain their last accepted configuration if
+   the control plane becomes unavailable.
+4. Untrusted clients connect to the gateway. Envoy and configured filters parse,
+   authenticate, authorize, transform, and route requests to upstream services
+   or explicitly configured AI/model providers.
+5. The gateway emits access logs, metrics, and traces to destinations selected
+   by the operator. Depending on configuration, those signals may include
+   sensitive request metadata.
+
+### Data Assets and Trust Boundaries
+
+| Asset or boundary | Security relevance |
+| --- | --- |
+| Kubernetes configuration and status | Unauthorized mutation can redirect traffic, weaken policy, load code, or disrupt availability. |
+| TLS keys, certificates, tokens, and upstream credentials | Disclosure or replacement can enable impersonation, traffic decryption, or unauthorized upstream access. |
+| Request/response bodies, AI prompts, and model outputs | May contain application secrets, personal data, proprietary data, or attacker-controlled content. |
+| xDS/SDS control-plane boundary | Integrity and availability determine what code, routes, clusters, policy, and secrets the data plane uses. |
+| Gateway process boundary | Native Go/C++ filters execute inside the proxy trust boundary; a defect can affect the full gateway process. |
+| Wasm plugin boundary | Wasm provides stronger isolation than a native filter, but plugins can still observe or modify traffic granted to them. |
+| External integration boundary | Registries, identity providers, certificate issuers, Redis, observability systems, OCI registries, and model providers have separate operators and trust. |
+| Source and release boundary | Compromise of source control, CI identities, dependencies, images, or plugin artifacts can affect every adopter. |
+
+### Goals
+
+- Preserve the integrity and availability of configuration delivery between
+  control and data planes, reject invalid xDS updates, and make transport trust
+  assumptions explicit for operators.
+- Terminate and originate TLS as configured and distribute private key material
+  through Kubernetes Secrets and SDS.
+- Isolate Wasm plugin execution from the gateway process to the extent provided
+  by the Envoy/Wasm runtime.
+- Enforce configured routing, authentication, authorization, traffic, and data
+  policies consistently.
+- Contact only the external registries, identity systems, observability
+  backends, AI providers, and upstreams explicitly configured by the operator.
+- Provide a private vulnerability reporting and coordinated disclosure path.
+
+### Non-goals
+
+Higress does not secure a compromised Kubernetes control plane, node, cluster
+administrator, upstream service, identity provider, model provider, registry,
+or native plugin. It does not guarantee that user-authored policy is correct,
+provide regulatory certification, or replace network segmentation, secrets
+management, PKI governance, application security, or incident response.
+
+## Self-Assessment Use
+
+This document is an internal analysis by the Higress project. It is not an
+independent audit, certification, or attestation. It gives adopters and CNCF
+reviewers an initial view of security boundaries, practices, and known gaps.
+
+## Security Functions and Features
+
+### Critical
+
+- xDS configuration generation, transport, validation, and last-known-good
+  behavior between controller/discovery and gateways.
+- TLS termination/origination, SDS secret delivery, certificate issuance and
+  rotation paths, and private-key access.
+- Kubernetes RBAC, ServiceAccounts, token reviews, subject-access reviews, and
+  admission/configuration validation.
+- HTTP/TCP parsing, routing, upstream selection, and request/response mutation.
+- Plugin loading and Wasm sandbox boundary; native Go/C++ filters share the
+  gateway process trust boundary.
+- Release workflows, container/plugin registries, dependency inputs, and
+  published artifacts.
+
+### Security Relevant
+
+- Authentication and authorization plugins (JWT, OIDC, key, HMAC, basic auth),
+  WAF, rate limiting, request blocking, and data masking.
+- Pod/container security contexts, host networking, privileged mode, RBAC
+  toggles, network exposure, and admin/debug endpoints.
+- Access, audit-style, metrics, and trace output, which may contain sensitive
+  request metadata depending on operator configuration.
+- External service registries, Redis, certificate issuers, identity providers,
+  OCI registries, and AI/model providers.
+
+### Threat Model
+
+This project-authored model uses the actors, assets, flows, and boundaries above.
+Priority reflects generic impact for a shared production gateway; adopters must
+adjust it for their tenancy model and data classification.
+
+| ID | Priority | Threat scenario | Current mitigation and residual risk |
+| --- | --- | --- | --- |
+| HG-TM-01 | High | A principal with excessive Kubernetes permissions creates or changes routes, policies, Secrets, or plugins to hijack traffic or bypass controls. | Kubernetes authentication, RBAC, API validation, namespace scoping where configured, and review/GitOps practices reduce exposure. Cluster administrators remain trusted, and the controller currently has broad cluster-wide permissions. |
+| HG-TM-02 | High | A compromised controller, gateway ServiceAccount, or ClusterRoleBinding exposes TLS keys or upstream credentials. | Secrets are delivered through Kubernetes APIs and SDS rather than embedded in images. Gateway and controller roles are separate, but secret access and several controller rules remain broad and require minimization. |
+| HG-TM-03 | High | A malicious or compromised plugin/image executes code, exfiltrates traffic, or alters policy. | Plugin installation is explicit and Wasm supplies a sandbox boundary. Native filters share the gateway process; release/plugin artifacts lack project-wide signature, SBOM, and provenance guarantees. |
+| HG-TM-04 | High | Control-plane or xDS/SDS channel compromise injects malicious configuration or secret material, or prevents updates. | Envoy validates delivered resources and can retain last accepted configuration. Operators must protect control-plane identities, endpoints, network paths, and Kubernetes access; transport and deployment assumptions require a dedicated hardening guide. |
+| HG-TM-05 | High | Hostile downstream traffic exploits an Envoy/filter parser defect or exhausts connections, memory, CPU, sockets, or upstream capacity. | Envoy validation, resource limits, timeouts, rate-limit/circuit-breaker features, probes, and multiple replicas can limit impact. Safe values are deployment-specific and timely Envoy/Higress patching remains essential. |
+| HG-TM-06 | High | A tenant accidentally or deliberately attaches a route or policy to another tenant's gateway and exposes or disrupts traffic. | Kubernetes RBAC, namespace separation, Gateway API attachment controls, and review can restrict authors. Higress does not make a hostile multi-tenant cluster safe when administrators grant overlapping write privileges. |
+| HG-TM-07 | High | Requests, AI prompts, credentials, or responses are disclosed to an external registry, plugin, observability backend, identity service, or model provider. | Integrations require operator configuration and can be restricted through credentials and network policy. Operators remain responsible for egress allowlists, provider contracts, log redaction, residency, and data-retention controls. |
+| HG-TM-08 | Medium | Logs, metrics, traces, admin/debug endpoints, or configuration dumps expose credentials or sensitive request metadata. | Admin interfaces are not intended as public endpoints and telemetry is configurable. Access control, redaction, retention, and exposure are deployment responsibilities; unsafe logging or endpoint exposure remains possible. |
+| HG-TM-09 | High | Certificate expiration, issuer compromise, or unauthorized Secret replacement causes outage or impersonation. | SDS and automatic HTTPS support dynamic certificate updates and renewal. Operators must secure issuers, monitor expiry/renewal, test emergency rotation, and control Secret writers. |
+| HG-TM-10 | High | A source-control, dependency, GitHub Actions, registry, or maintainer-account compromise produces malicious release artifacts. | Public review, CI tests, license checks, CodeQL, pinned dependency/submodule inputs, and GitHub release workflows provide layers. Missing universal immutable action pinning, release SBOMs, signatures, provenance, and documented repository access controls leave material residual risk. |
+
+The model should be reviewed after material architecture, privilege, plugin,
+release-pipeline, or trust-boundary changes. The project does not yet enforce a
+review cadence or require a named security reviewer, which is itself a process
+gap.
+
+## Project Compliance
+
+The open-source project does not claim PCI-DSS, SOC 2, ISO 27001, GDPR, or
+other regulatory certification. Deployers are responsible for assessing their
+configuration and operational environment. Source is Apache-2.0 and pull
+requests run license header and dependency-license checks.
+
+## Secure Development Practices
+
+Pull requests are publicly reviewed and run build/unit tests with Go race
+detection, Gateway API and Higress conformance tests, plugin tests, and license
+checks. CodeQL is scheduled weekly; it is not currently a pull-request gate.
+The configured `golangci-lint` execution is commented out because of existing
+findings. Release tags trigger image and CLI/CRD artifact builds. Dependency
+inputs are versioned, but release artifacts do not currently have a
+project-generated SBOM, signature, or SLSA provenance. Not all workflow actions
+are pinned to immutable commits. The public repository does not prove a
+required reviewer count, signed-commit requirement, organization-wide 2FA, or
+branch-protection configuration; those controls require separate repository-
+settings evidence.
+
+Ordinary project-team communication uses GitHub issues, pull requests,
+discussions, mailing, localized community channels, and Discord. Inbound users
+use the same public channels. Every vulnerability report must be submitted to
+both GitHub Private Security Advisories and the Alibaba Security Response
+Center, as documented in `SECURITY.md`. The Security Response Team correlates
+the two private records.
+Releases, the project website, and the WeChat Official Account are outbound
+channels. [`COMMUNITY.md`](https://github.com/higress-group/higress/blob/main/COMMUNITY.md)
+is the authoritative inventory of public, subproject, and narrowly scoped
+non-public channels.
+
+Higress operates in the Kubernetes networking and cloud-native gateway
+ecosystem. It implements Ingress and Gateway API and builds on Envoy, Istio,
+OCI, Prometheus/OpenTelemetry conventions, and optional service registries.
+
+## Security Issue Resolution
+
+[`SECURITY.md`](https://github.com/higress-group/higress/blob/main/SECURITY.md)
+prohibits public vulnerability reports and
+requires reporters to submit the same substantive report through both GitHub
+Private Security Advisories and the Alibaba Security Response Center. The named
+Security Response Team is the current maintainer list.
+For each case it assigns a triage coordinator, fix lead, independent reviewer
+and release lead, and disclosure lead, with at least two unconflicted members.
+The policy documents conflicts and escalation. Its targets are acknowledgement
+within three business days and triage within 14 days, followed by private fix
+development, coordinated disclosure (typically within 90 days), a GitHub
+Security Advisory, and a CVE request where appropriate.
+
+An operational security incident in an adopter environment remains the
+adopter's responsibility. The project handles defects in project code and
+artifacts. For confirmed project vulnerabilities, maintainers triage impact,
+develop and release a fix, notify affected users through a GitHub Security
+Advisory and release information, and coordinate timing with the reporter.
+
+## Appendix
+
+### Known Gaps
+
+- OpenSSF Passing is not complete. Outstanding areas include compiler warning
+  enforcement, static-analysis alert remediation, and dynamic analysis.
+- There are unresolved critical/high CodeQL alerts requiring maintainer access,
+  triage, and either fixes or documented upstream/vendor dispositions.
+- Release SBOMs, signatures, and verifiable build provenance are absent.
+- The controller's ClusterRole is broad and its default container security
+  context is empty. Gateway non-root defaults depend on Kubernetes/platform
+  capability; legacy fallback adds `NET_BIND_SERVICE` and allows escalation.
+- No dedicated fuzzing/DAST program or automated upgrade/downgrade matrix is
+  documented.
+- This threat model is project-authored, has not been independently validated,
+  and is not yet backed by a published data-flow diagram with explicit trust
+  boundaries or an independent security audit.
+- Requiring every reporter to duplicate the report in the vendor-operated
+  Alibaba Security Response Center creates a vendor-neutrality concern that
+  requires CNCF review or a future neutral replacement plan.
+
+### Known Issues Over Time
+
+Published project advisories are available from the repository's
+[Security Advisories](https://github.com/higress-group/higress/security/advisories)
+page. This assessment does not claim that the absence of a public advisory for
+a period means no vulnerability existed. The project has not published an
+aggregate vulnerability history or mean-time-to-remediation report.
+
+### OpenSSF Best Practices
+
+The [Higress OpenSSF entry](https://www.bestpractices.dev/projects/12667) is at
+96% of the Passing badge as of this assessment. Seven criteria remain
+unanswered or unmet: compiler-warning enforcement, strict-warning enforcement,
+warning remediation, static-analysis remediation, static-analysis frequency,
+dynamic analysis, and enabling assertions or equivalent dynamic-analysis
+checks. Passing requires evidence and implementation for all seven, not merely
+updating the questionnaire.
+
+### Example Use Cases
+
+1. A platform team exposes Kubernetes services through Gateway API with TLS,
+   JWT authentication, rate limiting, and Prometheus metrics.
+2. An AI platform routes requests across model providers while applying token
+   quotas, content policy, and request/response observability.
+3. A microservice platform discovers Nacos/Consul services and exposes them
+   through stable API routes without reloading the data plane.
+
+### Related Projects and Vendors
+
+Envoy supplies the proxy foundation; Istio supplies xDS/control-plane building
+blocks; Kubernetes Gateway API and Ingress supply standard configuration APIs.
+Kong, Apache APISIX, Envoy Gateway, Traefik, and ingress controllers address
+overlapping gateway use cases with different APIs, extension models, and
+operational tradeoffs. Commercial products may distribute or manage Higress,
+but they are outside this open-source security assessment.