Re: [SC-L] Comparing Scanning Tools

2006-06-08 Thread Gunnar Peterson
Hi James, I think you are right to look at it as economic issue, but the other factor to add into your model is not just the short term impact to developer productivity (which is non-trivial), but also the long term effects of making decisions *not* to deal with finding bugs. "Cleaning up data br

RE: [SC-L] Comparing Scanning Tools

2006-06-08 Thread Gary McGraw
Hi All, Just a quick reminder that there is a chapter on code scanning technology and its application in "Software Security" (www.swsec.com). Don't forget that these tools are best used as aids to make a smart human more efficient. They do not replace the human, nor are they of much use amon

RE: [SC-L] Comparing Scanning Tools

2006-06-08 Thread McGovern, James F (HTSC, IT)
Several thoughts: 1. I love it when industry analysts are perceived as being credible by throwing out financial costs for things they really don't have visibility into. 2. The VA lost data not do secure coding techniques but an employee not following the rules on what data to take out of the bu

[SC-L] SOA and security

2006-06-08 Thread Gary McGraw
Hi all, You may recall the article that I wrote with Scott Matsumoto and Jeremy Epstein about SOA security for IEEE S&P magazine. I recently did an interview with a SOA guy that stemmed from that article. It's available here: http://soasecurityarchitect.com/2006/06/08/interview-with-gary-mc

Re: [SC-L] Comparing Scanning Tools

2006-06-08 Thread Gunnar Peterson
Hi James, The point is going back to your original question -- "I wonder if budgets and the tools themselves are really causing more harm than helping in that enterprises will now think about trading off such tools vs the expense they cost." -- the economic comparison needs to take into account t