From Fragile to Fortified: Engineering Verifiable Trust in Open Source

Author: John Kjell

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 codebases¹ 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.

The Evolution of “Many Eyes”

In the age of AI, “Linus’s Law” that “given enough eyeballs, all bugs are shallow” has mutated into “given enough prompts to AI agents, all bugs will be exploited”. The rise of sophisticated supply chain attacks, made easier by vibe coders who don’t read their agent’s code contributions, has resulted in the discovery of over 454,000 new malicious packages in open source repositories in 2025 alone, 75 per cent more than the previous year².

The risk is not merely a bug in a library; it is the intentional subversion of the delivery pipeline. When a developer’s credentials are compromised, or a build server is breached, the resulting artefact is signed and authentic but fundamentally malicious.

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, 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.

Next Steps: Engage and Act

The shift from managing inventory to validating integrity requires a proactive strategy. We understand the complexity of implementing hardware-backed roots of trust and cryptographic attestations across legacy systems. Find out more about our approach.

The time to begin this strategic pivot is now. If you’re ready, book a Supply Chain Maturity Assessment today.

From Fragile to Fortified: Engineering Verifiable Trust in Open Source