From Fragile to Fortified: Engineering Verifiable Trust in Open Source

The industry has reached a point of cognitive dissonance regarding Open Source Software (OSS). Acknowledging that OSS is the bedrock of modern digital infrastructure - powering roughly 98% of scanned codebases1 yet it is continually consumed through a model of implicit trust that would be rejected in any other engineering discipline.

For organizations, the challenge is no longer just finding vulnerabilities. It is about managing the transparency gap between upstream consumption and deployment to production. Attempting to hold developers accountable for these risks started as a ripple, a minor disruption to their daily work that evolved into a tsunami. CVE burnout is accelerating, and all organizations are suffering under the same mass of unexploitable alerts and fire drills, distracting from the real risks buried in the code.

Transitioning from Inventory to Integrity

Some organizations have responded to this threat by mandating Software Bill of Materials (SBOMs). While an SBOM provides essential visibility, it is a static list, a nutrition label for a meal that is often inaccurate and can easily be tampered with after packaging.

To move towards a resilient posture, leadership must pivot toward Attestation-Based Security. This involves:

• Cryptographic Provenance: Moving beyond simple checksums to identity-based signatures that prove who built the code and how.
• Reproducible Builds: Ensuring build environments are isolated, ephemeral, and dependency-controlled so that any authorised party can verify that the same inputs produce the same outputs and eliminate hidden tampering.
• Hardware Roots of Trust: As our CEO, Andrew Martin, emphasised in this SC Magazine article (opens in a new tab), software-based security is only as strong as the environment in which it runs. Utilising Trusted Execution Environments (TEEs) or Hardware Security Modules (HSMs) to protect signing keys is the only way to ensure that authorised doesn’t just mean “compromised by a valid key.”

The Way Forward: Verifiable Evidence

For development and security teams, the goal is to reach a state where security is not a gate at the end of the SDLC but a continuous stream of verifiable evidence for managing third-party code risk.

By adopting a “Verify, then Trust” architecture, organizations can programmatically reject any artefact that lacks a verified chain of custody. This shifts the burden of proof from the security team to the automated pipeline, reducing friction and significantly lowering the blast radius of upstream OSS compromises.