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 wel
Again, people are reading other peoples words as though they are ours. Please see our page for the information... a simple Google search would've provided you with this info.
XS-Sniper
Thanks,
Nate
Gents, please keep in mind that we did not post this original story. If you want to see the technical content, you should actually go and read the research we posted at our site XS-Sniper. This was not referenced in the article.
As for the security.itworld.com link that references stealing user's data, this is a new story that we were just interviewed on a couple of days ago. The vulnerability is real, and will be released after appropriate communications with the vendor.
Thanks,
Nate
Slashdot Mirror
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 wel
Again, people are reading other peoples words as though they are ours. Please see our page for the information... a simple Google search would've provided you with this info. XS-Sniper Thanks, Nate
Gents, please keep in mind that we did not post this original story. If you want to see the technical content, you should actually go and read the research we posted at our site XS-Sniper. This was not referenced in the article. As for the security.itworld.com link that references stealing user's data, this is a new story that we were just interviewed on a couple of days ago. The vulnerability is real, and will be released after appropriate communications with the vendor. Thanks, Nate