docs(higress): add security self-assessment for incubation

[EndlessSeeker]

Summary

Adds the Higress project-maintained Security Self-Assessment at the canonical path used for CNCF incubation due diligence.

• Original: https://github.com/higress-group/community/blob/main/docs/cncf/security-self-assessment.md
• Follow-up source update: docs: clarify security assessment boundaries higress-group/community#2
• Follows the CNCF TAG Security self-assessment outline
• Documents actors, trust boundaries, security functions, threat scenarios, development practices, and known gaps
• OpenSSF Best Practices status: Passing

Review follow-up

The latest revision identifies the enforcement point for critical trust boundaries, distinguishes allowedRoutes.namespaces from ReferenceGrant, clarifies plugin scoping and last-known-good behavior, and states that golangci-lint is not an active CI control. The dual-reporting policy remains unchanged and will be handled separately by Higress maintainers as a governance question.

Scope

This is a project self-assessment, not an independent audit or joint assessment. The content is copied from the project-maintained version approved in higress-group/higress#4177 and updated in response to review feedback on this PR. The revision changes documentation only and does not alter runtime behavior.

Checklist

• DCO signed
• Added as projects/higress/security-assessment/self-assessment.md
• Source and public evidence links included
• Review feedback incorporated

Agent-assisted contribution

• Codex assisted with implementation analysis and documentation wording.
• Gate status: verified maintainer/administrator exception under the Higress agent-assisted contribution policy.
• PR: docs(higress): add security self-assessment for incubation #2268
• Authenticated GitHub login: EndlessSeeker.
• Canonical higress-group/higress role: admin.
• Actual PR author: EndlessSeeker.
• GH_TOKEN and GITHUB_TOKEN were unset for every identity, permission, and PR-author verification command.
• Bypass rationale: focused documentation clarification on an in-flight CNCF security-assessment review; no runtime behavior changes.
• The CNCF TOC PR template has no Higress verified-exception selector, so the status is recorded here.

[Santoshkumarpuppala]

This is the most security-mature of the self-assessments I've read in this batch, and I want to be specific about why: it ships an actual threat model with residual-risk columns, an actors/assets/trust-boundary table, and a Known Gaps section that volunteers the uncomfortable items (the commented-out linter, the broad controller ClusterRole, absent SBOM/signature/provenance, and the vendor-neutrality question around dual ASRC reporting). Flagging your own vendor-neutrality concern before a reviewer raises it is exactly the right instinct. Most of what follows is refinement, not a request to add missing sections.

I read it with one narrow lens: for each boundary the document claims, does it name the single server-side point that enforces it, and what would a negative test look like — a request that should be refused, and is. The threat model is strong on scenario and residual risk; where it's thinner is the line between what Higress itself refuses and what it delegates to Kubernetes RBAC or the operator's configuration. Several High rows resolve to "operator responsibility," which is often the honest answer for a gateway, but a reader can't always tell which half of the boundary is Higress's.

The row I'd start with is HG-TM-06 (cross-tenant route/policy attachment), since it's the one most readers will scrutinize for a shared gateway. The mitigation lists "Gateway API attachment controls" generically. Gateway API has named mechanisms for precisely this: a Gateway's allowedRoutes.namespaces selector decides which namespaces may attach Routes, and ReferenceGrant governs cross-namespace references to Secrets and backends. Those are the concrete points that refuse a Route in one namespace from binding a Gateway in another. Naming them — and saying whether Higress relies on the upstream Gateway API implementation or adds its own enforcement — would turn that row from "controls exist" into a testable statement: a Route from an unlisted namespace attaching to a protected Gateway, refused.

A few more, in rough priority:

1. Enforced-by-Higress vs delegated. It would help to mark, per critical boundary, whether enforcement is in Higress code, in Envoy, or in Kubernetes RBAC that the operator must configure. HG-TM-01, HG-TM-02, and HG-TM-06 all lean on "Kubernetes RBAC" as the mitigation — which is correct, but it means the boundary is only as good as the operator's RBAC, and that's worth stating as the explicit dependency rather than as a Higress control. The distinction matters most where the controller's own ClusterRole is broad (which Known Gaps already admits): a broad controller role widens what a compromised controller can do regardless of the operator's tenant RBAC.

2. The commented-out golangci-lint. Known Gaps notes it's disabled "because of existing findings." Worth calling this out slightly more sharply, because a disabled linter is a control that reads as present — it's in the CI config — while enforcing nothing. Either a tracked path to re-enabling it (even lint-new-code-only, so the baseline debt doesn't block it) or an explicit "not currently enforced" note would keep the secure-development section from overstating coverage. CodeQL plus the go vet gate are doing real work; the lint line is the one that currently claims more than it delivers.

3. Wasm plugin grants. The trust-boundary table says "plugins can still observe or modify traffic granted to them," which is the right framing. The follow-up a reader wants: what does the granting? Is there a capability/scoping model for what traffic or configuration a plugin may touch, or does a loaded plugin see all traffic on the routes it's attached to? HG-TM-03 treats plugin installation as the control point (explicit install), but once installed, the scope of a plugin's access is the residual question — and native filters, as you note, share the process outright.

4. Last-known-good and policy removal. HG-TM-04 frames "retain last accepted configuration" as an availability mitigation, which it is. There's a security corner worth a sentence: if the control plane is unavailable, does the removal or tightening of a policy (say, revoking an auth filter or narrowing a route) also fail to propagate, leaving a stale permissive config serving? Availability-preserving last-known-good and timely policy revocation can pull in opposite directions, and stating which wins under partition would close the question.

One process note, not a document issue: the dual-reporting requirement (GitHub Private Security Advisories plus Alibaba ASRC) that you've already flagged is the right thing to have surfaced. From a reporter's side, the coordinated-disclosure concern is simply that a reporter must file into a vendor-operated channel to reach the project at all; a neutral primary intake (GitHub PSA as the system of record, with ASRC correlated behind it) would resolve most of it without losing the vendor's response capacity. Sharing that only because it's the disclosure-process angle, and you've clearly already thought about it.

None of this is a finding — it's all "the document asserts a boundary and I'd like the text to name what enforces it, or the dependency it rests on." The threat model is a good base to be doing this against. Happy to be pushed back on any of it, particularly the Gateway API enforcement points, where your implementation details will be more current than my read of the spec.

[EndlessSeeker]

@Santoshkumarpuppala Thanks for the careful review. We have updated the assessment to name the enforcement point for the critical boundaries, distinguish allowedRoutes from ReferenceGrant, state the current golangci-lint status, clarify plugin scope, and document the stale-policy tradeoff in last-known-good behavior; the project-maintained source update is higress-group/community#2. We are handling the dual-reporting policy separately with project maintainers, since it needs a governance decision rather than a wording-only change.

[Santoshkumarpuppala]

Thanks — I've read the revision here and the source change that merged upstream. The HG-TM-06 rewrite is what I was asking for: it names allowedRoutes.namespaces and ReferenceGrant as two separate checks rather than one general control, and then says what each one refuses — a Route from an unselected namespace doesn't attach, and a cross-namespace reference without a matching grant is rejected. That last sentence is the part a reader can actually act on, because it's falsifiable.

The change I didn't ask for is the better one. HG-TM-03 now introduces matchRules and in the same paragraph says they scope intended execution but are not a security sandbox against a malicious installed plugin. Adding a mechanism to a threat model and disclaiming it in the same breath is the harder move, and it's what stops a reader assuming that scoping is isolation.

On dual reporting — treating it as a governance decision rather than a wording fix is the right call. A reporter needs to know which intake is authoritative before they send anything, and that isn't something a self-assessment can settle on its own.