What are Full Disclosure and Responsible Disclosure

A debate has been going back basically as long as software: for security bugs is it better to follow Full Disclosure or Responsible Disclosure?

A great article on the topic comes form Bruce Schenier's Crypto-Gram way back in 2001.

Originally people primarily followed full secrecy - the issue was reported to vendors and not disclosed until the vendor decided to do it. This resulted in issues languishing for months or years while the researchers got no credit for their work and systems were vulnerable. That led researchers to want to regain some control.

Proponents of Full Disclosure believe that vendors move too slowly so they should publicly announce the vulnerability as soon as they can describe it accurately. and that putting knowledge of the bug into the hands of the system admins and software users so they can mitigate it appropriately for their environment. One of the main places for Full Disclosure is the Full Disclosure mailing list. The drawbacks of Full Disclosure are:

• vendors are rushed to make a release, potentially introducing bugs
• a broader pool of attackers have the information earlier, allowing them to exploit it sooner
• sysadmins and software users may not actually know what to do with this information

These flaws led people to a policy referred to as responsible disclosure.

Proponents of Responsible Disclosure feel that vendors should have some time, but not unlimited time, to fix and announce the issue. The exact amount of time to wait is up for debate: some say 2 weeks, others 60 days, and still others feel 6 months is appropriate. In 2010 Google wrote about Rebooting Responsible Disclosure where they discuss why Responsible Disclosure makes sense in a lot of cases, but needs a specific timeline, and is sometimes not appropriate. A couple of interesting points about Responsible Disclosure

• The researcher is tasked with proposing a deadline for public disclosure and they should do so considering whether the issue is critical and whether there is evidence of "blackhats" knowing or exploiting the issue.
• Schneier points out that researchers should give out papers, descriptions of the problem, descriptions of ways to mitigate the problem, but only after a patch is long released should researchers provide proof-of-concept exploit code.

The Drupal project works to follow Responsible Disclosure. We ask security researchers to keep the issue confidential until a fix can be released. If the module maintainer seems to be taking action then we will postpone the date for many months. That said, the Drupal Security Team will eventually issue an SA stating that sites should simply remove the module and we will publish the issue in the queue so it can be fixed and the module returned to a full release status.