How to report vulnerabilities to LF projects and foundations

We at the Linux Foundation (LF), along with our many contributors, work to develop secure software in our foundations and projects. We also work to secure the infrastructure and processes we use. Sadly, mistakes can happen. So, if you discover a security vulnerability in something we do, please tell us!

If you find a security vulnerability in the software developed by an LF foundation or project, or in how we develop the software, please report the vulnerability directly to that foundation or project, using their vulnerability reporting process and policy. Examples of such processes/policies are (alphabetically) those of FINOS, Kubernetes, the Linux kernel, Yocto, and Zephyr. Feel free to browse our list of foundations/projects.

If you find a security vulnerability in either the LF infrastructure (as a whole) or the main LF website, please privately report it to security@linuxfoundation.org. Do not send vulnerability reports there for any other situation (such as for the Linux kernel or any other project); such reports will typically be ignored. Instead, send the project vulnerability report directly to the relevant foundation/project.

Guidance

The vulnerability reporting process is often described in the file SECURITY.md of its source repository, among other places. This process will typically involve one of:

1. Sending an email to security@DOMAIN where DOMAIN is the domain of the project/foundation. For example, Linux kernel security vulnerabilities should be reported to security@kernel.org as described in the Linux kernel security bugs page. In some cases, different email address(es) other than “security” will be recommended.
2. Using GitHub’s ability to privately report a security vulnerability, if the project is hosted on GitHub. In cases where private reporting has been enabled, please use it.

If a specific LF project doesn’t state how to report a vulnerability, report the vulnerability to the foundation that runs the project using its process. Also, if an LF project or foundation doesn’t make it clear how to report vulnerabilities, please ask them to clarify their process so that you can then report the vulnerability. If a project doesn’t respond in any way to a report, after some time retransmit it several times in case it was accidentally dropped. Please give them time to fix it before making the vulnerability public (many ask for up to 90 days from the initial report). If the project/foundation is marked as no longer being maintained (e.g., it is “archived” or “abandoned”), then reporters may directly report the vulnerability to the public, but they must also clearly note that the project is already marked as being no longer maintained.

Vulnerability finders (aka security researchers) who discover security vulnerabilities, and aren’t familiar with how to report vulnerabilities to open source software (OSS) projects, should consult the OpenSSF “Guidance for Security Researchers to Coordinate Vulnerability Disclosures with Open Source Software Projects”. You must provide specific information about the vulnerability so it can be rapidly identified, verified as a true (exploitable) vulnerability, and corrected. In particular, a data dump from a fuzzer or a static analysis tool is normally insufficient and is not considered a valid vulnerability report. If the project/foundation has a bug bounty program, payment (if applicable) occurs as defined by its bug bounty program. Otherwise, please do not expect that you’ll be paid for a vulnerability report, as we have limited resources. Please make it clear in your report whether or not you would like public credit when the vulnerability is publicly announced (we typically assume you want public credit).

If the vulnerability isn’t already publicly and widely known, our projects typically ask that you privately report vulnerabilities with time to fix them (often up to 90 days). If such vulnerabilities are publicly reported, attackers may exploit the software while maintainers are still working on a fix. So, unless otherwise required by law, do not publicly report the details of an otherwise unknown vulnerability or share that information with anyone likely to exploit the vulnerability, until either the project has time to fix the vulnerability or the project says it is fine to make it public.

If you have specific recommendations on how to improve a particular foundation / project, beyond fixing specific vulnerabilities, please work with the foundation / project to help them improve their processes and results.

For LF foundations and projects

If you lead an LF foundation, or maintain an LF project, we ask that you take steps to (1) make it easy for vulnerability finders (e.g. users or security researchers) to report vulnerabilities, and (2) be ready to receive those reports. The OpenSSF “Guide to implementing a coordinated vulnerability disclosure process for open source projects” can help you do that. As noted above, vulnerability reports are typically sent to security@YOUR_DOMAIN and/or a private reporting mechanism; this should be noted in a SECURITY.md file and README file where appropriate. As noted above, please give public credit to the finder when the vulnerability is publicly announced (unless the finder has requested that they not receive public credit).

We also encourage you to make vulnerabilities less likely. For example, we encourage you to learn how to develop secure software, as well as use practices to counter vulnerabilities (e.g., see the Concise Guide for Developing More Secure Software, Concise Guide for Evaluating Open Source Software, the OpenSSF Security Scorecard, and the OpenSSF Best Practices badge). Each of the LF foundations and projects is expected to try to develop software that is adequately secure for its purpose, apply good practices to counter attacks (including supply chain attacks), and continuously improve.

The Linux Foundation is also working to make open source software (OSS) even more secure in general. The Open Source Security Foundation (OpenSSF) is a broad initiative to secure the OSS that we all depend on. Please check out the OpenSSF if you’re interested in learning more.

Acceptable approaches

There are laws and regulations that may impact security research. You should become familiar with them and consult legal counsel if you have any questions. The Linux Foundation cannot provide you with legal advice and it is your responsibility to comply with applicable laws. We welcome your vulnerability report contributions; they are valuable contributions to our communities and the ecosystems dependent on the projects. The Linux Foundation itself will not pursue legal action against anyone for performing vulnerability analysis on our projects or for disclosing vulnerabilities to our projects (e.g. using the project’s defined process).

If you have concerns or are uncertain whether your approach to security research is acceptable with a specific foundation or project, please contact the foundation / project community first.