Re: Microsoft SDL report card

["Steven M. Christey" <coley () linus mitre org>]

On Thu, 31 Mar 2011, security curmudgeon wrote:

> Circumstancial evidence suggests Microsoft's SDLC isn't making much
> progress (e.g., 2011-02-08, 2010-12-14):
>
> http://osvdb.org/search?search[vuln_title]=microsoft&search[text_type]=titles
>
> Specifically, not just the amount of vulnerabilities but the types. Things
> don't appear to have changed much over the years.

Microsoft is a victim of its own vague advisories by using generic terms 
like "memory corruption" that make people assume it's always the same old 
problem.  But in general, the types of vulnerabilities that they're 
getting hit with are related to access of uninitialized data, 
use-after-frees/use-after-deletes, array index errors, pointer calculation 
errors, etc. - all issues for which detection and reliable exploitation 
are still fairly rare.  (Other vendors/products are getting hit with 
these, too.)

When software is getting flagged with more obscure issues, instead of the 
same old classic overflows and format strings (SCADA anyone?), that 
suggests a noticeable improvement in the SDLC.

You know better than most about the dangers of relying too much on 
information about published vulnerabilities ;-)  For example, Microsoft 
products are probably aggressively targeted by more attackers / 
researchers than most other products ever will be, thanks in large part to 
market share.  So the raw numbers of reported issues aren't surprising.

But I believe that qualitative indicators (such as "novel" vuln types) can 
be informative, unless/until our software security practice develops 
repeatable, consistent metrics (which also assumes accuracy improvements 
in automated code scanning and consistent threat/architecture/design 
analysis).

Interested parties can see my 2007 "Unforgivable Vulnerabilities" paper, 
which describes different phases of software maturity in terms of the 
kinds of vulnerabilities being discovered in the product.

If anything, Microsoft's continued troubles are an indicator of how far 
the whole software industry needs to go.

- Steve
_______________________________________________
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________