Platform Mesh

Platform Mesh's components are continuously patched and released on their active version lines, older umbrella versions remain available as OCM components in ghcr.io/platform-mesh, and breaking changes between umbrella releases are documented per-PR with 🔥 markers in the platform-mesh/ocm release notes.

Repositories on GitHub, GitHub provides an issue tracker.

No vulnerabilities reported in the last 12 months.

Document on the project's website: https://platform-mesh.io/main/concepts/security/.

Documented as part of the contributing guide: https://github.com/platform-mesh/.github/blob/main/CONTRIBUTING.md.

Go components enforce coding style via golangci-lint and gofmt in CI, with failing checks blocking merge.

Platform Mesh's Go components build with CGO_ENABLED=0, producing statically-linked native binaries via the Go toolchain, which does not consume CC, CFLAGS, CXX, CXXFLAGS, or LDFLAGS. There is no C/C++ compilation step where these variables would apply, and the criterion's rationale (ASAN, distro hardening compiler flags) is specific to C/C++ toolchains. TypeScript components produce no native binaries.

Platform Mesh has no installation system. There is no make install, no install -s, and no post-build stripping step. Go components are compiled into container images and the resulting binary is the shipped artifact. The C/C++ debug-info flags the criterion references do not apply since no C/C++ code is compiled.

Platform Mesh does not use recursive subdirectory builds. Go components are built with go build, which resolves dependencies through the module graph. TypeScript components are built with npm/Node tooling, which resolves dependencies through the package graph. Neither uses recursive Make-style subdirectory builds, so the criterion's concern about cross-directory dependencies does not apply.

Platform Mesh is distributed as Helm charts and OCI container images published to ghcr.io/platform-mesh, both standard Kubernetes conventions. Helm provides helm install and helm uninstall for lifecycle management. The project also publishes OCM components for users of the Open Component Model.

Platform Mesh installs via Helm into a Kubernetes cluster, not onto a POSIX filesystem. The install location is selected through Helm conventions (--namespace, --kube-context, values.yaml) rather than DESTDIR or similar POSIX variables, which do not apply to Kubernetes deployments.

https://platform-mesh.io/main/how-to-guides/set-up-platform-mesh-locally.html describes how to set up a local environment that can be used for development.

Dependencies are listed in standard machine-readable formats: go.mod and go.sum for Go components, package.json with lock files for TypeScript components, Chart.yaml for Helm charts, and Dockerfile for container base images.

Example URL: https://github.com/platform-mesh/account-operator/blob/main/go.mod

The organization runs Renovate for automated dependency updates across all repositories, GitHub Dependabot security alerts on each repo, and OpenSSF Scorecard checks on a schedule. Vulnerabilities flagged by these tools are addressed through PRs.

Reused components are managed through standard package managers: go.mod for Go, package.json for TypeScript, Chart.yaml for Helm, and Dockerfile for base images. Renovate automates version bumps across the organization, so updating a vulnerable dependency is a normal PR.

All Go code is linted with golangci-lint on every commit. staticcheck is enabled (it is included by default in golangci-lint's standard linter set), and its SA1019 check flags any use of deprecated functions, methods, fields, or packages. Pull requests introducing deprecated API usage are blocked from merging.

Each repository runs an automated CI pipeline on every push and pull request via GitHub Actions, executing unit and integration tests. Results are reported on the PR and in the Actions tab, and failing checks block merges through branch protection rules.

Example URL: https://github.com/platform-mesh/account-operator/actions

Per ADR 005, repositories enforce 80/80/80 test coverage thresholds (file, package, total) as a hard gate in CI. The shared job-golang-test-source.yml workflow runs go test with -coverpkg=./... and then go-test-coverage against the configured thresholds, failing the job if any threshold is not met. Bug fixes that touch previously-untested code paths cannot merge without accompanying tests, which in practice ensures regression tests are added alongside bug fixes.

URLs:

• https://github.com/platform-mesh/architecture/blob/main/adr/005-default-test-coverage-thresholds.md
• https://github.com/platform-mesh/.github/blob/main/.github/workflows/job-golang-test-source.yml

Per ADR 005, repositories enforce 80/80/80 test coverage thresholds (file, package, total) as a hard gate in CI. The shared job-golang-test-source.yml workflow runs go test with -coverpkg=./... and then go-test-coverage against the configured thresholds, failing the job if any threshold is not met. Individual repos may set lower thresholds where justified (e.g., early-stage prototypes), but the default and intended baseline is 80%.

ADR 005: https://github.com/platform-mesh/architecture/blob/main/adr/005-default-test-coverage-thresholds.md

Document in the CONTRIBUTING.md file in the .github repository: https://github.com/platform-mesh/.github/blob/main/CONTRIBUTING.md.

All contributors are required and expected to read https://github.com/platform-mesh/.github/blob/main/CONTRIBUTING.md before submitting a change proposal. GitHub automatically reminds new contributors and those who didn't contribute for some time about this file upon submitting a Pull Request.

Go components run golangci-lint in CI with strict configuration, and go vet warnings are treated as errors. CI fails on lint or compiler warnings, blocking merge.

Platform Mesh applies standard secure design principles across its components: least privilege through Kubernetes RBAC and fine-grained authorization via OpenFGA (ReBAC), defense in depth with an authorization webhook (rebac-authz-webhook) layered on top of Kubernetes API server auth, secure defaults in Helm charts, fail-safe defaults in the security-operator, separation of concerns across dedicated operators (account, security, extension-manager, platform-mesh), and authentication delegated to Keycloak with OIDC. Secrets are managed via Kubernetes secrets and cert-manager handles TLS certificates.

Platform Mesh relies on standard, modern cryptographic implementations from its dependencies: Go's standard crypto library, Kubernetes API server TLS, cert-manager for certificate issuance, Keycloak for OIDC token signing, and OpenFGA for authorization. None of these default to weak algorithms like SHA-1 or CBC-mode SSH. The project does not implement custom cryptography.

Cryptographic algorithm choice is delegated to the underlying components (Go's crypto/tls, Kubernetes API server, cert-manager, Keycloak, OpenFGA), all of which support multiple algorithms and allow operators to configure cipher suites, signing algorithms, and hash functions through their respective configuration.

Authentication credentials are handled by an external identity provider (Keycloak via OIDC), not stored by Platform Mesh itself. Where the project does handle secrets (such as service account tokens or TLS keys), they are stored in Kubernetes Secrets, separate from ConfigMaps, application configuration, and logs. Secrets are mounted into pods at runtime, so users can rotate them by updating the Secret without rebuilding any component.

Network communication between components uses TLS, and the project does not enable insecure protocols by default.

TLS is provided by the underlying components (Kubernetes API server, Keycloak, Go's crypto/tls), all of which support TLS 1.2 and 1.3 by default.

TLS certificate verification is enabled by default through the underlying components (Kubernetes client-go, Go's crypto/tls, Keycloak). The project does not disable verification in its default configuration.

The project relies on standard HTTP and TLS client libraries (Go's net/http and crypto/tls, Kubernetes client-go) which perform certificate verification as part of the TLS handshake, before any application data including headers is sent.

Container images are signed with cosign keyless via Sigstore (cosign sign after pushing to ghcr.io/platform-mesh). Signing uses GitHub Actions OIDC, so no long-lived private key exists on the distribution site. Release tags are also GPG-signed.

Release tags are cryptographically signed and show GitHub's verified signature badge.

Inputs from untrusted sources are validated at multiple layers. Kubernetes CRDs define OpenAPI v3 schemas that the API server enforces on every resource (types, required fields, enums, patterns). The GraphQL gateway validates queries against a generated schema derived from those CRDs. Authentication tokens are validated by Keycloak (OIDC), and authorization decisions go through the rebac-authz-webhook backed by OpenFGA. HTTP handlers in the Go services reject malformed requests rather than coercing them.

Container images are built with statically-linked Go binaries (CGO_ENABLED=0) on minimal bases, reducing attack surface. Helm charts apply pod-level and container-level securityContext through a shared library template (common.pod.securityContext / common.container.securityContext). TLS certificates for webhooks are managed by cert-manager (charts use cert-manager.io/inject-ca-from annotations and mount cert-manager-issued certs into pods). Authorization is enforced via the rebac-authz-webhook backed by OpenFGA, with Kubernetes RBAC underneath. Dependencies are monitored via Renovate and Dependabot, and build provenance is signed via cosign.

Example URL: <URL: https://github.com/platform-mesh/helm-charts/blob/main/charts/account-operator/templates/deployment.yaml>

Platform Mesh's security architecture is documented at https://platform-mesh.io/release-0.3/concepts/security/, covering trust boundaries (per-organization Keycloak realms and OpenFGA stores aligned with the account hierarchy, kcp as the central enforcement point, distinct client entry paths via UI/kubectl/MCP) and secure design principles (separation of authentication and authorization as independent subsystems, layered authorizer chain with RBAC followed by ReBAC via OpenFGA, per-tenant isolation, standard Kubernetes extension points). The Authentication and Authorization sub-pages provide design-level detail, and the document references the kcp Security Self-Assessment for the underlying control plane foundations.

URL: https://platform-mesh.io/main/concepts/security/

Memory-unsafe languages are not used.