There's a low rasp of a noise being made in the software world. Customers want software vendors to hold programmers responsible if they release code containing security flaws.
Actually, that's not strictly true. Security vendors want customers to start wanting software vendors to hold the programmers responsible.
As we recently reported, the annual Top 25 programming errors announcement urged customers to let software vendors know that they want secure products. This desire is captured and bottled in a draft Application Security Procurement contract provided by security certification vendor SANS. The majority of the contract discusses liability in terms of the vendor. But the occasional clause stands out, like this one:
Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application...
In other words, when it comes to application security and QA, the buck stops with the developer. And that's in a contract that likely won't even be seen by the developer and will be signed on his behalf by his employer. It renders the contract unenforceable - so why add a clause like that in the first place?
It reminds me of the Dilbert book Bring Me the Head of Willy the Mailboy. No one wants to take responsibility, so the blame is passed down through the ranks in an Ayn Rand-ian shoulder shrug, until the atomic unit in the trenches (the programmer) is reached. The process has failed, management has failed, QA has failed and the customer's blood is boiling. So the answer's obvious: sue the little guy!
That said, no one's saying that programmers should be impervious to blame. Those dilettantes who refuse to adhere to corporate guidelines can still be fired after all. But it's understandable that managers want some formal assurance that their staff have a penny's worth of discipline on the job.
So what's the answer to? Certification in some vendor or another's technology stack?