Kicksecure Vulnerability Disclosure Policy

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

This page documents Kicksecure'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 Kicksecure may publish information about reported vulnerabilities.

Version: 1.0

DRAFT!

Disclosure timelines

Disclosure timelines overview

Topic	Standard vulnerabilities	In-the-wild vulnerabilities	In-the-wild vulnerabilities directly affecting Kicksecure and/or Whonix
Day count reference	Day 0 is the day the vendor is first notified by Kicksecure.
Main deadline (if there is no fix yet)	90 days (after vendor notification)	7 days (after vendor notification)	0 days (published upon discovery)
Grace period (extra time, if explicitly agreed)	Up to 14 additional days	Up to 3 additional days	None
If a fix ships by the main deadline	Kicksecure publishes public details no earlier than 30 days after the patch is made available to users. Publication may happen later depending on workload.		N/A
If a fix ships during the grace period	Kicksecure 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.		N/A
If no fix ships by the main deadline	If no fix is available by the main deadline, Kicksecure may publish public details at or after that time. Publication may happen later depending on workload, unless a grace period was explicitly agreed.		N/A
If no fix ships by the end of the grace period	If a grace period was explicitly agreed and still no fix is available by the end of that grace period, Kicksecure may publish public details at or after that time. Publication may happen later depending on workload.		N/A
Exceptional Grace period (rare)	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.		N/A
Mutually-agreed early disclosure	Kicksecure 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 Kicksecure where feasible.		N/A

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, Kicksecure 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 Kicksecure.
  • 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 Kicksecure where appropriate. If needed, Kicksecure and the vendor may explicitly agree on what counts as "available to users" and on publication timing.

Definition: In-the-wild vulnerabilities directly affecting Kicksecure and/or Whonix

• What "In-the-wild" means: For this policy, a vulnerability is considered to be "in-the-wild" if there is clear evidence that it is both known to threat actors and being used to compromise the machines of end-users on any Linux distribution or operating system.
• What "vulnerabilities directly affecting Kicksecure and/or Whonix" means: This means a vulnerability that can be used to successfully breach the confidentiality, integrity, or availability of a Kicksecure or Whonix installation in its default configuration.
• Vulnerabilities that meet both of these criteria (that is, they are both in the wild and can compromise Kicksecure or Whonix) are eligible to be made public immediately upon discovery, as keeping them secret could prevent end-users from taking steps to protect themselves until a fix is made available.
• It is expected that this form of disclosure will be warranted very rarely, if ever. To date, no vulnerability discovered by Kicksecure has ever met both of these criteria.

Publication and disclosure by Kicksecure

• Disclosure and publication by Kicksecure: Kicksecure 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 Kicksecure.
  • Minimal publication by Kicksecure: If the vendor publishes an advisory through their usual channels, includes sufficient information for users, and gives credit to Kicksecure, Kicksecure 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 Kicksecure 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.
  • Kicksecure publication: We may publish the report through the same channels described in the "Disclosure and publication by Kicksecure" section.
  • Disagreement documentation: If Kicksecure 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 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, Kicksecure may publish it in some cases.
• Sharing with third parties: Kicksecure 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 Kicksecure 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: Project Zero (not Kicksecure!) Vulnerability Disclosure policy FAQ
• Reported vulnerabilities: To see what kinds of security vulnerabilities Kicksecure has reported, see Security Vulnerability Bug Reports.
• What is Project Zero: A dedicated security vulnerability research project. See also About Project Zero.
• What is Kicksecure: A security-hardened operating system. See also About.
  • Scope: Kicksecure is primarily a Linux distribution focused on proactive security defenses. In practice, this means a compilation of many upstream components, Kicksecure software, and integration "glue", combined to build a more secure system.
  • Not the main focus: Kicksecure is not primarily a project that searches for security vulnerabilities in third-party (upstream) software. Kicksecure does not intend to become Project Zero.
  • Why vulnerabilities may still be found: Due to our security hardening research, we sometimes find security vulnerabilities in upstream software.
  • Limits: Because vulnerability research and disclosure handling are not the main focus of Kicksecure, weaknesses in this policy and in our practices may be understandable.

Upstream Project Communication Templates

Standard vulnerabilities

Unless there is a particular reason not to, we'd like to make this bug public 90 days from today, on XXXX-XX-XX. If a fix for this issue is made available to users before the end of the 90-day deadline, we'd like to publicize it no later than 30 days after the fix was made available.

In-the-wild vulnerabilities

If at all possible, we'd like to make this bug public 7 days from today, on XXXX-XX-XX, 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, we'd like to publicize it no loater than 30 days after the fix was made available.

Credits

Based on Project Zero vulnerability disclosure policy.

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 14 year success story and maybe DONATE!