Full Disclosure Policy 2.0

Okay so for the last couple of days, I’ve spent what feels like a lifetime trying to track down the relevant people to report some various web application security vulnerabilities, and it’s been a living hell!

I’m posting this, so that hopefully someone will read this from a vendor, and realise the way that things are supposed to work. This work is originally posted here .

—————————————————————————————————-

////// Full Disclosure Policy (RFPolicy) v2.0 //////
This policy is available at http://www.wiretrip.net/rfp/policy.html

\\ Executive overview for vendors and software maintainers \\

This policy states the ‘guidelines’ that an individual intends to follow. You basically have 5 days (read below for the definitions and semantics of what is considered a ‘day’) to return contact to the individual, and must keep in contact with them *at least* every 5 days. Failure to do so will discourage them from working with you and encourage them to publicly disclose the security problem.

This policy is not set in stone—in fact, it is encouraged that all parties regularly communicate with each during the process, adjusting as situations arise.

\\ Table of contents \\

Purpose of this policy

Policy definitions

Policy

Detailed/commented explanation of policy

Difference between version 1 and version 2 of RFPolicy

RFPolicy FAQ

Using this policy

Credits
\\ Purpose of this policy \\

This policy exists to establish a guideline for interaction between a researcher and software maintainer. It serves to quash assumptions and clearly define intentions, so that both parties may immediately and effectively gauge the problem, produce a solution, and disclose the vulnerability.

First and foremost, a wake-up call to the software maintainer: the researcher has chosen to NOT immediately disclose the problem, but rather make an effort to work with you. This is a choice they did not have to make, and a choice that hopefully you will respect and accept accordingly.

The goal of following this policy, above all else, is education:

Education of the vendor to the problem (ISSUE, as defined below).

Education of the researcher on how the vendor intends to fix the problem, and what caveats might cause a solution to be delayed.

Education of the community of the problem, and hopefully a resolution.
With education, through continued communication between the researcher and software maintainer, it allows both parties to see where the other one is coming from. Coupled with compensation*, the experience is then beneficial to the researcher, vendor, and community. Win/win/win for everybody. :)

(*Compensation is meant to include credit for discovery of the ISSUE, and perhaps in some cases, encouragement from the vendor to continue research, which might include product updates, premier technical subscriptions, etc. Monetary compensation, or any situation that could be misconstrued as extortion, is highly discouraged.)

\\ Policy definitions \\

The ISSUE is the vulnerability, problem, or otherwise reason for contact and communication.

The ORIGINATOR is the individual or group submitting the ISSUE.

The MAINTAINER is the individual, group, or vendor that maintains the software, hardware, or resources that are related to the ISSUE.

The DATE OF CONTACT is the point in time when the ORIGINATOR contacts the MAINTAINER.

All dates, times, and time zones are relative to the ORIGINATOR.

A work day is generally defined in respect to the ORIGINATOR.
\\ Policy \\