task: Scorecard — evaluate fuzz testing for Go services (Fuzzing)

[mirzakopic]

Description

OpenSSF Scorecard reports Fuzzing: 0/10 on most platform-mesh repos. Scorecard expects either:

• Native Go fuzz tests (func FuzzXxx(f *testing.F)) for Go projects, OR
• An OSS-Fuzz integration for the project, OR
• ClusterFuzzLite or similar.

This is lower priority than Token-Permissions / Pinned-Dependencies and should be scoped down during refinement — fuzzing makes the most sense for code that parses untrusted input (CRD validation, GraphQL parsing, webhook admission).

Candidates worth fuzzing

Go services with parsing / admission / validation logic:

• golang-commons — utility library; fuzz any parsers/decoders
• kubernetes-graphql-gateway — GraphQL parsing of arbitrary CRD schemas; high-value target
• iam-service — auth flows; fuzz token/header parsing
• account-operator — controller; fuzz CRD validation if any custom logic
• extension-manager-operator — same as above
• subroutines — utility library; fuzz any parsers
• platform-mesh-operator — controller
• rebac-authz-webhook — admission webhook; fuzz request bodies

Skip (not meaningful)

• UI repos (portal, portal-ui-lib, iam-ui) — Scorecard's Fuzzing check assumes Go fuzz; not applicable here.
• Image / config repos (custom-images, upstream-images, helm-charts).

Steps

1. Triage the list above — for each repo, identify the highest-value parse/validate boundary.
2. Add a Fuzz<Function> test next to the existing unit tests (Go 1.18+ native fuzzing).
3. Optionally: open an OSS-Fuzz integration PR for the highest-value repos (graphql-gateway, rebac-authz-webhook).

Objectives

• At least 3 high-value repos have native Go fuzz tests.
• Decision documented for each candidate: fuzz / OSS-Fuzz / skip-with-reason.

Demo Required

None

Demo Steps

No response

---

Epic: #278