I’m just perusing a DarkReading article that talks about the just-released 2010 CWE/SANS Top 25 Most Dangerous Programming Errors and something about a software procurement security contract (link from 2009, so not sure if this is what was referenced).
Without the benefit of real dialogue/discussion on what the contract is trying to do and what it really means, my kneejerk reaction echoes what Gary McGraw was quoted saying in the DarkReading article(“The liability angle is not the right idea…”). A contract is an extremely heavy-handed way to try to ensure something you can’t ensure (secure). But I guess it does throw a punch to software developers where it hurts the most: money. Still, this isn’t about improving security so much as shifting monetary losses. In other words, the avoidance of those punches where it hurts the most. Should vendors/developers be responsible? Yes. But I also think natural market forces are “better” for this relationship than contract wording. You got hacked through bad software? Stop using that software. You bought bad software? Maybe your procurement *process* was hurried and flawed. Shifting costs…that’s all this really is.
It also has the dangerous possible side-effect of allowing software buyers to blame developers for everything, even improperly using software or nor properly following their own best practices for network security, isolation, and so on. You mean I can blame Microsoft because my Windows XP system was connected directly to the Internet without a firewall/router?
I also would be worried that we just get more violent about disagreements on what is considered a “security issue” or a “bug.” Contracts bring about discussion on semantics and definitions…things that don’t help anyone.
One thought on “sans top 25 released, and thoughts on procurement contracts”
Gary is just throwing punches because the “good” contract language came from OWASP, not SANS/MITRE. At least that’s my gut reaction.
Contract language is extremely useful in a number of ways not even mentioned:
1) Placing closed-source application source code into escrow in case of the ISV’s financial or other collapse
2) Allowing customer of an ISV to test the application
3) IANAL but probably other things
Comments are closed.