Chief security officer Mary Ann Davidson has hit out at an industry in which "most software people are not trained to think in terms of safety, security and reliability." Instead, they are wedded to a culture of "patch, patch, patch," at a cost to businesses of US$59 billion, she said.
"What if civil engineers built bridges the way developers write code?" she asked. "What would happen is that you would get the blue bridge of death appearing on your highway in the morning."
Speaking at the WWW2006 conference in Edinburgh, Scotland, on Thursday, Davidson also touched on the wider subject of the state of the software and security industries.
The pressure to deal with the problem of unreliable and insecure software is building, and the industry has reached a "tipping point," she said.
It is now "chief executives who are complaining that what they are getting from their vendor is not acceptable, in terms of software assurance," Davidson said.
Things are so bad in the software business that it has become "a national security issue," with regulation of the industry currently on the agenda, she said. "I did an informal poll recently of chief security officers on the CSO Council, and a lot of them said they really thought the industry should be regulated," she said, referring to the security think tank.
But if regulation is coming, the industry has only itself to blame, she said.
"Industries don't want to be regulated, but if you don't want to be regulated, the burden is on you to do a better job."
Davidson also hit out at the "hacking mentality," and the incidence of exploits that could cause "a million dollars worth of damage...passed around freely at conferences." She said there was a major difference between people working in the software business and engineers who "are trained to think in terms of safety, security and reliability first."
She claimed that the British are particularly good at hacking as they have "the perfect temperament to be hackers -- technically skilled, slightly disrespectful of authority, and just a touch of criminal behaviour."
Colin Barker and Jonathan Bennett of UK.Builder.com reported from London.
Buggy software is inevitable.
Mathematically it becomes an impossible task to prove code is correct when the code body grows beyond a couple hundred thousand lines. "Perfect" code is just too costly in time to try to achieve.
That being said, proper design, coding standards and practices and a well thoughtout and designed test plan implemented from the outset can significantly reduce the volume of the typical "sloppiness" bugs. Too often the design factor of a programming project is given too little attention and is treated with a "we design it as we build it" attitude. That kind of thinking leads to a lot of interoperablity type bugs; pieces just don't fit and work well together, hence a lot of patches to make things work.
By setting forth good code standards and practice, lots of vunerabiltiy issues are avoided (proper memory management, parameter handling, etc). With the development team using the same tight practices, a whole class of bugs are minimized.
What often amazes me is how little engagement is offered to the test team at the beginning. The test suite needs to be designed at the same time as the function components of the product are being designed. This means that the test development team needs to be engaged by the product architects early on so they know what to build the test suite to do.
Testing is expensive and time consuming. A good test engineer is worth their weight in gold. Pressuring these people to meet artificial schedules is a recipe to disaster. The company has to plan for and be prepared to spend the time and money necessary to hold to an appropriate schedule, and when bugs are found late in the project schedule, reward those who find these potentially disasterous bugs before the project ships rather than punishing them for cause a slip in the schedule.
Just my two cents worth. "Been there, done that, ain't goin' back no more."