[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TECH] "Responsible Disclosure Process" released

Most of you know that I have been working with Chris Wysopal to
produce a document that describes a process for responsible
disclosure.  This is directly related to CVE in the following ways:

- The Board has agreed that CNAs should not reserve candidates for
  people who do not practice responsible disclosure (candidates would
  be assigned *after* publication).  I hope that this document, or a
  later version, will become part of the "definition" of responsible

- 50% of reported vulnerabilities are not clearly acknowledged by the
  vendor, which directly affects voting on candidates.

- As I am starting to discuss more publicly, here and elsewhere,
  disclosure has other impacts on CVE content.

The announcement is below.

- Steve

An Internet-Draft titled "Responsible Disclosure Process" has been
released for commentary by me and Chris Wysopal of @stake.  This
Internet-Draft may be reviewed by members of the IETF and the general
public.  This is the first step towards establishing an RFC (Request
for Comments) and Best Current Practices document.  This document is
*not* an RFC, and it does *not* represent a commitment by the IETF to
produce an RFC.  It is the first step within the IETF review process.

It should be noted that we plan to create a "sister document" that
will contain recommendations for the contents of security advisories.
The curent Internet-Draft is focused on how the different parties
interact, not the type of information that gets published.


   New vulnerabilities in software and hardware products are discovered
   and publicized on a daily basis.  The disclosure of vulnerability
   information has been a divisive topic for years.  During the process
   of disclosure, many vendors, security researchers, and other parties
   follow a variety of unwritten or informal guidelines for how they
   interact and share information.  Some parties may be unaware of these
   guidelines, or they may intentionally ignore them.  This state of
   affairs can make it difficult to achieve a satisfactory outcome for
   everyone who uses or is affected by vulnerability information.

   The purpose of this Internet-Draft is to describe best practices
   for a responsible disclosure process that involves vulnerability
   reporters, product vendors or maintainers, third parties, the
   security community, and ultimately customers and users.


   We gratefully acknowledge the constructive comments received from
   several contributors.  Any errors or inconsistencies in this
   Internet-Draft are solely the responsibility of the authors, and
   not of the reviewers.  This document does not necessarily reflect
   the opinion of the reviewers or their parent organizations.

   We would like to thank Andy Balinsky, Mary Ann Davidson, Elias Levy,
   Russ Cooper, Scott Blake, Seth Arnold, Rain Forest Puppy, Marcus
   Ranum, Lori Woeler, Adam Shostack, Mark Loveless, Scott Culp, and
   Shawn Hernan for their valuable input.

Obtaining the Internet-Draft

  The Internet-Draft is accessible from the following URL:


  (this URL may have been wrapped by your email client).

  Note that the version number of this draft will change as it is
  modifed due to public commentary.

Commenting on the Internet-Draft

  Discussion of this Internet-Draft is currently taking place on the
  IETF Security Area Advisory Group (SAAG) mailing list, although it
  is possible that the IETF may move the discussion to another
  location at a later date.

  SAAG mailing list archives and subscription information can be found
  at http://jis.mit.edu/mailman/listinfo/saag

The IETF and RFC process

  A high-level description of the IETF and the RFC process is at

  Additional details on the Internet standards process are at


Steve Christey
Lead INFOSEC Engineer
The MITRE Corporation

Chris Wysopal
Director of Research and Development
@stake, Inc.

Page Last Updated or Reviewed: May 22, 2007