Hello, this is Nate McFeters, the original author of the article.

Awitod quoted me as saying:
"The problem of course is I'm saying how the companies should handle them, and I have no authority at any of these places, save people actually valuing my ideas. Personally, I've done some development in the past, and there was the concept of defects. Your bonus would depend on how many defects were in your application at delivery time. These were feature-based defects, but shouldn't vulnerabilities be considered defects as well?"

And has responded with the following:
"So, the author freely admits he is neither a developer or a manager. If he was a developer he'd know that these are defects and everyone treats them as such."

To that, I respond by saying that I am no longer a developer or manager, although I did develop applications in both Java and C++ for around 6 years full-time, and managed a significant development effort of over 200K lines of code. Currently, I work at Ernst & Young's Advanced Security Center as a consultant, where I work with a lot of fortune 500 companies, mostly on addressing their web application security needs. I've performed deep source code assessments on applications over 2 million lines of code and been tightly integrated into a few companies development lifecycles. SO, that said, I truly have a ton of experience with this type of thing, and I'm actually surprised that so many people on the Slashdot list here have responded saying that they ARE treating these as defects, as this is NOT what I've seen from a majority of my clients and does not reflect what I've heard from others in my line of work with other consulting companies.

Awitod goes on to say:
"If he was a manager, he'd know that one of the surest ways to wreck a good shop is to start doing comp based on defects. Here is what invariably (in my experience) happens when a shop includes defect counts in there comp plans.

1. Relationships between Dev, QA, Product Management and Operations get worse because the terms 'defect' and 'bug' become toxic. In reality these things always exist in software. The last thing you want to do is create barriers to dealing with them. Making the acknowledgment of a defect cost someone money means you will have arguments over every one of them unless they cause an out right crash."

I don't agree that this is necessarily the case. I don't think you have to wreck relationships to encourage a positive competitive environment. This is exactly why I suggested moving to a positive culture that includes training for developers, a secure software development lifecycle that encourages challenging development and business to look at security issues throughout the entire development of an application, and most importantly, I actually suggested that rather than take the negative approach... reinforce positively.

For example, the top BU could get the biggest bonus, or a celebratory night out, or whatever... maybe it's just a trophy or championship belt they get to keep with their group, which could be a fun pride point. Positive competition can be astoundingly effective at managing a team.

Awitod continues:
"2. Culture becomes overly risk-averse - No one wants to take on difficult problems or blaze new territory. The smartest people will naturally pick the easiest work to minimize the risk of defects."

I disagree and feel this could be fixed quite simply. If you address possible security concerns in the design phase of the application build out, you have a pretty good idea of the threat threshold of the application. Applications that are tackling tough challenges or blazing new territory could be given higher scoring factors.

Think of this similar to how an Olympic Diver can perform a perfect jump, but still get a lower score than someone who just missed a tougher jump. In this case, strong teams will be striving to take on the tougher challenges. You could also put other factors into that as well, such as time deadline (as that certainly adversely affects what you can do from a security standpoint), budgetary constraints, etc.

Awitod continues:
"3. Over-dependence on consultants - More CYA behavior. If it's too complex people will outsource to keep the defects away. This is a very bad thing if the nasty problems are because of business and not technical challenges. Now the people who know enough about the problem domain to understand the risk are hiring proxies who know nothing to avoid responsibility for 'defects'."

Certainly agreed on this one, but this is a problem no matter how you treat your vulnerabilities. I also think that this implies a bit of a distance between you and your consultants. If you are just doing A&P's with your consulting firm, your missing out on the true value of a good firms expertise. In my opinion, your consultants should be on the ground with you, helping you early in the process even in the design phase, that way, they do understand the business drivers and concerns and can be tightly coupled with your team.

I don't mean to pick on awitod here, his comments were very good. I just think it's important to point out a second opinion on things. I'm pretty happy that it seems people have enjoyed the article and have had some really good comments back here on Slashdot.

Thanks,

Nate McFeters