CNCF published a guidance card on September 7, 2026, titled “Handling vulnerability reports: Recipe card,” targeting small and medium-sized open source projects that do not primarily focus on security. The material was prepared by Marina Moore of Edera, who is the co-chair of TAG Security, and Sherine Khoury of Red Hat, who is a lead of TAG Security.
The guide’s central idea is to reduce extra work for maintainers and users while preventing a security report from becoming a public discussion before the fix is ready. CNCF explains that a security vulnerability is a flaw that can be exploited to affect a system’s confidentiality, integrity, or availability, but not every software defect is exploitable or classified as a vulnerability.
Start with a Clear, Private Reporting Channel
The guidance recommends that README.md include a clear security section that is easy to find, with instructions placed directly in the file or a reference to a SECURITY.md file at the repository root. The goal is to direct researchers to a private path instead of publishing problem details in a public issue that everyone can read.
Reporting instructions should clarify several elements, including the threat model or the minimum requirements for considering a report a vulnerability, where to send it, the report format, the expected time before review, and the approximate time until disclosure. GitHub’s private vulnerability reporting mechanism or a private mailing list can be used. A bug bounty program is not mandatory for small and medium-sized projects if they do not have the capacity to operate one.
Verify the Nature of the Report Before Treating It as a Vulnerability
After the report arrives, the first step should be to determine whether it actually points to an exploitable vulnerability, a non-exploitable defect, a misunderstanding of expected behavior, or a documentation error. CNCF suggests discussing the report with its author and the appropriate experts in the project, while keeping the number of participants limited and requiring everyone to maintain confidentiality until the report becomes public.
Practical questions that can be asked include: Is a mitigation mechanism available to users? Could the flaw lead to a compromise, data leakage, or other malicious activity? Is the problem limited to the documentation? If it turns out that the report is not a vulnerability, its author can be directed to create a public issue, using appropriate release procedures to notify users when necessary.
In cases of uncertainty, the guidance indicates that advice can be requested from TAG Security and Compliance or CNCF staff, while keeping the report details out of public channels. Participants in the confidential embargo period should also be chosen carefully, involving only those who genuinely need to help resolve the issue, so that information does not leak to attackers before a correction is available.
Develop and Test the Fix Away from the Public
CNCF warns that publishing or discussing the patch in a public pull request may reveal the nature of the vulnerability before users have an opportunity to update. If GitHub’s private reporting mechanism is used, a private branch can be created from the report. Otherwise, the fix can be developed and reviewed through a private channel.
The fix must be tested, even if the usual continuous integration environment does not work with private branches. In that case, testing can be performed locally according to the maintainers’ judgment and the scope of the change. After confirming that the patch addresses the problem and that the tests are sufficient, the guidance recommends merging it quickly and involving enough maintainers in its creation and testing. Before the public release, the code should be reviewed again to ensure that the vulnerability has actually been closed.
Coordinate the Release with CVE Disclosure
Once the fix is complete, CNCF considers disclosure within 90 days of receiving the report a common practice. If the project has the resources, it can notify a private list of users in advance, but maintaining an up-to-date contact list is a burden that most small projects cannot handle.
Therefore, the recipe card suggests a simpler approach: make the release containing the fix available and announce the vulnerability at the same time, so users receive the fix when the issue is announced. This requires building a new release as soon as the fix is introduced, then publishing the CVE. If GitHub’s private mechanism is used, this can be done from the GitHub interface.
A CVE number must be assigned by a CNA, meaning a CVE Numbering Authority. GitHub is one such authority and can carry out the process, and the project and researcher can also communicate directly with one of the listed CNA authorities. The CVE severity is determined through a set of questions, and the project should work with the researcher to ensure that the answers are accurate and agree on the assigned score.
Why Does This Guidance Matter?
In practice, the card moves vulnerability management from an improvised reaction to an actionable process: a private channel, limited verification, an undisclosed fix, and then a coordinated release and disclosure. After the CVE is published, the information appears in OSV and other vulnerability databases, helping users’ scanning tools detect the need to update.
However, the recipe’s scope is clearly limited; it is intended for small and medium-sized projects that do not specialize in security, and it is not a substitute for a more complex program for high-risk or security-sensitive projects. CNCF also suggests considering the publication of a proof of concept after some time has passed since the fix became available, giving users an additional opportunity to update, while acknowledging that this may be difficult when private reporting is used.