{{Header}} {{title|title= {{project_name_short}} Vulnerability Disclosure Policy }} {{#seo: |description={{project_name_short}} vulnerability disclosure policy based on a 90+30 deadline, including grace periods, handling for in-the-wild exploitation, and publication practices. }} {{intro| This page documents {{project_name_short}}'s vulnerability disclosure policy for security issues reported to upstream vendors. The goal is to provide clear, predictable timelines for disclosure while giving vendors time to ship fixes and protecting users when active exploitation is detected. This page also documents how {{project_name_short}} may publish information about reported vulnerabilities. Version: 1.0 }} {{draft}} == Disclosure timelines == {| class="wikitable" |+ Disclosure timelines overview |- ! Topic ! Standard vulnerabilities ! In-the-wild vulnerabilities |- ! Day count reference | colspan="2" | Day 0 is the day the vendor is first notified by {{project_name_short}}. |- ! Main deadline (if there is no fix yet) | 90 days (after vendor notification) | 7 days (after vendor notification) |- ! Grace period (extra time, if explicitly agreed) | Up to 14 additional days | Up to 3 additional days |- ! If a fix ships by the main deadline | colspan="2" | {{project_name_short}} publishes public details no earlier than 30 days after the patch is made available to users. Publication may happen later depending on workload. |- ! If a fix ships during the grace period | colspan="2" | {{project_name_short}} publishes public details no earlier than 30 days after the main deadline has passed (that is, after day 90 for standard vulnerabilities, or after day 7 for in-the-wild vulnerabilities), regardless of which day within the grace period the patch is released. Publication may happen later depending on workload. |- ! If no fix ships by the main deadline | colspan="2" | If no fix is available by the main deadline, {{project_name_short}} may publish public details at or after that time. Publication may happen later depending on workload, unless a grace period was explicitly agreed. |- ! If no fix ships by the end of the grace period | colspan="2" | If a grace period was explicitly agreed and still no fix is available by the end of that grace period, {{project_name_short}} may publish public details at or after that time. Publication may happen later depending on workload. |- ! Exceptional Grace period (rare) | colspan="2" | In exceptional cases (for example but not limited to very complex, ecosystem wide issues, or extraordinary circumstances such as residing in a territory affected by war), an additional grace period without a fixed limit may be possible by explicit agreement. |- ! Mutually-agreed early disclosure | colspan="2" | {{project_name_short}} and the relevant vendor can mutually agree to publish earlier than the policy timelines. The vendor is always free to publish at any time. Vendors are encouraged to coordinate publication with {{project_name_short}} where feasible. |- |} == Definition: patch available to users == * What "patch available to users" means: For this policy, a patch is considered "available to users" when corrected binaries are broadly available to affected users through the vendor's normal distribution channels that users are expected to use (for example, stable releases, security updates, or vendor-supported update mechanisms), and the vendor has published a corresponding announcement (for example, an advisory, release notes, or a security bulletin), unless otherwise agreed. ** Quiet fixes: Vendors are allowed to commit fixes without explicitly stating that a potential CVE or other security issue was fixed. ** Public source changes: For timing purposes, {{project_name_short}} does not treat a public source code patch, by itself, as equivalent to public disclosure. *** For reference only, Project Zero’s FAQ summarizes their view as follows: “We think a public source code patch is usually equivalent to a public disclosure, even if it’s not clearly marked as a security-relevant change.” This quote is non-binding for {{project_name_short}}. ** Our expectation: We prefer vendors to make corrected binaries broadly available through their usual channels, publish an advisory or equivalent announcement, and give credit to {{project_name_short}} where appropriate. If needed, {{project_name_short}} and the vendor may explicitly agree on what counts as "available to users" and on publication timing. == Publication and disclosure by {{project_name_short}} == * Disclosure and publication by {{project_name_short}}: {{project_name_short}} may publish information about reported vulnerabilities using the following channels, depending on what is useful and appropriate for users. ** Development research log: We may add an entry to [[Dev/research]]. ** News: We may publish a news item. See also [[Stay Tuned]]. ** Wiki documentation: We may add information to the wiki if it is useful as an example or is likely to be relevant again. If a relevant wiki page already exists, we prefer adding to that page. Creating a new page or documentation editing is less likely for one-off issues. ** Credit and vendor advisories: We hope the vendor will publish their own advisory or bug report through their usual channels and give credit to {{project_name_short}}. ** Minimal publication by {{project_name_short}}: If the vendor publishes an advisory through their usual channels, includes sufficient information for users, and gives credit to {{project_name_short}}, {{project_name_short}} may limit publication to a short entry in [[Dev/research]] (and optionally other brief references as needed). == Vendor responses == * Vendor publication of reports and credit: If a report is acknowledged as valid, we prefer that the vendor publishes the previously private bug report, if any, and gives credit to {{project_name_short}} as appropriate. ** E-mail reports: If the report was sent by e-mail, it would be good if the vendor publishes the e-mail (or an equivalent copy) at an appropriate time (for example, together with the vendor’s advisory or bug tracker entry). * Vendor response: invalid or won't fix: If the vendor states the report is invalid or indicates they cannot or will not fix the issue, publication of the previously private bug report (if any) is encouraged. ** Vendor publication preferred: If the report was sent by e-mail, it would be good if the vendor publishes the report. However, vendors may be unwilling to do so if they believe the issue is invalid or will not be fixed. ** Issue tracker considerations: If there is a suitable vendor issue tracker, we may attempt to post the report there. ** {{project_name_short}} publication: We may publish the report through the same channels described in the "Disclosure and publication by {{project_name_short}}" section. ** Disagreement documentation: If {{project_name_short}} disagrees with an "invalid" or "won't fix" decision and believes the issue affects our users, we may document the difference of opinion in our news blog and/or wiki (including the vendor’s position, if known). == Open questions == * Reporting transparency: Undecided. See also [https://projectzero.google/2025/07/reporting-transparency.html Project Zero reporting transparency (2025)]. * Proof of concept code: Undecided. If proof of concept code is included as part of a bug report or becomes available during coordination, {{project_name_short}} may publish it in some cases. * Sharing with third parties: {{project_name_short}} does not intend to share vulnerability details with other parties unless the issue directly involves multiple projects. == Further reading == * Project Zero's FAQ: This FAQ is not part of the {{project_name_short}} Vulnerability Disclosure Policy. It may still be useful background reading to understand why a policy like this can make sense. It is for information only and is non-binding: [https://projectzero.google/vulnerability-disclosure-faq.html Project Zero (not {{project_name_short}}!) Vulnerability Disclosure policy FAQ] * Reported vulnerabilities: To see what kinds of security vulnerabilities {{project_name_short}} has reported, see [[Dev/research#Security_Vulnerability_Bug_Reports|Security Vulnerability Bug Reports]]. * What is Project Zero: A dedicated security vulnerability research project. See also [https://projectzero.google/about-pz.html About Project Zero]. * What is {{project_name_short}}: A security-hardened operating system. See also [[About]]. ** Scope: {{project_name_short}} is primarily a Linux distribution focused on proactive security defenses. In practice, this means a compilation of many upstream components, {{project_name_short}} software, and integration "glue", combined to build a more secure system. ** Not the main focus: {{project_name_short}} is not primarily a project that searches for security vulnerabilities in third-party (upstream) software. {{project_name_short}} does not intend to become Project Zero. ** Why vulnerabilities may still be found: Due to our [[Dev/research|security hardening research]], we sometimes find security vulnerabilities in upstream software. ** Limits: Because vulnerability research and disclosure handling are not the main focus of {{project_name_short}}, weaknesses in this policy and in our practices may be understandable. = Upstream Project Communication Templates = == Standard vulnerabilities == {{quotation |quote=This bug is subject to a 90 day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public no earlier than 30 days after the fix was made available. Otherwise, this bug report may become public after the deadline. }} == In-the-wild vulnerabilities == {{quotation |quote=This bug is subject to a 7 day disclosure deadline because there is evidence that this vulnerability is being actively exploited against real users in the wild. If a fix for this issue is made available to users before the end of the 7-day deadline, this bug report will become public no earlier than 30 days after the fix was made available. Otherwise, this bug report may become public after the deadline. }} = Credits = Based on [https://projectzero.google/vulnerability-disclosure-policy.html Project Zero vulnerability disclosure policy]. {{Footer}} [[Category:Development]]