When it comes to a sound certification practice, commercial and military avionics are light years ahead of the pack. DO-178 certification, first introduced in the 1980s, represents the gold-standard, requiring companies to comply with software processes that mandate requirements traceability, software architecture and coding guidance, comprehensive testing of all code, and the production of certifiable products. Both commercial and military industries boast the healthiest record on system safety. And, largely due to these processes, projects such as the Joint Strike Fighter (JSF) are recognized for the highest levels of design and safety integrity.
Given this, is adding Common Weakness Enumeration (CWE) to an already stellar record simply overkill, or is it really necessary?
CWE is a formal list of software weakness types created to: serve as a common language for describing software security weaknesses in architecture, design, or code; offer a standard measuring stick for software security tools targeting these weaknesses; and provide a common baseline standard for weakness identification, mitigation, and prevention effort.
In other words, it’s more than a list of security weaknesses. It’s a “language” for communicating the details of security weaknesses. The “language” enables users to describe the weaknesses in detail, classify them, and measure security tools in their ability to uncover security weaknesses.
In contrast, the typical programming standard seeks to expose common errors, architectural weaknesses, and unexpected runtime errors. Specifically, at the highest level of compliance, DO-178 is geared to address 66 objectives that represent best practices for engineering safety-critical systems. Because the standard has repeatedly proven to deliver high-integrity systems, the standard is stable and scheduled to receive only its third update in 30 years.
CWE, on the other hand, focuses on providing protection from the constantly changing security threats that attack today’s highly connected systems. CWE offers guidelines to protect systems from the weaknesses that lead to such security vulnerabilities. Its list of weaknesses enables companies to discuss, find, and contend with causes of software security vulnerabilities as they are manifested in code, design, and architecture using a common language. Buyers can demand specific CWE conformance, and vendors—once proven conformant—can publicly describe their tools as matching specific levels of CWE assurance.
Although it’s tempting to assume rigorous DO-178B processes are above reproach, CWE offers an altogether different competency. DO-178 is focused on the process of building safety-critical software. CWE keeps software secure. As devices, whether a guided missile, a drone, or a Navy ship gets more connected, the vulnerability to security breaches increases exponentially. With 70 percent of those security vulnerabilities rising from programming errors, it’s time to recognize that we’re in an era where connectivity necessitates both standards.
Chris Murray ([email protected]), vice president of business development at LDRA in San Bruno, Calif., boasts more than 20 years of experience in software.
