Trust in code: the new frontline of defence supply chain security

Tracey Hannan-Jones

Consulting Director in Information Security, UBDS Digital

I’ve spent much of my career working with organisations that believed their supply chain was secure because the paperwork said so. Certifications were current, audits were passed, and suppliers met contractual requirements. On paper, it held together. In reality, it often didn’t.

That gap is now becoming critical in UK defence.

Autonomy across land, sea and air depends on software, models, data and continuous updates. The risk has shifted away from physical components to the integrity of what is running on them. A compromised dependency, an unverified model update, or a tampered build pipeline can degrade capability without any obvious failure in the platform itself.

The core problem is this: static assurance models are no longer fit for purpose. Periodic audits and point-in-time compliance cannot keep up with systems that change continuously. If assurance only tells you that something was secure three months ago, it has limited value in an environment where software may have changed ten times since.

Continuous verification must replace periodic compliance

In practical terms, that means being able to prove, at any point, where a component came from, whether it has changed, and whether that change was authorised. Every update, dependency change and model retrain needs verifiable provenance. Without that, organisations are relying on assumptions rather than evidence.

This is where many current approaches fall short. Assurance is still treated as a governance exercise rather than an operational control. Evidence is collected, reviewed and archived, but rarely used to monitor live risk. I’ve seen programmes delayed because teams could not confirm the origin of a software component already integrated into a system. By the time the issue surfaced, tracing it back through the supply chain was slow and disruptive.

The challenge becomes more acute beyond the prime contractor. Visibility into sub-tier suppliers is often limited, yet this is where much of the innovation and risk sits. Open-source components, specialist SMEs and niche service providers are embedded in delivery, but not always in assurance.

Failures in this space are rarely dramatic at first. They tend to appear as subtle issues. A dependency updated from an unverified source. A model trained on data that has not been validated. A patch applied without full traceability. These are the kinds of weaknesses that accumulate quietly until they affect performance, delay deployment or introduce security exposure at the worst possible moment.

AI is often presented as a solution to this problem. It can help, but only within limits. Used properly, it can process large volumes of supplier data, detect unusual changes and highlight gaps in expected controls. That reduces the time it takes to identify potential issues.

However, it also introduces new risks. I’ve seen organisations place too much confidence in risk scores without understanding how they were derived. If the underlying data is incomplete or biased, the output will be misleading. If decisions cannot be explained, they cannot be defended, particularly in a defence context.

For now, AI should be treated as a support capability. It can prioritise, flag anomalies and maintain an audit trail. It should not replace human accountability.

So, what needs to change?

First, defence contracts should require software bills of materials and provenance tracking as standard. It should not be possible to deliver software into a defence environment without a clear record of its origin and dependencies.

Second, assurance needs to move from annual or milestone-based audits to continuous signals. This includes automated checks on build integrity, dependency changes and access controls that provide ongoing visibility rather than retrospective assurance.

Third, requirements need to be standardised across MOD programmes. One of the most consistent issues I see is suppliers facing different assurance expectations for different contracts. That drives cost, creates confusion and weakens compliance. A common baseline, applied consistently, would improve both efficiency and security.

Fourth, there needs to be a clearer model for SMEs. They are essential to the defence ecosystem, but they are often asked to meet requirements that are either inconsistent or disproportionate. Defining a minimum set of controls that are realistic, scalable and aligned to risk would reduce friction while still raising the overall standard.

This is not about lowering expectations. It is about making them workable.

Accountability also needs to be more explicit. The MOD sets requirements and must enforce them. Primes and integrators need to take responsibility for validating their supply chains, not simply passing obligations downstream. Suppliers need to demonstrate that controls are operating in practice, with evidence that can be verified.

Compromise should be assumed, not treated as an exception. The focus should be on how quickly issues are detected, contained and resolved, and whether responsibility is clear when they occur.

There is no shortage of frameworks to support this. NIST SSDF, SBOM practices, ISO standards and the NIST AI Risk Management Framework all provide useful guidance. The issue is not awareness. It is consistent implementation and enforcement.

The shift required is straightforward but significant. Supply chain security is no longer a compliance exercise sitting alongside delivery. It is part of how capability is delivered.

If defence systems depend on software that is updated continuously, then every change becomes a potential point of failure. Without continuous verification, organisations are making decisions based on incomplete information.

And in an operational environment, that does not lead to minor inefficiencies. It leads to delayed deployment, degraded capability, and in the worst cases, mission failure.

Read the full article here for a more detailed view of the risks, practical controls and assurance model needed for autonomy-led defence.