We're always looking for ways to improve our security posture and taking security vulnerabilities seriously.
CRA stewardship: This project is supported under the Linux Foundation CRA stewardship framework, as described at https://www.linuxfoundation.org/security. Security vulnerabilities should be reported through the mechanisms described below, which we will coordinate with our CRA steward. For actively exploited vulnerabilities and severe incidents that may require CRA escalation, please use the project's emergency security reporting mechanisms as appropriate.
To report a vulnerability, send an email to the official k8gb maintainers list cncf-k8gb-maintainers@lists.cncf.io, or report it privately on GitHub with Report a vulnerability on the repository's Security tab.
If you have evidence that the vulnerability is being actively exploited, say so at the top of your report. Maintainers prioritize those reports and escalate them to the Linux Foundation CRA steward as described in CONTRIBUTING.md.
Please make sure to provide the following information:
- vulnerability description
- version of the k8gb package
- version of the k8s cluster
- steps to reproduce the vulnerability
The standard response time from k8gb project maintainers for a vulnerability report is less than 14 days.
Once k8gb project maintainers have confirmed the relevance of the report, a draft security advisory will be created on Github. Please provide Github username to k8gb project maintainers if you wish to be invited to participate in advisory discussions. You can also request to be updated about advisory discussions directly via email.
If the vulnerability is accepted, you'll be informed about the determined timeline for developing a patch, public disclosure, and patch release. You are expected to participate in the discussion of the timeline and respect the agreed dates for public disclosure.
Once a vulnerability is publicly disclosed, its advisory is published on the repository's security advisories page.
The published Level 2 results include controls that need human review. The following evidence accompanies the automated results; it does not constitute an independent security audit or a badge award.
The privileged-context finding in the 2026-10-31 scan concerns
helm_sign_oci.yaml. Its automatic trigger
follows a successful Helm Publish workflow; it also permits manual dispatch.
Helm Publish runs on published releases or
manual dispatch, with no pull-request trigger. The signing workflow uses a GitHub
hosted runner, checks out inputs.tag || github.ref, and does not select a pull
request head or the triggering workflow's head SHA. Manual tag selection and
release publishing are trusted maintainer actions.
The signing job has contents: read, packages: write, and id-token: write.
It fetches chart archives from this repository's gh-pages branch, pushes them to
GHCR, and signs them with GitHub OIDC. It does not restore an Actions cache or
download artifacts from a pull-request workflow. Writers to gh-pages, release
publishing credentials, and the pinned third-party actions are part of this trust
boundary. The job uses Harden Runner with an outbound endpoint allowlist.
Changes to the workflow triggers, checkout references, chart sources, caching, or runner type require this evidence to be revisited. Release signing improvements are tracked separately in #2568.
| Interface | Documentation and contract |
|---|---|
| Kubernetes configuration and watched resources | API types, CRD schemas, resource references, and dynamic zones |
| DNS clients and inter-cluster health discovery | Component data flows, DNS exposure, strategies, and trust boundaries |
| Edge DNS providers and credentials | Provider guides, including Route53, Google Cloud DNS, and Infoblox |
| Metrics, health endpoints, and optional tracing | Metrics, tracing, and ports and access assumptions |
| Installation and runtime configuration | Helm chart documentation and values schema |
The architecture map connects these interfaces to the code. k8gb configures DNS and does not proxy application traffic; the referenced Ingress, Service, Gateway API route, or Istio resource handles application traffic.
The self-assessment, reviewed in #2574, covers intended use, components, actors and actions, trust boundaries, security goals and non-goals, development practices, and vulnerability response. It records deployment and RBAC hardening gaps, tracked in #2587. The Security Insights assessment entry links this evidence and records its review date.
The public disclosure destination is the GitHub security advisories page, as specified in Published Advisories. The 2026-10-31 scan found no published advisories, so it could not infer this practice from advisory history. Private reporting and coordinated disclosure follow the process above.