At 9:50 AM -0400 7/19/07, McGovern, James F (HTSC, IT) wrote:

>  I would actually recommend AGAINST using prior track records for fixing
> previous vulnerabilities because in all honestly they probably don't
> track it. Most enterprises prioritize any type of defect based on the
> importance as declared by business users whom traditionally would
> prioritize a spelling error on a web page of higher importance than a
> buffer overflow. Security stuff may get addressed while the developer
> has the patient open and therefore there is no real transparency in
> terms of the numbers.

If investigation of prior security vulnerability remediation shows it
is skewed by low organizational priority, then that _is_ an indication
of how fast _that_organization_ will fix a security vulnerability.  It
seems much more honest that guesses about how long it would take if it
were high priority.

As for record keeping, the source code archives should show the date a
change was made (even if bundled with other changes).
Larry Kilgallen
Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to