Hi Steve, Thanks for your thoughtful response. I do think the top-25 project moved things in the right direction (in particular with the idea of mitigations), but I still have worries. BTW, sorry for the delay responding, I had band practice last night for my "Hot Club Millwood" (Django/Grappeli covers) concert Friday.
BTW, I do hope everyone will read the original article <http://www.informit.com/articles/article.aspx?p=1322398> in order to see the paragraphs explaining the sentences that Steve snipped here. Some particular responses to steve's concerns: gem> Executives don't care about technical bugs s> No, but they do what PCI says they have to (i.e. listen to the OWASP Top s> Ten). They do care about the bottom line. They hate buying software and s> finding out how crappy it is afterward. Unfortunately security by compliance seems to be more of a problem than it is a justification for top ten lists. In my view, PCI does not lead to secure software. gem> Too much focus on bugs. s> The Top 25 has 4 or 5 items that are clearly design-related I acknowledge movement in the right direct here. Question for sc-l...do we need a "top ten flaws" list? gem> Using bug parade lists for training leads to awareness but does not educate. s> Yep - which is why we want universities to get cracking, and if the Top 25 s> helps to prod them on, then so be it. Good lord I hope that the CS curriculum does not embrace the bug parade. I would rather have a crop of kids who know how C *actually works*, what a stack is, and how computers function! Education prepares people for training...it does not supercede it. Sadly, I have little faith that software security will work its way into the university curriculum in a meaningful way (and will be ecstatically psyched to be completely wrong). gem> Top ten lists mix levels. s> Regarding Seven Pernicious Kingdoms - how does the Top 25 map to them? Good question. You tell me! Hopefully it's better than the OWASP 10! Once again, I think we need to ponder the difference between a taxonomy and a top-N list. gem> Automated tools can find bugs---let them. s> Yes, and a lesson of the Top 25 (that we all already know) is that when s> people start to apply it, they'll see how a tool won't be a silver bullet. A tool is so much superior to a list that I simply have say..huh?! gem> When it comes to testing, security requirements are more important than vulnerability lists. s> New York State has put up draft text that mentions the Top 25 as s> part of a condition for acquisition. In my view this is not a helpful development. gem> Ten is not enough. s> I'm of the mindset that the Top 25 is, short-term, an awareness tool for s> developers and for customers. Agreed. I like it for that reason. s>In the longer term, maybe it will be a little blip on the road to actionable software assurance. This is my concern. s> The Top 25 is a means to an end, and not the end itself. Also agreed. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com _______________________________________________ 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. _______________________________________________
