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.
Likewise, if you wanted to think of security as a system quality and wanted to compare it to things like performance and scalability, those things haven't been always solved by changing code where the behavior was more like throwing lots of hardware at it. Security has done some of this as well but this will not uncover what you seek. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ljknews Sent: Wednesday, July 18, 2007 3:42 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Resources to fix vulns At 8:53 AM -0700 7/18/07, McCown, Christian M wrote: > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7C953.D03CBE5C" > > What do you tell a C-level exec in terms of h/c and time it will take >to fix web app vulnerabilities discovered in a website? > > X number of vulnerabilities = Y h/c and Z time. > > Of course there's a host of factors/variables involved that could wind >up looking like actuarial tables or DNA sequences (!), but what we'd >like to be able to do is sum it up as an initial swag and let the app >owners use it as a factor in calculating the actual time to remediate. Look at the track record for _that_organization_ fixing previous vulnerabilities. -- Larry Kilgallen ************************************************************************* This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
