Verification Over Trust: Rethinking Software Supply Chain Security

In March 2026, Daniel Stenberg, creator and lead developer of curl, published a blog post that challenges a fundamental assumption in software development: that we can trust widely-used components simply because they're popular or well-regarded. Stenberg's argument is particularly compelling given that curl runs in an estimated tens of billions of devices, making it one of the most widely deployed software components in existence.

The Problem with Trust-Based Models

Stenberg identifies several scenarios in which a project at curl's scale could be compromised:

• A malicious contributor merging tainted code
• A breached committer unknowingly distributing modified releases
• An extorted team member making unwanted changes
• A hacked distribution server serving altered tarballs

What makes these scenarios particularly dangerous is that they can occur independently or in rapid sequence, and the consequences of a successful attack on a project of curl's reach could be severe. As Stenberg states, "Software and digital security should rely on verification, rather than trust."

This perspective is reinforced by real-world events. The XZ Utils backdoor discovered in 2024, which involved a long-running effort to insert malicious code via a trusted contributor, demonstrated the limits of reputation-based trust. Practitioners in security and platform engineering have echoed this position, noting that such attacks precisely match the threat vectors Stenberg describes.

Curl's Verification Framework

The curl project has implemented an extensive set of controls designed to make the git repository the authoritative and auditable source of truth. These technical controls include:

• Code style enforcement: Consistent formatting across the entire codebase
• Restricted C functions: Banning functions deemed difficult to use safely
• Complexity limits: Imposing ceilings on function complexity to maintain readability
• Multi-layered review: Both human and automated review of all pull requests
• Binary restrictions: Prohibiting binary blobs and most uses of base64-encoded content

These controls are complemented by more than 200 CI jobs that run on every commit, builds using strict compiler settings that treat warnings as errors, continuous fuzzing via Google's OSS-Fuzz project, and mandatory two-factor authentication for all committers.

Each of these controls is designed to make any deviation from expected behavior visible to anyone following the project. The goal is to create an environment where any unauthorized change would be immediately detectable.

Beyond Internal Controls: The Verification Ecosystem

Stenberg recognizes that internal controls alone are insufficient. The curl project provides several mechanisms for external verification:

• Signed release artifacts: Every release is cryptographically signed by the release manager
• Dedicated verification page: The curl website includes a page where users can verify that a release contains only what's in the git repository
• Transparent build process: Detailed documentation of how releases are built and distributed

"If even just a few users verify that they got a curl release signed by the curl release manager and they verify that the release contents is untainted and only contains bits that originate from the git repository, then we are in a pretty good state," Stenberg explains.

This approach creates a distributed verification model where the burden of verification is shared across the ecosystem. Even a small number of independent verifiers can provide meaningful security by raising the alarm if anything looks wrong.

Software Bill of Materials: Enabling Verification at Scale

One of the structural tools now available for expressing exactly what a piece of software contains is the Software Bill of Materials (SBOM). Viktor Petersson, founder of sbomify, argued at QCon London 2026 that teams are running out of time to adopt SBOMs.

Regulatory pressure is building:

• The EU Cyber Resilience Act opens its first enforcement window in September 2026 and requires full SBOM compliance by December 2027
• US Executive Order 14028 makes SBOMs a procurement condition for software sold to the federal government
• The FDA requires SBOMs for medical devices

Petersson emphasized the importance of signing SBOMs throughout their lifecycle, stating that "Any signing is better than no signing. Do sign your SBOMs in your pipeline, not on somebody's machine." This provides the verifiable chain of custody that Stenberg describes as essential for verification.

The connection between SBOMs and verification is direct: curl already provides signed release artifacts and details verification steps clearly, giving consumers the chain of custody that Petersson identifies as critical.

CI/CD Pipeline Security: A Critical Verification Point

CI/CD pipelines represent a significant vulnerability in software supply chains. The compromise of a widely used GitHub Action in April 2025 highlighted how a single malicious or compromised action can expose secrets and build artifacts across many projects simultaneously.

Stenberg's approach addresses this directly: the curl CI jobs are configured to access the source repository read-only and are checked with the zizmor tool to reduce the risk of insecure job configuration. This exemplifies the principle of least privilege applied to build systems.

Additional verification practices for CI/CD include:

• Pinning dependencies to specific commit hashes
• Monitoring for unexpected changes in CI tooling
• Regular auditing of third-party actions and dependencies
• Implementing code signing for build artifacts

Implementation Challenges and Trade-offs

While verification-based security offers significant benefits, implementing these practices presents several challenges:

Complexity Overhead

Verification processes add complexity to the development workflow. Organizations must balance security requirements against development velocity. The key is to automate verification as much as possible, integrating it seamlessly into existing CI/CD pipelines.

Resource Requirements

Implementing robust verification requires significant resources: skilled personnel, tooling investments, and ongoing maintenance. For smaller projects or organizations, this can be a substantial barrier.

False Positives and Alert Fatigue

Overly aggressive verification can generate false positives, leading to alert fatigue. Organizations must carefully tune their verification systems to focus on genuine security concerns rather than minor deviations.

Interoperability Issues

Different verification tools and standards may not always interoperate seamlessly. Organizations may need to invest in integration work to create a cohesive verification ecosystem.

Performance Impact

Some verification processes, particularly cryptographic operations, can impact build performance. Organizations must carefully consider where to apply verification to minimize impact on development workflows.

Best Practices for Implementation

Based on the approaches taken by curl and other projects, several best practices emerge:

1. Start with critical components: Focus verification efforts on the most critical and widely-used dependencies first.

2. Automate everything: Automate verification processes as much as possible to reduce human error and ensure consistency.

3. Implement layered verification: Use multiple verification methods at different points in the supply chain.

4. Maintain transparency: Make verification processes and results transparent to all stakeholders.

5. Regular audits: Conduct regular audits of verification processes to identify and address weaknesses.

6. Community engagement: Engage with the broader community to share verification practices and learn from others.

Future Outlook

The shift from trust to verification represents a fundamental change in how we approach software security. As supply chain attacks become more sophisticated, verification will become increasingly essential.

Several trends are likely to shape the future of software supply chain verification:

• Standardization: More standardized verification processes and tools will emerge, reducing the complexity of implementation.

• Regulatory pressure: Continued regulatory pressure will drive broader adoption of verification practices.

• AI-powered verification: Artificial intelligence will play a larger role in automating verification processes and identifying potential threats.

• Blockchain-based verification: Blockchain technology may be used to create immutable verification records.

• Supply chain transparency: Greater transparency throughout the software supply chain will become the norm rather than the exception.

Conclusion

Daniel Stenberg's call for verification over trust represents a necessary evolution in software security. As the XZ Utils attack demonstrated, no project is immune to compromise, regardless of its reputation or the trustworthiness of its contributors.

The technical controls implemented by curl, combined with broader verification practices like SBOMs and secure CI/CD pipelines, provide a blueprint for how organizations can implement verification-based security. While these practices present challenges, the alternative—continuing to rely on trust in an increasingly hostile environment—is far riskier.

As Stenberg concludes, "I want to strongly encourage more users and consumers of software to verify curl. And ideally require that you could do at least this level of verification of other software components in your dependency chains." This advice applies not just to curl, but to all software components in our increasingly complex supply chains.

The future of software security lies not in blind trust, but in rigorous, transparent, and automated verification. Organizations that embrace this shift will be better positioned to defend against the evolving threat landscape and build more secure software ecosystems.

Resources

• curl verification page
• OSS-Fuzz
• EU Cyber Resilience Act
• US Executive Order 14028
• sbomify
• zizmor security analysis