> At no time did it include corporations who use Ounce Labs or Coverity Bzzzt. False. While there are plenty of Fortify customers represented in BSIMM, there are also plenty of participants who aren't Fortify customers. I don't think there are any hard numbers on market share in this realm, but my hunch is that BSIMM is not far off from a uniform sample in this regard.
Brian > -----Original Message----- > From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On > Behalf Of Kenneth Van Wyk > Sent: Wednesday, February 03, 2010 4:08 PM > To: Secure Coding > Subject: Re: [SC-L] BSIMM update (informIT) > > On Jan 28, 2010, at 10:34 AM, Gary McGraw wrote: >> Among other things, David and I discussed the difference between descriptive >> models like BSIMM and prescriptive models which purport to tell you what you >> should do. > > Thought I'd chime in on this a bit, FWIW... From my perspective, I welcome > BSIMM and I welcome SAMM. I don't see it in the least as a "one or the other" > debate. > > A decade(ish) since the first texts on various aspects of software security > started appearing, it's great to have a BSIMM that surveys some of the largest > software groups on the planet to see what they're doing. What actually works. > That's fabulously useful. On the other hand, it is possible that ten thousand > lemmings can be wrong. Following the herd isn't always what's best. > > SAMM, by contrast, was written by some bright, motivated folks, and provides > us all with a set of targets to aspire to. Some will work, and some won't, > without a doubt. > > To me, both models are useful as guide posts to help a software group--an SSG > if you will--decide what practices will work best in their enterprise. > > But as useful as both SAMM and BSIMM are, I think we're all fooling ourselves > if we consider these to be standards or even maturity models. Any other > engineering discipline on the planet would laugh us all out of the room by the > mere suggestion. There's value to them, don't get me wrong. But we're still > in the larval mode of building an engineering discipline here folks. After > all, as a species, we didn't start (successfully) building bridges in a > decade. > > For now, my suggestion is to read up, try things that seem reasonable, and > build a set of practices that work for _you_. > > Cheers, > > Ken > > ----- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > ************************************************************ > 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. > _______________________________________________ _______________________________________________ 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. _______________________________________________
