In the past year, several high-profile outages disrupted airports, cloud platforms, and critical digital services worldwide. In each case, the software involved had been tested, certified, and deployed in accordance with accepted practices. Yet, when assumptions broke, the impact travelled fast across organisations, supply chains, and international borders.
These recent incidents, from large-scale cloud outages to supply-chain compromises, point to a deeper issue: tested software is not the same as trustable software. These failures expose a growing gap in software supply chain trust, where testing is treated as assurance despite increasingly complex and opaque dependencies.
That distinction will sit at the centre of John Ellis’ OCX26 session, “Rebuilding trust: From open source to open accountability”. John makes the problem explicit:
“How does the industry currently define trust? With those outages exposed, the industry has quietly redefined trust to mean: it passed tests at a point in time.”
Testing, he argues, has become a convenient stand-in for trust, but not a reliable one:
“Testing has become a proxy for trust, but not proofable. We test expected behaviour under known conditions, but we don’t continuously verify where software came from, how it was built, what changed, or who is accountable once it’s deployed at scale.”
When those assumptions break, systems fail (sometimes at a global scale) despite being fully tested. Let’s think of a few of the 2025 events, such as the CrowdStrike incident, Google Cloud outages, and the SolarWinds. As John explains,
“They were trust failures, caused by invisible complexity and fragmented responsibility across the supply chain.”
At the heart of the issue is how trust is currently established.
“We’ve built critical infrastructure on implicit trust, not demonstrative trust. And trust without evidence isn’t trust at all. It’s hope.”
This matters more now than ever. Regulatory frameworks such as the Cyber Resilience Act are raising expectations around transparency and accountability, but we should be cautious against equating compliance with confidence. Reliability is an observed outcome after the fact. Trustability, by contrast, is a property that must be continuously demonstrated as software evolves.
In his OCX26 session, John will introduce the Eclipse Trustable Software Framework (TSF), developed openly within the Eclipse Foundation ecosystem. TSF reframes trust as something that must be evidenced across the entire software lifecycle, through provenance, construction, change history, expectations, results, and confidence, rather than assumed because a system “passed”.
For engineers, architects, and technical leaders responsible for critical systems, this talk is not about adopting another framework. It is about confronting a flawed mental model and replacing implicit trust with evidence-based confidence.
If your organisation still equates “tested” with “trustable”, this session will challenge that assumption. John Ellis shows how teams can move from asking “are we compliant?” to asking “what evidence do we have right now that this system is still trustable?” starting with one critical system, clear ownership, and continuous, inspectable evidence.
Join the conversation at OCX26 in Brussels this April.
