Update SECURITY.md to use GitHub for security issue reporting#308
Merged
Conversation
WalkthroughReplaces the SECURITY.md placeholder with a defined security policy adding sections for reporting vulnerabilities (GitHub advisories link and triage), coordinated vulnerability disclosure guidance, a policy on scanner report acceptance, and a Security Advisories section describing GitHub-managed advisories and CVE handling. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Please see the documentation for more information. Example: reviews:
pre_merge_checks:
custom_checks:
- name: "Undocumented Breaking Changes"
mode: "warning"
instructions: |
Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. Comment |
mjudeikis
previously approved these changes
Sep 15, 2025
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
SECURITY.md (5)
5-7: Tighten wording, add SLA, and avoid public issue leaks.Recommend clear steps, explicit ack/triage timelines, and removing the unspecified “via email” bit.
-kube-bind uses GitHub to allow submission of private security reports. Please report any security finding via -[this link](https://github.com/kube-bind/kube-bind/security/advisories/new). -Maintainers will triage your report as soon as possible and get in touch with you via your report or via email in case they have more questions. +Use GitHub Security Advisories (GHSA) to privately report vulnerabilities: +[Report a vulnerability](https://github.com/kube-bind/kube-bind/security/advisories/new). +Please do not open public issues or PRs for security reports. +Maintainers acknowledge within 3 business days and provide a triage update within 14 days. +We will communicate with you in the advisory thread.Follow-up:
- If you have a dedicated security email/alias, add it; otherwise the above keeps one channel.
9-11: Prefer “CVD” phrasing and add a brief safe-harbor statement.This reduces ambiguity and sets researcher expectations.
-As a security researcher, please report vulnerabilities to kube-bind in a [coordinated vulnerability disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) -fashion. In return, maintainers pledge to engage in good faith and collaborate with security researchers to address and publish vulnerabilities found in kube-bind as soon as possible. +As a security researcher, please follow a coordinated vulnerability disclosure (CVD) process ([guidance](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). +In return, maintainers will collaborate in good faith to remediate and publish fixes promptly. +Safe harbor: we will not pursue or support legal action for good‑faith security research that adheres to this policy and avoids privacy violations, data exfiltration, or service disruption.
12-12: Clarify dependency‑scanner acceptance criteria.Current text sounds dismissive; suggest actionable evidence requirements.
-Please understand that the maintainers also do not accept results of dependency scanners without proof that the detected CVE / vulnerability can be used against kube-bind. +We do not accept bulk dependency‑scanner submissions. For dependency CVEs, include evidence of exploitability in kube‑bind +(for example: a reachable call path, affected configuration, or a minimal PoC) so we can prioritize appropriately.
16-17: Expand on GHSA/CVE flow and credit.Make it explicit that CVEs are requested via GitHub and that reporters get credit on disclosure.
-Advisories are managed through GitHub. Public disclosure of vulnerabilities happens through GitHub. -Please visit [Security Advisories](https://github.com/kube-bind/kube-bind/security/advisories) to review security bulletins published by the maintainers. +Advisories are managed through GitHub Security Advisories. Where applicable, we request CVE IDs via GitHub’s CNA during the advisory process and credit reporters upon release. +Please visit [Security Advisories](https://github.com/kube-bind/kube-bind/security/advisories) to review published bulletins.Follow-up:
- Confirm you plan to use GitHub’s CNA for CVE assignment; if not, tweak wording accordingly.
3-18: Optional additions to strengthen the policy.Non-blocking polish that improves clarity and expectations.
- Add “Supported versions and backport policy” (which branches get fixes; how long).
- State embargo expectations (e.g., coordinated disclosure target like 90 days, adjustable by severity/complexity).
- Note what’s out of scope (DDoS, physical attacks, social engineering, automated scanner spam).
- If you have a PGP key for off-GitHub comms, link it; otherwise GHSA only is fine.
On-behalf-of: SAP <marvin.beckers@sap.com> Signed-off-by: Marvin Beckers <marvin@kubermatic.com>
embik
force-pushed
the
security-process
branch
from
9062060 to
70588c7
Compare
Member
Author
|
Incorporated some of the nits in the AI review. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
SECURITY.md (6)
5-7: Set explicit triage SLAs and tighten phrasing.Add acknowledgment/assessment timelines to reduce ambiguity.
- k ube-bind uses GitHub to allow submission of private security reports. Please report any security finding via -[this link](https://github.com/kube-bind/kube-bind/security/advisories/new). -Maintainers will triage your report as soon as possible and get in touch with you via your report in case they have more questions. + kube-bind uses GitHub Private Vulnerability Reporting for confidential submissions. Please report any security finding via + [this link](https://github.com/kube-bind/kube-bind/security/advisories/new). + Maintainers acknowledge receipt within 2 business days and provide an initial assessment within 7 business days. Follow‑ups will occur in the advisory thread.
9-13: Strengthen CVD timelines and safe‑harbor language.Make embargo and researcher protections explicit.
-As a security researcher, please report vulnerabilities to kube-bind in a [coordinated vulnerability disclosure (CVD)](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) -fashion. - -In return, maintainers pledge to engage in good faith and collaborate with security researchers to address and publish vulnerabilities found in kube-bind as soon as possible. We will not pursue or support legal action for good‑faith security research that adheres to this policy and avoids privacy violations, data exfiltration, or service disruption. +As a security researcher, please follow [coordinated vulnerability disclosure (CVD)](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html). +Do not publicly disclose details until we publish an advisory or 90 days have elapsed, unless mutually agreed otherwise. + +Safe Harbor: We will not pursue or support legal action for good‑faith security research that adheres to this policy. Avoid privacy violations, data exfiltration, service disruption, and social engineering. Keep testing within your own environments and stop if you encounter user data or sensitive content.
14-15: Reword scanner policy to “evidence of impact,” not “proof of exploit.”Prevents discouraging valid reports while filtering noise.
-Please understand that the maintainers also do not accept results of dependency scanners without proof that the detected CVE / vulnerability can be used against kube-bind. +To keep triage actionable, reports based solely on automated dependency scans may be closed as informational unless they include evidence that the finding impacts kube-bind (e.g., a reachable vulnerable code path, misconfiguration leading to impact, or a minimal proof‑of‑concept).
16-18: Expand advisory contents and pre‑disclosure notes.Sets reporter/user expectations and helps downstreams.
-## Security Advisories - -Advisories are managed through GitHub Security Advisories. Where applicable, we request CVE IDs via GitHub’s CNA during the advisory process and credit reporters upon release. Please visit [Security Advisories](https://github.com/kube-bind/kube-bind/security/advisories) to review security bulletins published by the maintainers. +## Security Advisories + +Advisories are managed through GitHub Security Advisories (GHSA). Where applicable, we request CVE IDs via GitHub’s CVE Numbering Authority (CNA) and credit reporters upon release. + +Each advisory will include: +- Summary, impact, and severity (CVSS v3.x score and vector). +- Affected and fixed versions, remediation steps, and any workarounds. +- Credits (opt‑in for reporter attribution). +- Pre‑disclosure coordination with trusted maintainers/distributors under embargo when necessary. + +See published advisories at [Security Advisories](https://github.com/kube-bind/kube-bind/security/advisories).
3-3: Add Scope and Supported Versions sections (helps triage/backporting).Clarifies what’s in scope and which release lines get patches.
## Reporting a Vulnerability + +## Scope + +This policy applies to all code in this repository. Third‑party services and dependencies are out of scope except where kube-bind’s code enables exploitation. + +Out of scope examples (non‑exhaustive): +- Issues without security impact (general bugs, style, or performance only). +- Purely theoretical CVEs in unused or dev‑only dependencies. +- Findings that require physical access or a compromised admin to exploit. + +## Supported Versions + +Security fixes are released for actively supported release lines. Each advisory states affected versions and the first patched version(s); maintainers may backport at their discretion based on severity and feasibility.
18-18: Nit: first use of “CNA.”Spell out “CVE Numbering Authority (CNA)” on first mention for clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
SECURITY.md(1 hunks)
🔇 Additional comments (1)
SECURITY.md (1)
3-18: Good move: adopt GitHub Private Vulnerability Reporting and GHSA.Clearer process, CVD guidance, and CVE handling read well.
Please ensure “Private vulnerability reporting” is enabled in repo settings and that maintainers with triage access are assigned to receive notifications.
mjudeikis
approved these changes
Sep 15, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
I would like to propose using GitHub issue reporting for handling security vulnerability disclosure. We will be able to both manage our own disclosures and accept security reports through GitHub, which will also allow us to request CVEs when necessary.
What Type of PR Is This?
/kind documentation
Related Issue(s)
Fixes #
Release Notes
Summary by CodeRabbit