Posted on September 7, 2026 by Marina Moore (Edera, TAG Security co-chair), Sherine Khoury (Red Hat, TAG Security lead) Set the Station: Define a clear reporting path in your README. md so reporters know where to deliver ingredients. Taste Test First: Determine if a report is a real vulnerability or just a regular bug before starting the fire. Plate for Everyone: Coordinate the patch release with a public CVE disclosure to serve your users safely. This recipe card provides guidance for handling security vulnerabilities in open source projects.
A security vulnerability is a flaw in a program that can be exploited by an attacker to compromise the confidentiality, integrity, or availability of a system. Security vulnerabilities often stem from bugs in a program, but not all bugs can be exploited. While many bugs appear in the kitchen, not all of them have the potential to compromise the confidentiality or integrity of your menu. Spoiled ingredients can cause a lot of damage for patrons, in the same way that vulnerabilities can cause a lot of damage for end-users. So many users track & prioritize vulnerabilities to minimize impact.
This process can generate a lot of work, so in this guide we aim to minimize the extra work needed for both project maintainers and end-users. For more information about handling vulnerabilities, especially for larger projects, see the vulnerability disclosure guide from the OpenSSF . As a head chef, you want to hear from your customers when something is wrong, but you want them to reach out to you directly with the information, instead of posting it as a public review. Similarly, as a maintainer, you don’t want vulnerabilities to be reported to you through a plain bug issue, publicly visible to the world.
Make it as obvious and as easy as possible for people to find that path by including a security section directly in the README. This section can directly include the instructions, or point to the SECURITY. md file, which should also be at the root of the repository. The instructions for reporting a vulnerability should include: Once you discover a vulnerability or have one reported, you will want to respond to the vulnerability without talking publicly about the vulnerability. This involves an “embargo” where key individuals from the project, usually maintainers, are made aware of the vulnerability