Cyber Resilience Starts With Software Engineering

For many years, cyber resilience has largely been viewed through the lens of security controls, monitoring, governance and compliance. While these remain important, they represent only part of the picture.

Increasingly, the resilience of critical systems is being determined much earlier in the lifecycle by software architecture, technology choices, systems integration decisions and the ability to maintain software over decades of operation.

The proposed UK Cyber Security & Resilience Bill and the UK Software Security Code of Practice both point in the same direction: cyber resilience must be engineered into systems from the outset rather than added later.

For organisations operating critical infrastructure, that shift has significant implications.

One of the defining characteristics of critical infrastructure is longevity.

Rail signalling systems, industrial control systems, defence platforms, transport systems and utilities infrastructure are often expected to remain operational for decades. Yet the software, hardware and development environments on which they depend evolve at a dramatically faster rate.

This creates a growing disconnect between the operational life of infrastructure and the lifecycle of the technologies embedded within it.

Historically, this was viewed primarily as an obsolescence issue. Today it is increasingly becoming a cyber resilience issue.

Many organisations are discovering that software and hardware require replacement not because they have failed, but because they can no longer be adequately secured, supported or maintained.

The UK Government’s response to the Software Security Code of Practice consultation highlighted that 59% of organisations globally are believed to have been impacted by a software supply-chain attack or exploit, yet only 11% of businesses assess risks posed by immediate suppliers.

The implication is clear: software lifecycle management and supply-chain understanding are becoming fundamental components of cyber resilience.

The Software Security Code of Practice places significant emphasis on secure-by-design principles.

At first glance this may appear to be a software development concern. In reality, it is a systems engineering challenge.

Cyber resilience is influenced by decisions made long before a system enters service, including:

• Software architecture
• Interface design
• Technology selection
• Third-party dependencies
• Verification strategies
• Update mechanisms
• Systems integration approaches

Many organisations understand these principles. The challenge is applying them within complex operational environments where legacy systems, operational constraints and long asset lifecycles must also be considered.

This is particularly true within critical infrastructure, where replacing a system is rarely straightforward and where changes often carry operational, safety and regulatory implications.

A resilient system is not simply a system that is secure today.

It is a system that can still be understood, maintained, tested, modified and supported years into the future.

Many organisations possess source code but no longer possess the build environments, test frameworks, engineering knowledge, configuration baselines or specialist tooling required to safely evolve their systems.

Over time:

• Original engineering teams retire
• Suppliers cease trading
• Development tools become obsolete
• Documentation becomes incomplete
• Knowledge gradually disappears

As software lifecycles continue to shorten while infrastructure lifetimes continue to extend, engineering resilience is becoming an increasingly important part of cyber resilience.

This is an area that receives far less attention than vulnerabilities and threat detection, but it often determines whether organisations can respond effectively when change becomes necessary.

Cyber security discussions often focus on vulnerabilities, threats and incidents.

Less attention is paid to the engineering capability required to support software over time.

Questions organisations should be asking include:

• Can we still build the software?
• Can we still test it?
• Do we understand how it behaves?
• Are the original development tools still available?
• Can security updates be implemented safely?
• Do we understand all external dependencies?

In many cases, source code still exists, but the surrounding engineering ecosystem has disappeared.

Compilers, build environments, test harnesses, simulators and specialist diagnostic tools may no longer be available.

The result is that seemingly small software changes become increasingly difficult, expensive and risky.

For many organisations, cyber resilience and obsolescence are still managed as separate challenges.

In practice, they are becoming increasingly interconnected.

The same factors that create software obsolescence often create cyber resilience risks:

• Unsupported operating systems
• Unsupported software libraries
• Obsolete development tools
• Disappearing technical knowledge
• Inability to test or modify software safely
• Loss of supplier support

A system does not need to fail in order to become a risk.

It may continue to operate exactly as intended while becoming progressively more difficult to maintain, secure and evolve.

As a result, organisations are increasingly discovering that software lifecycle management, obsolescence management and cyber resilience are no longer separate disciplines. They are different perspectives on the same underlying challenge: how to maintain confidence in software-intensive systems over long operational lifecycles.

This is particularly relevant for organisations operating long-life infrastructure, where software may remain operational for decades while the technologies, tools, suppliers and security expectations around it continue to evolve.

One of the most significant trends emerging across critical infrastructure is that cyber security is becoming a direct driver of obsolescence.

Historically, systems were replaced because they failed functionally or became unreliable.

Increasingly, systems are being replaced because they can no longer meet modern security expectations.

Examples include:

• Unsupported operating systems
• Unsupported software libraries
• Insecure communication protocols
• Inability to implement security patches
• Lack of secure update mechanisms
• Regulatory and compliance requirements

This creates a new category of obsolescence where systems remain operationally functional but become increasingly difficult to justify from a cyber resilience perspective.

As explored in Zircon’s previous articles on Artificial Intelligence Obsolescence, Cybersecurity and Obsolescence, and The Challenge of Obsolescence in UK Infrastructure, software obsolescence and cyber resilience can no longer be treated as separate disciplines.

Rather than waiting for failures, vulnerabilities or compliance pressures to force action, organisations should adopt a more proactive approach.

Understand not only what software is deployed, but how it is maintained, supported, tested and updated.

Identify unsupported technologies, ageing platforms, disappearing development environments and supplier dependencies before they become operational problems.

Source code alone is rarely enough. Development environments, test systems, configuration baselines, build processes and engineering knowledge may be equally important to long-term resilience.

Consider security, maintainability, supportability and update mechanisms from the outset of any development or modernisation programme.

Long-life infrastructure increasingly requires managed evolution rather than periodic wholesale replacement.

For more than 25 years, Zircon has helped organisations address complex software and systems engineering challenges across rail, highways, defence and industrial sectors.

Our expertise spans software engineering, systems engineering, assurance, software obsolescence management, systems integration, lifecycle management and technology modernisation.

Whether the challenge is modernising a legacy system, understanding software lifecycle risk, addressing technology obsolescence or applying secure-by-design engineering principles, our focus remains the same: helping organisations build and maintain resilient operational systems.

To explore these topics in more detail, we recommend:

• Artificial Intelligence Obsolescence
• Cybersecurity and Obsolescence
• The Challenge of Obsolescence in UK Infrastructure

Together, these papers explore how ageing software, technology evolution, cyber security requirements and operational resilience are becoming increasingly interconnected challenges for organisations operating critical systems.

The future of cyber resilience will be influenced as much by engineering decisions as security controls.

Organisations that understand the relationship between software engineering, lifecycle management, obsolescence and cyber resilience will be better positioned to manage risk, maintain operational capability and adapt to evolving regulatory expectations.

For critical infrastructure operators and suppliers, cyber resilience no longer starts with security controls.

It starts with software engineering.