Don't blame Willy the Mailboy for software security flaws
In defense of developers
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?
Next page: Uncertain certification
Puts the kibosh on 3rd party libraries?
So I develop some applications. Being an efficient kinda guy, I don't write all the software (down to the interrupt routines that handle the video controller) myself. I rely to a large extent either on code that already exists in the O/S, or code that exists in high-level libraries from thrid parties: possibly supplied with the development suite I use. Further, I don't inspect every piece of source from these libraries - or even just the version I developed on - for any weakeness. Where does that leave me in terms of being liable for any security holes? Maybe holes in the libraries, or because I use them in ways that are unorthodox (although still in compliance with the API)
Unless you turn the whole world of software development into a chartered profession, with errrr, professionals who carry the whip (as opposed to their managers doing the lashing) and have the authority to demand certain development practices, this sort of professional liability can never be made to stick. Imagine the situation where a product design meeting takes place. The marketing peeps say they "need" a new product to compete with thier rivals. The softies say: "fine, but unless YOU accept liability for any and all security flaws, it will take 4 years to develop and cost 8 times as much, in professional fees, accredited methodologies, external audits, testing, re-testing and final certification." Under these circumstances, can you see any new software ever being developed - or will we have time-travelled back to the 60's where software was held in awe - and not just because of its price?
Some years back I had the dubious pleasure of fixing some POS written by a helpful chap who'd called the first variable he'd used "ONE", the second "TWO", etc.
If that sort of thing's supposed to be the way forward I think I'll give this shit up and take up something easy and safe. Like naked alligator wrestling.
...or, failing that, a fuckton of cash.