The Volkswagen case has opened a can of worms. Fingers are being pointed at this very reputed company and already many heads have rolled. But one thing we all are forgetting that this is not just a failure of Volkswagen as a company, it is a failure of the whole software development ecosystem starting from coders and ending with auditors from regulatory agencies.
Traditionally, we all have been developing software in a defined way. Coders are given the specifications, they develop the code, do the unit testing, integrate the modules and prepare all the documents (rather unwillingly) and their job is done. The internal quality teams and external auditors have a check list of documents and they verify whether all documents are in place or not. If they are there, they certify that software as conforming to standards. This whole process is flawed. Nobody cares what the software is doing internally. Take this –
A militant-minded person joins an organisation and starts working on a flight control software. He develops a module that will only activate when the plane has travelled 1 million miles. It fires up then and shuts down the plane software. Another mischievous coder works on a patient database and creates a small application that lets all the patient data to be transmitted to an external network when the database size has exceeded 1000 times. A car’s breaks is made to fail when the car has been refuelled 100 times. People can write software to disrupt traffic lights, stop moving trains, stop elevators, disrupt financial transactions and of course tamper emission data. All of these can go undetected for many years as Volkswagen engineers have proved to the world. This is a real security threat- not from outside hackers and viruses. This is coming from within the organization. This I call Software Terrorism. I might be exaggerating, but in this world of IoT and M2M, nobody can deny that this threat is for real.
What is the way out? Handling software terrorism requires three major actions.
- The first is use of open source software as much as possible. People should be able to dive “into” the software and see what is happening. The proponents of closed software will immediately stand up and counter this saying – what about confidentiality and business interest? Come on – do you thing that somebody comes to see all the windows code, she/he will be able to create a new Microsoft?
- Second is the role of Quality systems inside an organization. My past experiences say that most of the quality systems folks are obsessed with documentation and they take decisions based on that. That is as wrong as it can get. A quality organization should have a composite structure – Testers, regulatory experts, external auditors. It should work very much like board of directors work for an organization.
- The role of Auditors – and this requires the biggest change. Why does it take 5 years to catch an emission scandal from millions of cars? Who certified them to run on our roads? On what basis the certificates were issued? Is banning the cars and putting fine on the company is enough? Obviously not. Auditors need to redefine their roles. They need to get involved much earlier in the SDLC and try to go into each and every module, keep a tab on the number of lines, the interaction between the modules, test cases and internal testing done by the organization. They need to realize that software terrorism is for real and then screen all codes (passengers) as religiously as they do in US airports.
Experts’ views are welcome!
