full-disclosure - Open Letter on the Interpretation of "Vulnerability Statistics"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat Jan  7 18:29:32 2006
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Open Letter on the Interpretation of
	"Vulnerability Statistics"

On Sat, 7 Jan 2006, Georgi Guninski wrote:

> - 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
>   disclosure.

This has also somewhat evolved over time.

"Responsible disclosure" or "coordinated disclosure" or whatever you want
to call it is one of the best ways to ensure there is actionable, accurate
non-duplicated information at the time of disclosure.  If you don't
coordinate with a vendor, then your advisory will not have vendor fix
information, the list of affected versions might be incomplete, the
underlying bug diagnosis might be missing or wrong, and the only
actionable items might be to reduce the affected functionality or use
another product, which is not necessarily feasible in an organization with
more than, say, 100 machines.

This kind of information is important for assigning the correct number of
candidates to an issue.

Florian - I don't see an incompatibility in Debian's approach.  Before
publication, Debian interacts with the vendor (i.e. itself and probably
the maintainer).

- Steve