As the Cyber Resilience Act (CRA) moves closer to enforcement, engineering teams across Europe are being asked to demonstrate secure development practices, software supply chain transparency, and improved vulnerability management. For many organisations, the focus has shifted to compliance: what needs to be shown, documented, and certified.
However, compliance alone does not guarantee resilience.
In his OCX 26 session, “Rebuilding Trust: From open source to open accountability”, John Ellis (President and Head of Product at Codethink) will draw a clear distinction between meeting regulatory expectations and understanding whether software systems can still be trusted as they evolve. As he explains in an interview,
“The CRA asks organisations to demonstrate secure development practices, supply chain transparency, and building management.”
The challenge lies in how those requirements are accomplished.
“The CRA largely defines what must be shown at specific compliance moments. So, for example, before release, during incident response, or audits.”
Modern software systems do not operate at discrete moments. Dependencies change, suppliers update components, and environments shift continuously, often without clear executive or system-level visibility. In that context, passing a compliance assessment provides limited insight into whether a system remains safe today.
This is where John introduces a different framing of trust.
“The Eclipse Trustable Software Framework treats trust as continuous, not episodic. It doesn’t just help you pass an assessment, it helps you know every day whether your software still deserves to be trusted.”
Developed openly within the Eclipse Foundation ecosystem, the Eclipse Trustable Software Framework (TSF) is presented as a way to turn regulatory intent into operational evidence. Rather than relying on periodic assertions, TSF focuses on continuously answering practical questions: where software came from, how it was built, what changed, and what risks exist right now, not at the last audit.
John also highlights a limitation that remains even when compliance obligations are met.
“CRA compliance can still be satisfied with fragmented ownership, each supplier asserting their own correctness. (...) The TSF shifts the model towards a shared system-level accountability across the supply chain.”
For teams responsible for critical or connected systems, the takeaway is not that compliance is irrelevant, but that it is incomplete. The Cyber Resilience Act defines necessary expectations. Understanding whether a system still deserves trust requires continuous evidence and shared accountability.
If you’re relying on the Cyber Resilience Act compliance to answer questions about software risk, this session will challenge what it still doesn’t guarantee. John Ellis explains how teams can move from asking “are we compliant?” to asking “what evidence do we have right now?” and how to make trust visible before incidents force the issue.
Join the conversation at OCX26 in Brussels this April.
