The CNCF has published a concise “recipe” that formalises a lightweight vulnerability reporting workflow aimed at small‑to‑medium open‑source projects. It codifies the steps needed to expose a clear reporting channel, evaluate reports under embargo, and align a patch release with a public CVE, thereby giving engineers a repeatable process that limits accidental disclosure and operational noise.
Define a Public Reporting Path
Project maintainers should add a security section to the README.md that either contains the reporting instructions directly or points to a SECURITY.md file at the repository root. The file must state:
- What kinds of issues are accepted (the threat model and vulnerability bar).
- Where to send reports – for example a private GitHub vulnerability reporting endpoint or a dedicated email address.
- Required report format and any timelines for acknowledgement and disclosure.
- Whether a bug bounty is offered; the guidance notes that small projects may omit a bounty.
By making the path obvious, reporters are steered away from public issue trackers, reducing the risk of premature exposure.
Assess and Embargo Reports
When a report arrives, the first task is to confirm whether it is a true vulnerability or a non‑exploitable bug. This assessment should be done in a confined discussion with the reporter and a minimal set of trusted maintainers. All participants must agree to keep the details confidential until a public disclosure is scheduled.
If the report is deemed non‑vulnerable, the reporter can be redirected to file a normal public issue. If uncertainty remains, the guidance suggests reaching out to CNCF TAG Security and Compliance or CNCF staff for advice, again keeping the content off public channels.
Key considerations during the embargo include:
- Is there a mitigation that users can apply immediately?
- Does the flaw enable data leakage, code execution, or other compromise?
- Is the problem merely a documentation mismatch?
Only those who need to contribute to the fix should be added to the embargo list, mirroring the “few cooks in the kitchen” principle.
Patch Privately and Coordinate Disclosure
Once a fix is ready, it must remain out of public view until the coordinated disclosure date. For repositories that support GitHub’s private vulnerability reporting, maintainers can create a private branch that contains the patch. In environments without that feature, the patch should be developed and reviewed on a private channel.
After the patch is merged, the project should issue a public CVE and publish the release notes simultaneously, giving users a clear upgrade path before the vulnerability details become public.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Adopting this minimal process gives engineers a repeatable way to handle security reports without the overhead of a full‑scale disclosure program. It reduces the chance of accidental public exposure, aligns patch delivery with CVE timelines, and provides a clear communication channel for reporters. Teams should audit their repositories for a missing SECURITY.md, establish a private reporting address, and practice the embargo workflow on a test report to ensure the steps are understood before a real incident occurs.
