Can software developers be protected from themselves?

2007-12-12

It's now six weeks since RSA Europe, when I made a diary note to take a deeper look at the SAFECode forum. SAFECode stands for the Software Assurance Forum for Excellence in Code - we can be profoundly grateful that the founders didn't try to expand out the entire acronym. It also stands for "increasing trust in information technology (IT) products and services through the advancement of proven software assurance methods" - a kind of Green Cross man of the IT world, helping software developers across the highly risky freeways of the technologcal world.

The SAFECode idea is to co-ordinate software best practices across software vendor companies, build in appropriate checks and balances to ensure the resulting applications are secure (or at least, to minimise the risks). Is it necessary? Where there's smoke there's fire, and to be sure, Microsoft is no longer the only target of cyber-attacks. As hackers mature into commercial operators, no longer motivated (just) by "giving it to the man," an ever-widening pool of programs is coming under threat.

In principle, then, SAFECode is a good, worthy and valuable idea. It is by no means guaranteed to succeed, for a number of reasons. Don't get me wrong - of course it will be a good thing to co-ordinate and share best practice. From the point of view of its longer term success there are several howevers, based around:

- Credibility. To succeed, the SAFECode forum requires to be seen as successful. This is a conundrum but it isn't new - consider the ITIL library of systems management best practice, which has taken a good 10 years to establish itself. It may be that SAFECode by itself proves inadequate because it focuses only on security, and quickly runs into the weeds as it tries to integrate with the wider picture of software development, which is itself peppered by competing best practice, from waterfall to RUP to agile.

- Critical mass. While there are big hitters in the list (from the site: EMC Corporation, Juniper Networks, Inc., Microsoft Corporation, SAP AG, and Symantec Corp.), the number of members is not yet adequate to cause a mass adoption or understanding of the best oractices it wants to espouse.

- Clarity. SAFECode can perhaps learn from the mistakes of other forums - notably in this case ITIL - by opening its documents to the widest possible audience. A quick glance at the publications page indicates that the organisation does not yet have anything to tell people, not in terms of best practice. The wrong thing to do hereon in would be to make any publications for members only, or indeed available only for sale. Commerciality will get in the way of SAFECode's mission, if not scuppering it already.

- Collaboration. The technology world has come a long way since the smoke-filled rooms in which many best practice standards have been conceived. We have ridden the open source wave and now we are in the midst of a new era of collaboration, as illustrated by social networking. The fastest route to success (and I'm not always a fan) for SAFECode would be to build a Wiki, and open it up as widely as possible with appropriate editorial responsibility. While noise to signal would have to be managed, this would aid both visibility of the process and road-testing of the results

- Certification process. Without some kind of certification, SAFECode members do not have to prove anything for themselves, nor would there be any kind of recourse should SAFECode practices not be kept. Certification needs to have teeth - while anyone can join the forum, only products that fulfil appropriate criteria should be marked as "SAFECode certified", and only organisations that continue to apply the best practices should be able to maintain their member status.

In summary, then, all initiatives such as SAFECode should be applauded. However, the forum should be judged not on its existence alone, but on its ability to change how applcations are written - and ultimately, on whether the risks posed by member applications are reduced. This may seem like a tall order but if SAFECode can't provide some kind of guarantee, then it will be of little use. Not only this, but its currency will very quickly devalue, to the detriment of its founders and the credibility of their products.