In the early days of avionics, software operated in silos, or isolated computing environments with little to no outside connectivity. Today, modern airborne systems are increasingly linked to maintenance systems, passenger networks, and cloud-based analytics.

While this connectivity drives operational efficiency, it transforms cybersecurity from an IT concern to a fundamental safety risk. A single vulnerability in a communication link is no longer just a data threat, but instead is a potential flight-safety hazard. As the boundaries between safety and security blur, developers must adopt a unified approach to ensure airworthiness.

The regulatory shift: Beyond DO-178C

For decades, DO-178C has been the gold standard for avionics software safety. However, safety standards alone are no longer sufficient to address intentional malicious interference. The industry has responded with a more robust regulatory framework:

DO-326B (Airworthiness Security Process Specification) defines the processes and activities for identifying and mitigating cybersecurity vulnerabilities
DO-356A (Airworthiness Security Methods and Considerations) provides guidance and objectives to meet the requirements for each safety assurance level (SAL).

Simply put, DO-326B calls out DO-356 as the set of objectives for security and prescribes a process; the earlier DO-326A was less clear. Together, these standards complement DO-178C. They recognize that whether a system failure is caused by a random hardware fault (safety) or a deliberate buffer overflow (security), the loss of system integrity is the same.

Five steps to safe and secure software development

To navigate this complexity, developers should move from fragmented workflows to an integrated model. Consider these five essential steps to building safe and secure aerospace software.

1. Establish a standards-compliant coding foundation: Airworthy software begins with a deterministic foundation. General-purpose C or C++ often contains so-called undefined behaviors that are unacceptable in flight-critical systems. Developers should use language subsets like MISRA C:2023, which prohibit risky features such as dynamic memory allocation or nondeterministic timing.

By using static-analysis tools to gate code, teams can prevent logic from entering the repository unless it is proven free of common vulnerabilities, such as those listed in CWE [Common Weakness Enumeration] or the CERT C coding standard. This process ensures that the code is inherently robust against both glitches and exploits from the very first line.

2. Build continuous verification into the life cycle: Verification should not be a final hurdle before certification. Instead, incorporate dynamic analysis and structural coverage into daily development. Developers must prove that every line of code is not only functional but necessary. In aerospace, dead or unused code isn't just inefficient – it’s a security backdoor and a safety liability. Continuous unit testing ensures that as the codebase grows, its integrity remains intact.

3. Link safety and security evidence: Treating safety and security as separate streams leads to duplicated effort and noncohesive documentation. A unified workflow enables engineers to analyze structural behavior once and interpret the results through both the DO-178C and DO-326B lenses. For example, a tool that identifies an open network port (a security vulnerability) can immediately flag its impact on a flight-control module (a safety hazard). Doing so provides a single, coherent source of truth for auditors.

4. Maintain end-to-end traceability: Traceability is the map of the software. Every line of code must be traceable back to a high-level requirement. If a requirement changes – such as an update to a flight envelope – traceability tools enable engineers to immediately see which modules, test cases, and safety artifacts are affected. This bidirectional link ensures that the system does exactly what it is intended to do – and nothing else.

5. Use integrated, qualified toolchains: The most critical step is the use of an integrated toolchain, defined as compilers, debuggers, and verification tools that are qualified for use in aerospace.

A qualified compiler is essential because it is proven to translate source code into object code without introducing hidden optimizations that could bypass safety checks. When integrated with a debugger, it allows for high-fidelity, nonintrusive observation of the software on target hardware. This method ensures that testing occurs under flight-like conditions, monitoring real-time CPU loads and latencies without altering system timing.

A future-proof approach

As the aviation industry moves toward a more autonomous and connected future, the cost of stitching together security and safety only at the end of a project is too high. By adopting these five steps, development teams can reduce rework, satisfy regulators like the FAA and EASA more efficiently, and – most importantly – ensure that the next generation of aircraft is as secure as it is safe.

Jay Thomas is senior director of field engineering for TASKING.

TASKING · https://www.tasking.com/