Aloha Jim, I agree that security bugs should not necessarily take precedence over other bugs. Most of the initiatives that we observed cycled ALL security bugs into the standard bug tracking system (most of which rank bugs by some kind of severity rating). Many initiatives put more weight on security bugs...note the term "weight" not "drop everything and run around only working on security." See the CMVM practice activities for more.
The BSIMM helps to measure and then evolve a software security initiative. The top N security bugs activity is one of an arsenal of tools built and used by the SSG to strategically guide the rest of their software security initiative. Making this a "top N bugs of any kind" list might make sense for some organizations, but is not something we would likely observe by studying the SSG and the software security initiative. Perhaps we suffer from the "looking for the keys under the streetlight" problem. gem On 3/19/09 2:31 PM, "Jim Manico" <j...@manico.net> wrote: > The top N lists we observed among the 9 were BUG lists only. So that > means that in general at least half of the defects were not being > identified on the "most wanted" list using that BSIMM set of activities. This sounds very problematic to me. There are many standard software bugs that are much more critical to the enterprise than just security bugs. It seems foolhardy to do risk assessment on security bugs only - I think we need to bring the worlds of software development and security analysis together more. Divided we (continue to) fail. And Gary, this is not a critique of just your comment, but of WebAppSec at large. - Jim ----- Original Message ----- From: "Gary McGraw" <g...@cigital.com> To: "Steven M. Christey" <co...@linus.mitre.org> Cc: "Sammy Migues" <smig...@cigital.com>; "Michael Cohen" <mco...@cigital.com>; "Dustin Sullivan" <dustin.sulli...@informit.com>; "Secure Code Mailing List" <SC-L@securecoding.org> Sent: Thursday, March 19, 2009 2:50 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) > Hi Steve, > > Sorry for falling off the thread last night. Waiting for the posts to > clear was not a great idea. > > The top N lists we observed among the 9 were BUG lists only. So that > means that in general at least half of the defects were not being > identified on the "most wanted" list using that BSIMM set of activities. > You are correct to point out that the "Architecture Analysis" practice has > other activities meant to ferret out those sorts of flaws. > > I asked my guys to work on a flaws collection a while ago, but I have not > seen anything yet. Canuck? > > There is an important difference between your CVE data which is based on > externally observed bugs (imposed on vendors by security types mostly) and > internal bug data determined using static analysis or internal testing. I > would be very interested to know whether Microsoft and the CVE consider > the same bug #1 on internal versus external rating systems. The > difference is in the term "reported for" versus "discovered internally > during SDL activity". > > gem > > http://www.cigital.com/~gem > > > On 3/18/09 6:14 PM, "Steven M. Christey" <co...@linus.mitre.org> wrote: > > > > On Wed, 18 Mar 2009, Gary McGraw wrote: > >> Many of the top N lists we encountered were developed through the >> consistent use of static analysis tools. > > Interesting. Does this mean that their top N lists are less likely to > include design flaws? (though they would be covered under various other > BSIMM activities). > >> After looking at millions of lines of code (sometimes constantly), a >> ***real*** top N list of bugs emerges for an organization. Eradicating >> number one is an obvious priority. Training can help. New number >> one...lather, rinse, repeat. > > I believe this is reflected in public CVE data. Take a look at the bugs > that are being reported for, say, Microsoft or major Linux vendors or most > any product with a long history, and their current number 1's are not the > same as the number 1's of the past. > > - 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. > _______________________________________________ > _______________________________________________ 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. _______________________________________________
