From integrating cybersecurity into established airborne software development processes to addressing the challenges of multicore verification, SYSGO joined the High Integrity Software Conference (HISC) 2026 in Birmingham to explore some of the key challenges facing modern avionics engineering.

On 13 October 2026, the High Integrity Software Conference (HISC) brought together experts from the safety-critical software industry at The Vox in Birmingham, UK. As aircraft systems become increasingly connected, software-intensive and computationally demanding, the development of reliable and certifiable software architectures continues to present new challenges.

SYSGO participated in the conference with a technical presentation titled "Secure and Safe Software – Integrating Security into Safe Airborne Software Development" and a joint demonstrator with technology partner TASKING, highlighting two closely related aspects of modern avionics development: the integration of Safety and Security requirements and the verification of complex multicore systems.

Multi-Core Avionics: From Execution to Verification

Modern avionics increasingly rely on multicore processors to consolidate functions, improve performance and reduce size, weight, power and cost (SWaP-C). However, sharing computing resources between applications with different criticality levels introduces challenges, particularly when it comes to ensuring predictable execution and preventing unwanted interference.

Together with TASKING, SYSGO presented a joint demonstrator based on the PikeOS real-time operating system and hypervisor. The demonstrator combined mixed-criticality execution, time and space partitioning, and multicore interference analysis and verification.

PikeOS provides the architectural foundation for running multiple applications with different criticality levels on a shared hardware platform while maintaining separation between their execution environments. Complementing this architecture, the demonstrator highlighted how interference between applications running on different processor cores can be analyzed, tested and verified.

The collaboration illustrated an important principle for future avionics platforms: It is not enough to execute critical applications in isolated environments; engineers must also understand and verify how shared multicore resources can influence system behavior.

While the demonstrator focused on multicore execution and verification, SYSGO's conference presentation addressed another fundamental challenge: how to incorporate cybersecurity into software development processes that have traditionally focused on functional safety.

Two Sides of the same Goal: Safety and Security in Aviation

For decades, aviation software development has been guided by one central objective: ensuring that aircraft systems operate safely, even when individual components or functions fail. Standards such as DO-178C have established rigorous development and verification processes to achieve this objective. Through structured requirements, traceability, verification activities and Design Assurance Levels (DALs), engineers can demonstrate that software has been developed with the assurance appropriate to its safety-critical functions.

However, traditional safety engineering primarily addresses failures arising from design errors, implementation defects or other unintended conditions. Cybersecurity introduces a different category of risk: deliberate attempts to manipulate software, compromise data or interfere with system behavior. An aircraft system may have been developed according to stringent functional safety requirements and still contain vulnerabilities that an attacker could exploit. This is where the relationship between Safety and Security becomes particularly important.

During its HISC presentation, SYSGO explained why the two disciplines should not be treated as independent engineering activities. Although they address different sources of risk, they ultimately share a common objective: preventing unacceptable consequences for the aircraft and its occupants.

Security is therefore not simply an additional feature of airborne software. It becomes an essential part of maintaining its safety throughout the operational lifecycle.

Extending the Safety Lifecycle with DO-326B and DO-356A

The aviation industry has developed dedicated guidance to address cybersecurity within the airworthiness framework. In particular, DO-326B introduces an approach to managing aviation security risks that could affect aircraft safety, while DO-356A provides supporting guidance for implementing and assessing security measures.

Rather than replacing established safety development processes, these frameworks extend them. The underlying principle is to introduce security considerations into the existing lifecycle, from initial system analysis and requirements definition through implementation, verification and continued assurance.

A central activity is the security risk assessment. Engineers first identify the system assets, interfaces and operating environment that require protection. They then examine potential threat conditions and attack scenarios, assess their implications for aircraft safety and derive appropriate security requirements. These activities introduce a perspective that is not fully covered by traditional failure analysis: not only what might go wrong, but also how someone could intentionally make it go wrong.

The assessment determines which protective measures are required and how their effectiveness must be demonstrated. Security Assurance Levels (SALs) provide assurance expectations for the development and verification of these measures, complementing rather than replacing the familiar safety-oriented DAL framework. Importantly, this is not a one-time assessment. Security development is an iterative process in which risks, protective measures and verification results must be evaluated repeatedly until the remaining risks are considered acceptable.

As the presentation emphasized, security requirements can also influence decisions made at higher architectural levels. A vulnerability identified during implementation may require changes to the system architecture, interfaces or operational concept. Integrating these considerations early in development can therefore reduce the risk of expensive redesigns and help establish a consistent approach to both Safety and Security assurance.

Common Criteria: Building on existing Security Evidence

Another important topic of the presentation was the relationship between aviation-specific security guidance and Common Criteria, the internationally recognized framework for evaluating IT product security under ISO/IEC 15408. Where DO-326B and DO-356A address security in the context of aircraft airworthiness, Common Criteria provides a structured method for evaluating security properties of IT products across industries. 

Common Criteria evaluations are based on defined security claims, expressed through documents such as Protection Profiles and Security Targets, and assessed against the identified Target of Evaluation. Although these frameworks serve different purposes, they share several underlying principles, including systematic threat analysis, documented security requirements, independent evaluation and the collection of verifiable evidence. This creates opportunities to reuse existing Common Criteria evaluation results when preparing evidence for aviation security assurance.

For developers working with certified software components, such reuse can be particularly valuable. Instead of starting every security assessment from the beginning, existing evaluation documentation may provide a foundation for demonstrating selected security properties.

However, SYSGO also highlighted that Common Criteria certification does not automatically establish compliance with aviation cybersecurity requirements. Differences in scope, assumptions, operational environments and assurance objectives must be considered carefully. Additional evidence may be required, particularly concerning software authenticity and integrity, protection of configuration management activities, and vulnerabilities in the tools and technologies used throughout development.

The practical benefit lies in understanding where the frameworks overlap and where aviation-specific requirements demand additional work. For an RTOS and hypervisor provider such as SYSGO, this relationship is especially relevant. PikeOS combines safety-oriented real-time execution and partitioning capabilities with security-oriented isolation mechanisms, providing a foundation on which developers can build systems requiring both forms of assurance.

When Security Mechanisms challenge Safety Requirements

One of the most interesting aspects of the HISC presentation addressed a less obvious engineering problem: security mechanisms that are effective in conventional IT systems are not necessarily straightforward to introduce into safety-critical avionics software. In many IT environments, cybersecurity aims to make exploitation difficult by introducing unpredictability, detecting abnormal behavior and enabling rapid software updates.

Safety-critical software, by contrast, depends heavily on determinism, reproducibility and stable, verifiable configurations. Aircraft software must often demonstrate predictable timing behavior, controlled memory usage and repeatable execution characteristics. Even relatively small changes to compiled code or runtime behavior can introduce new verification requirements.

This creates a challenging situation: a mechanism introduced to improve security may also affect the very properties needed to demonstrate functional safety. SYSGO illustrated this conflict through three practical examples.

Control Flow Integrity: Security Checks with Timing Implications

Control Flow Integrity (CFI) protects software against attacks that attempt to redirect program execution to unintended locations. By verifying that execution follows permitted control-flow paths, CFI can help prevent certain attacks involving manipulated function pointers, return addresses or other control-transfer mechanisms.

However, the necessary checks may introduce additional instructions into the compiled software and increase execution time. For safety-critical applications, these changes cannot simply be ignored. They may affect worst-case execution time analysis, code traceability and the verification of the final executable.

Additional metadata or runtime dependencies may also need to be considered in the system's isolation architecture. Possible approaches include carefully controlling where CFI is applied, evaluating its timing impact and separating applications into partitions with clearly defined access permissions.

Stack Protection: Balancing Randomization and Reproducibility

Stack canaries are another widely used protection mechanism. They place a guard value within a function's stack frame to help detect certain forms of stack corruption before execution returns to the calling function. If the guard value has changed unexpectedly, the software can initiate a defined error-handling response.

In conventional software, randomized canary values can make attacks more difficult. In safety-critical environments, however, generating and managing these values introduces additional considerations. The required entropy source, runtime initialization and compiler-generated checks may influence reproducibility, execution timing and the evidence required for certification.

Alternative or complementary approaches, such as protected memory guard pages and strictly bounded memory operations, can provide different ways of addressing related risks. The appropriate solution depends on the application architecture, hardware capabilities and safety requirements.

Address Space Layout Randomization: Unpredictability Meets Determinism

Address Space Layout Randomization (ASLR) is designed to make certain attacks more difficult by changing the memory addresses at which software components are loaded. An attacker attempting to exploit a known address cannot necessarily rely on finding the same code or data at that location.

For conventional operating systems, this is a familiar defense mechanism. In certifiable avionics software, however, changing memory layouts may complicate debugging, execution-time analysis and the reproducibility of verified configurations. Different layouts may also influence memory-access behavior and make it more difficult to establish consistent evidence for system performance. These challenges do not necessarily make ASLR unsuitable for airborne applications. They underline the need to evaluate security mechanisms in the context of the safety-critical execution environment.

Across all three examples, the message was consistent: Security improvements must not undermine the safety properties that the system is required to guarantee. Successful integration requires an architecture that accommodates both disciplines, supported by appropriate analysis, verification and configuration control.

Partitioning as a Foundation for safe and secure Architectures

Many of these challenges can be addressed more effectively when Safety and Security are considered at the architectural level. A separation-kernel-based architecture creates defined boundaries between applications, helping to control access to memory, processing resources and communication interfaces.

With PikeOS, applications of different criticality levels can operate in separate partitions on a shared hardware platform. For example, a safety-critical avionics function and a Linux-based application can coexist without being granted unrestricted access to one another. This separation helps contain faults and supports the implementation of security policies that restrict how software components can interact.

It also allows system designers to evaluate the requirements of individual partitions and determine which security measures are appropriate for their specific roles. Not every application necessarily requires the same protection mechanisms or assurance activities. What matters is that the overall architecture provides a controlled and verifiable environment in which the security of one component does not compromise the safety of another.

Partitioning alone does not eliminate all cybersecurity risks or multicore interference effects. Nevertheless, it provides an important foundation for limiting interactions, managing complexity and establishing evidence for safety- and security-critical systems.

Bringing Safety and Security together from the Beginning

The development of modern avionics software is increasingly characterized by converging requirements. Greater connectivity expands potential attack surfaces, multicore processors introduce new verification challenges, and evolving security expectations place additional demands on established certification processes. The central lesson from SYSGO's presentation at HISC 2026 is that Safety and Security cannot be addressed successfully as separate concerns.

Standards such as DO-178C, DO-326B and DO-356A provide complementary guidance, while Common Criteria evaluations can contribute valuable security evidence when appropriately mapped to aviation requirements. At the technical level, mechanisms such as CFI, stack protection and ASLR illustrate why security decisions must always account for deterministic execution and certification constraints. By combining sound development processes with carefully designed system architectures, developers can address these challenges without losing sight of the requirements that make airborne software dependable.

For SYSGO, HISC 2026 provided an opportunity to share this perspective how isolation, multicore execution and verification can be brought together in practice. As avionics platforms continue to evolve, the challenge is no longer simply to develop software that is safe or secure. It is to engineer systems in which Safety and Security reinforce each other throughout the entire lifecycle.