Leading Open Source Author Calls for Verification over Trust in Software Supply Chains

Matt Saunders · article · 2026-03 source ↗ Reader 🖥️

The software industry's default stance of trusting well-known components is no longer adequate; organisations must shift to active verification of the software they consume — and the tooling, regulatory pressure, and concrete exemplars (curl's own practices) to do so already exist.

practical · reportage-synthesis — An InfoQ news article that synthesizes Daniel Stenberg's blog post on verification-over-trust with supporting context from Viktor Petersson's SBOM talk, the XZ Utils backdoor, and a GitHub Actions compromise. The article is primarily reportage but builds a coherent argument arc across its sources.

Structure

Part	Role
Stenberg's core thesis: verify, don't trust	States the central claim and anchors it in curl's unique position (tens of billions of devices)
Threat model enumeration	Lists concrete attack vectors (malicious contributor, breached committer, extorted team member, compromised distribution server) to establish that trust can fail at any point
Curl's internal controls	Catalogues the verification mechanisms curl already implements: code style enforcement, banned functions, complexity ceilings, 200+ CI jobs, strict compiler settings, OSS-Fuzz, 2FA for committers
The external verification ecosystem	Describes signed releases, the verify page, and the argument that even a few independent verifiers provide meaningful security
XZ Utils backdoor as corroborating evidence	Cites the 2024 attack where a long-term trusted contributor inserted malicious code, showing the exact failure mode Stenberg warns about
SBOMs and regulatory pressure (Petersson's talk)	Introduces the structural tooling (SBOMs) and legal mandates (EU CRA, US EO 14028, FDA) that make verification not just advisable but mandatory
CI/CD pipeline compromise (GitHub Actions incident)	Shows that build infrastructure itself is an attack surface, reinforcing the need to verify the entire chain
Lifecycle and governance challenge	Petersson's observation that SBOM management is where 'source code management was in the 90s' — the tooling exists but practice lags

Key terms

verification (over trust) Software Supply-Chain Security
Actively checking that software artefacts contain only what they claim to contain, using cryptographic signatures, reproducible builds, and independent auditing — as opposed to relying on the reputation of the producer
Software Bill of Materials (SBOM) Software Supply-Chain Security
A machine-readable inventory of every component in a software artefact, which can be signed and verified to provide a chain of custody
chain of custody Software Supply-Chain Security
An unbroken, cryptographically verifiable record from source code through build to delivered artefact, establishing that no tampering occurred
supply chain trust
The current default posture where organisations consume dependencies based on the reputation of the project or maintainer without independently verifying the artefacts
EU Cyber Resilience Act (CRA) Software Supply-Chain Security
European regulation opening enforcement in September 2026 that can block product sales (not just impose fines) for non-compliance with SBOM and security requirements

Propositions

explicitcorroboratedSoftware and digital security should rely on verification rather than trust.conf: high
supports ←vlt 1.0 Ships as a Drop-in npm Replacement with Phased Installs, Graph Queries, and Malware-Blocking · p3 — Stenberg's call for 'verification rather than trust' is instantiated here as registry-level verification: vlt rejects packages that fail a malware check before serving them, rather than trusting publishers by default.
extends ←A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale · p2 — Applies the general 'verification over trust' security principle (originally about software supply chains) to a different domain: technical documentation production, where the risk is not a malicious actor but the LLM's structural inability to validate or own its own output.
explicitEven a small number of independent verifiers is sufficient to provide meaningful security, because any one of them can raise the alarm.conf: high
explicitcorroboratedA project at curl's scale (tens of billions of devices) could be compromised through any of several independent vectors: malicious contributor, breached committer, extorted team member, or hacked distribution server.conf: high
supports ←AI-Enabled Security Researchers Discover How a Crafted Video Can Provide Attackers Access to Your PC · p10 — Both propositions make the same structural point — a widely-depended-upon foundational project (FFmpeg's libavcodec here, curl there) is a single point of failure whose compromise cascades far beyond itself.
explicitThe XZ Utils backdoor demonstrated that reputation-based trust in open-source contributors is exploitable through long-term social engineering.conf: high
explicitdevelopedSBOM signing is more important than the specific signing tooling used — any signing is better than no signing.conf: high
extends ←GKE Security Blueprint Joins Growing List of Cloud AI Frameworks · p3 — Extends the corpus's SBOM/verification thesis into the AI-specific artefact layer: k8s-aibom generates AI bills of materials automatically because traditional SBOMs do not capture datasets, model weights, or frameworks.
explicitThe EU CRA can block product sales, not just impose fines, making SBOM compliance an existential business concern.conf: high
explicitCI/CD pipelines are themselves an attack surface that must be secured as part of the verification chain.conf: high
implicitdevelopedThe gap between available verification tooling and actual adoption is the primary problem — the tooling exists, the practice does not.conf: high
extends ←IBM and Red Hat Commit $5 Billion to Redefine the Future of Open Source in the AI Era · p2 — Offers a commercial-service answer to the tooling-vs-adoption gap identified there — packaging validation/patching as a subscription so enterprises adopt it as a service rather than building the practice themselves.
implicitProjects that cannot demonstrate verification practices comparable to curl's will be increasingly vulnerable to both attacks and regulatory action.conf: medium

Arguments

Organisations should actively verify all software they consume rather than relying on the reputation of producers. strength: high

Explicit premises:

A project as well-maintained as curl could still be compromised through multiple independent vectors (malicious contributor, breached committer, extortion, distribution server compromise).
The XZ Utils backdoor showed that a trusted contributor can be a long-term social engineering attack vector.
Curl already provides signed releases and a verification page, making consumer verification feasible.
Even a few independent verifiers create meaningful detection capability.

Implicit premises:

If even curl, with its extensive security practices, considers these threats real, then less rigorous projects are more vulnerable.
The cost of verification is low relative to the potential damage of a compromised dependency at curl's scale.

Inferences:

Trust is structurally inadequate because it fails precisely when it matters most — when a trusted entity is compromised.
Verification is both technically feasible (tools exist) and necessary (attacks are demonstrated).

The software industry is being forced toward verification by converging regulatory mandates. strength: high

Explicit premises:

The EU CRA opens enforcement in September 2026 and requires full SBOM compliance by December 2027.
The EU CRA can block product sales in the European market, not just impose fines.
US EO 14028 already requires SBOMs for federal procurement.
FDA requires SBOMs for medical devices.

Implicit premises:

Regulatory mandates create compliance pressure that voluntary best-practice advocacy cannot.
Companies that sell into EU or US government markets have no choice but to adopt verification practices.

Inferences:

The question is no longer whether to adopt verification but how quickly organisations can close the gap before enforcement begins.

The entire software delivery chain — not just source code — must be subject to verification. strength: high

Explicit premises:

A compromised GitHub Action exposed secrets and build artefacts across many projects simultaneously.
Curl configures CI jobs as read-only and uses zizmor to check for insecure job configuration.
Petersson insists SBOMs must be signed in the pipeline, not on a developer's machine.

Implicit premises:

Source code verification alone is insufficient if the build and distribution pipeline can be compromised independently.
Pipeline-level attacks can have wider blast radius than source-level attacks because they affect all consumers simultaneously.

Inferences:

Verification must be end-to-end: source, build, signing, and distribution.

Narratives

The XZ Utils backdoor (2024): a contributor gained trust over an extended period before inserting malicious code into liblzma, targeting the software supply chain through social engineering of maintainers
→ Primary corroborating evidence that reputation-based trust is exploitable — exactly the scenario Stenberg warns about
The GitHub Actions compromise (April 2025): a widely used GitHub Action was compromised, exposing secrets and build artefacts across many projects
→ Demonstrates that CI/CD infrastructure is a real attack surface, extending the verification argument beyond source code
Curl's verification infrastructure: 200+ CI jobs, strict compiler settings, OSS-Fuzz, banned functions, signed releases, a public verify page — built up over the lifetime of a project running on tens of billions of devices
→ Serves as the concrete exemplar proving that comprehensive verification is achievable in practice
Petersson's analogy: 'Dealing with SBOMs today feels like managing source code in the 90s, with patches sent over email'
→ Frames the current state of SBOM practice as immature but improvable, implying the same trajectory as version control adoption

Questions addressed

✅ Why is trust insufficient as a security posture for software dependencies?
Trust fails when the trusted entity is compromised — through malicious insiders, breached credentials, extortion, or social engineering (as demonstrated by XZ Utils). These vectors are independent and can combine.
✅ What does a concrete verification practice look like?
Curl's model: enforceable code standards, 200+ CI jobs, strict compiler settings, continuous fuzzing, 2FA for committers, signed releases, a public verify page, read-only CI, and pipeline security checks.
✅ Is regulatory pressure sufficient to drive adoption of verification practices?
Yes — the EU CRA (enforcement from September 2026, full compliance December 2027) can block sales, not just fine. US EO 14028 and FDA requirements add further pressure. The timeline is concrete and imminent.
✅ How many independent verifiers are needed for the system to work?
Stenberg argues that even a few are sufficient — any one verifier can raise the alarm if something is wrong.
⭕ Can most open-source projects realistically implement curl-level verification?

Gaps

incompleteThe article presents curl's verification infrastructure as the exemplar but does not address the resource asymmetry: curl is a well-funded, high-profile project with a dedicated lead developer. Most open-source projects lack the resources to implement 200+ CI jobs, continuous fuzzing, and dedicated security tooling. The transferability of this model to the long tail of open-source dependencies is unexamined.
Read next: Look for work on scalable verification for under-resourced projects — e.g., OpenSSF Scorecard, Sigstore for automated signing, or community-funded security auditing.
incompleteStenberg's 'few independent verifiers' argument rests on an unexamined incentive problem: who are these verifiers, what motivates them, and how do they sustain the practice? The article acknowledges Stenberg 'cannot know who those users are, or whether they currently exist' but does not explore the fragility of relying on unpaid, uncoordinated volunteers.
Read next: Look for research on verification-as-a-service models, paid auditing, or how the reproducible builds movement addresses the volunteer-verifier problem.
incompleteThe article synthesises Stenberg's argument with Petersson's SBOM advocacy and the GitHub Actions incident, but does not address the coherence gap between these approaches. SBOMs describe what is in the software; Stenberg's verification checks that the source matches the release; CI pipeline security prevents build-time tampering. These are complementary but the article does not articulate how they compose into a unified verification strategy.
Read next: Look for end-to-end supply chain security frameworks (e.g., SLSA — Supply-chain Levels for Software Artifacts) that integrate source, build, and distribution verification.
absentThe article does not discuss the cost-benefit tradeoff of verification. For organisations consuming hundreds or thousands of dependencies, verifying each one to curl's standard may be impractical. There is no discussion of risk-based prioritisation — which dependencies warrant full verification and which can be handled with lighter checks.
Read next: Look for risk-based dependency management frameworks and dependency criticality scoring (e.g., OpenSSF Criticality Score).