Vulnerability Disclosure Policy

This documents outlines a responsible disclosure model to publish security vulnerabilities. In the course of responsible disclosure vendors may sometimes try to delay fixing of vulnerabilities indefinitely. To counter this move a more strict approach is chosen to make sure a fix will be provided in a reasonable time or the details are disclosed publicly to make sure other mitigations can be established.

Found vulnerabilities will be disclosed to the vendor; if the vendor does not reply or a fix is not available after 45 days the vulnerability details will be released to the public.

Communication

The communication is done via e-mail only; no contact forms, issue-trackers or other means of communication will be used.

Vulnerability Classes

Upon discovery, vulnerabilities will be categorized in one of four severity classes (taken from the chromium project).

Critical Severity

Allows an attacker run arbitrary code with the user's privileges in the normal course of usage.

For critical vulnerabilities, a patch needs to be provided in under 30 days. If a fix is available for at least 14 days the vulnerability details are made public - or 45 days after the vendor was informed of the issue. If there is evidence of active exploitation the details are published after 7 days.

High Severity

Allows an attacker to read or modify confidential data belonging to other entities.

The vulnerability details are published 30 days after the vendor was notified.

Medium Severity

Allows an attacker to obtain limited amounts of information.

The vulnerability details are published 30 days after the vendor was notified.

Low Severity

Allows an attacker temporary control over non-critical features.

The vulnerability details are published 30 days after the vendor was notified.

At a glance …

• Notification. The vendor will be notified by e-mail describing the discovery of a security vulnerability. This will be done using the following addresses: security@, security-alert@, support@, secalert@, psirt@. Alternatively the e-mail will be sent to: abuse@, postmaster@, sales@, info@
• Acknowledgment. The vulnerability has to be acknowledged after at most 14 days. A failure to comply may trigger the publication of the vulnerability details.
• Status Update. A status update needs to be given by the vendor every 14 days (or a otherwise agreed time-frame).
• Disclosure-Deadline. The disclosure of the vulnerability will be done in accordance to the aforementioned severity classes.
• Missed-Deadline. If a vendor misses a deadline or refuses to fix / cooperate the details of the vulnerability may be published immediately. A applicable workaround may be given if available.
• Weekends. If a disclosure date would be a weekend the deadline will be moved to the next work day.
• Grace-period. A 14-day grace period may be granted if a patch is released in this time-frame.
• CVEs. Before publication a CVE will be requested to be published alongside the vulnerability report.

Exceptions

Some vulnerabilities need more time to be fixed correctly (e.g. design errors, issues in widely-deployed applications, etc.). Therefore more time may be granted for these bugs. This is up to the researcher - not the vendor.

Acknowledgment of the vulnerability

If the vendor publicly discloses details to this vulnerability the following acknowledgment line should be used:

ACKNOWLEDGEMENT 
This vulnerability was reported to <vendor> by Markus Piéton (www.a12d404.net).