Military Embedded Systems

Migrate safely using source code analysis


September 19, 2008

Gwyn Fisher


What can developers of military and avionics software systems do to take advantage of software reuse while ensuring that software is as bug-free and secure as possible?

What can developers of military and avionics software systems do to take advantage of software reuse while ensuring that software is as bug-free and secure as possible?

It's not exactly a national security secret that software gets used and reused within the military and aerospace industries across different programs. This is a tried and true approach to software development. The GAO's March 2004 report to the U.S. Senate estimates software reuse at up to 70 percent on some projects, which presents significant opportunities in terms of cost savings and efficiencies. However, migrating this quantity of software is not without risk, particularly when destined for safety- or mission-critical software applications. So, the question is this: What can developers of military and avionics software systems do to take advantage of software reuse while ensuring that software is as bug-free and secure as possible?

Migrating software for use on new systems and combining with newly developed code present huge challenges for mission-critical systems. First and foremost are the size and scope of software systems today. The U.S. Army's Future Combat Systems (FCS) is estimated to deliver more than 60 million lines of software code in the end-product. Avionics software on the latest commercial jets runs into the many millions of lines of code; the software that runs the Boeing 787 approaches 7 million lines of code, triple that of the 777. To properly test software projects of this size, which have essentially an unlimited number of code paths to consider, is not trivial, especially when designed for use in a mission- and safety-critical context.

Added to this migration challenge is the fact that even though the code is being reused and would likely be considered stable after years of field operation, it is often operating in a new context or environment. This provides the possibility of formerly latent bugs turning into active, critical bugs and formerly safe coding practices becoming high-risk security vulnerabilities. This is not a theoretical discussion. This exact issue happened to the European Space Agency (ESA) with the launch of the Ariane 5 spacecraft, which reused code from its predecessor, Ariane 4. The code operated safely within the older craft, but the execution context changed, changing a "theoretical" or latent bug in the Ariane 4 into a critical bug that caused the crash of the Ariane 5. The same is true with security vulnerabilities: Coding practices from years ago in non-networked systems can become extremely high-risk vulnerabilities when deployed in a modern software context where systems are networked in a secure, mission-critical environment.

Software risk is well known to professionals in the industry, with the civilian aerospace software industry subject to the DO-178B regulations governing software development and verification requirements. These types of guidelines exist in many industries where safety requirements are paramount for software being developed. The challenge for software development professionals in these industries is finding the right mix of tools and processes that will address the unique challenges of reusing large amounts of code while being able to scale to the size and scope of mission-critical systems.

A growing trend in mission-critical software development is the adoption of Source Code Analysis (SCA) as a technology to augment (or even replace) traditional source code verification techniques such as peer code reviews, which aren't able to scale. SCA is a bug-detection technology that requires no test cases, is fully automated, and allows developers to inspect their source code extremely early in the development life cycle, ensuring that bugs aren't propagated downstream causing unwanted quality and efficiency headaches. The underlying technology associated with SCA is called static analysis, and the current generation of technology solutions is capable of providing sophisticated, fast, and accurate analysis that locates and describes areas of weakness in source code, including memory and resource management, program data management, buffer overflows, unvalidated user input, vulnerable coding practices, and concurrency violations, along with a variety of longer-term maintenance issues.

SCA is distinct from traditional dynamic analysis techniques, such as unit or penetration tests, because the work is performed at build time using only the source code of the program or module in question. The results reported are therefore generated from a complete view of every possible execution path, rather than some aspect of a limited, observed runtime behavior. This is particularly valuable in a legacy migration context where SCA can inspect hard-to-test areas such as error handling routines. SCA will also report on "potential" issues so that senior developers can ensure that changes in runtime context through reuse haven't created new sources of errors. When combined with existing testing and software validation techniques, SCA provides a scalable, efficient solution to large-scale verification of source code.

As the complexity of software explodes and its mission-critical nature continues to increase, the future of software testing and validation lies in continued automation. New forms of validation will extend the depth and breadth of technologies such as SCA and will combine them with other forms of software testing to deliver technology that creates innovative, comprehensive approaches to software validation.

Gwyn Fisher is Chief Technology Officer at Klocwork and has more than 20 years of global technology experience. He can be contacted at [email protected].


Featured Companies


Perforce Software Headquarters 400 First Avenue North #200
Minneapolis, MN 55401