In the world today, we are relying more and more on the safety and security of software systems. When we get into a recently made car, the braking and control systems depend on complex software. When we enter the polling booth, we increasingly encounter machines that depend on software for recording our votes correctly.
The traditional view of safety-critical software is that it is concerned with avoiding logic bugs that could cause loss of life, whereas security concerns are about preventing unauthorized access and tampering.
But are these two concerns really different? I participated in the design of Ada 95, one of the only programming languages that specifically targets safety and security concerns [there is an annex of the Standard with the title "Safety and Security"]. We talked to experts and were struck by the fact that there seemed to be two different communities that did not talk to one another very much but had very similar technical concerns. Originally, we thought perhaps we would have separate annexes for safety and security in the Ada Standard, but we really couldn't see a clear technical distinction.
In the modern world, I would argue that it is wrong—and perhaps even dangerous—to separate these concerns. In a post-9/11 world, it's hard to imagine any safety-critical system where one can feel free to ignore the possibility of malicious intrusion. On an episode of "Alias," we see the CIA super hacker flying for the first time and nervous, hacking into the flight system at takeoff to ensure the pilot has completed the checklist properly. Entertaining or worrisome? Let's hope that this is indeed just fiction, but I think we can't rely on hope these days. Was the avionics system on this plane specifically designed with intrusion detection and avoidance in mind? I would guess not.
What about the other way around? There are lots of security-critical systems that don't seem to be directly linked to possible death or injury. But a lot hides behind the word "directly." You would have to be completely oblivious to the political developments of the last few years to disagree with the obvious link between elections, democracy, and life-and-death issues. In our heavily interlinked economy, software failures can cause serious collateral damage—a telephone system fails, preventing a 911 call? An error in an accounting system causes pensions to be wiped out? A failure in software evaluating a drug trial allows dangerous drugs on the market? You can easily add many items to this list.
It's time we merged the experience and skills of the two communities, as well as merging standards and procedures. We also need to recognize that safety and security are major concerns in much of what we do in the software field. We need to change the way we educate students. Very often students come out of school knowing very well how to fiddle around on the Web, but have no idea how one goes about writing large-scale, totally reliable software. We also need to examine our tools and environments. It would be a good start if languages other than Ada decided to concentrate on these issues (or if more people used Ada!). A search for safety or security in most language Standards yields a depressing blank.
