In a blog post published in March 2026, Daniel Stenberg, creator and lead developer of curl, makes the case that the software program business’s default place of trusting well-known elements is now not enough. Stenberg argues that customers and organisations ought to actively confirm the software program they devour, and he makes use of curl’s personal practices as a concrete instance of how that may be achieved.
Curl runs in an estimated tens of billions of gadgets, making it one of the extensively deployed software program elements in existence. Stenberg lists a variety of situations wherein a undertaking at that scale might be compromised, together with a malicious contributor merging tainted code, a breached committer unknowingly distributing modified releases, an extorted workforce member making undesirable adjustments, or a hacked distribution server serving altered tarballs. He notes that these situations can happen independently or in fast sequence, and that the implications of a profitable assault on a undertaking of curl’s attain might be extreme.
“Software program and digital safety ought to depend on verification, relatively than belief. I wish to strongly encourage extra customers and customers of software program to confirm curl. And ideally require that you may do no less than this stage of verification of different software program elements in your dependency chains.”
– Daniel Stenberg
The curl undertaking has put in place an in depth set of controls supposed to make the git repository the authoritative and auditable supply of fact. These embrace imposing a constant code fashion, banning the usage of sure C features deemed tough to make use of safely, imposing a ceiling on perform complexity, requiring human and automatic evaluation of all pull requests, and prohibiting binary blobs and most makes use of of base64-encoded content material, each of which might be used to hide malicious payloads. Stenberg additionally describes greater than 200 CI jobs that run on each commit, builds utilizing strict compiler settings that deal with warnings as errors, steady fuzzing by way of Google’s OSS-Fuzz undertaking, and necessary two-factor authentication for all committers. Every of those is designed to make any deviation from anticipated behaviour seen to anybody following the undertaking.
On high of these inside controls, Stenberg makes the case for a wider verification ecosystem. He explains that the undertaking supplies signed launch artefacts and a devoted verify page on the curl web site, in order that unbiased customers can examine {that a} launch accommodates solely what’s within the git repository and that it was signed by the discharge supervisor. He acknowledges that he can not know who these customers are, or whether or not they presently exist, however argues that even a small variety of unbiased verifiers is sufficient to present a significant examine: one in all them can increase the alarm if something appears to be like unsuitable.
“If even only a few customers confirm that they acquired a curl launch signed by the curl launch supervisor they usually confirm that the discharge contents is untainted and solely accommodates bits that originate from the git repository, then we’re in a fairly good state.”
– Daniel Stenberg
Stenberg ends his submit with a direct advice to require this verification for all dependencies, stating that “software program and digital safety ought to depend on verification, relatively than belief”. Neighborhood dialogue from earlier than April 2025 echoes this place in a number of methods. On LinkedIn, practitioners in safety and platform engineering have argued that the XZ Utils backdoor, found in 2024 and involving a long-running effort to insert malicious code by way of a trusted contributor, confirmed the bounds of reputation-based belief, similar to on this post from Cameron Stihel and this post from Ryan Johnston. The assault, which focused the liblzma part by gaining the boldness of maintainers over time earlier than inserting code adjustments, is exactly the sort of situation Stenberg describes in his listing of risk vectors.
One of many structural instruments now obtainable for expressing precisely what a bit of software program accommodates is the Software program Invoice of Supplies. In a chat at QCon London 2026 coated by InfoQ, Viktor Petersson, founding father of sbomify, argued that groups are working out of time to undertake SBOMs. He cited the EU Cyber Resilience Act, which opens its first enforcement window in September 2026 and requires full SBOM compliance by December 2027, and warned that its penalties transcend fines: “CRA is just not about fines. They will really block gross sales. Your merchandise will be blocked from the European market.” US Government Order 14028, in drive since 2021, makes SBOMs a procurement situation for software program offered to the federal authorities, and the FDA requires them for medical gadgets.
Petersson’s discuss addressed the total lifecycle of SBOM manufacturing, together with the step that the majority groups skip: signing. He was direct that this can be a mistake, and that the particular tooling issues lower than the act of signing itself, as this supplies a verifiable chain of custody. Petersson was blunt: “Any signing is healthier than no signing. Do signal your SBOMs in your pipeline, not on any person’s machine.” This connects on to Stenberg’s argument: curl already supplies signed launch artefacts and particulars the verification steps clearly, giving customers the chain of custody that Petersson describes because the objective.
CI/CD pipeline are additionally a possible weak level. InfoQ coated the compromise of a extensively used GitHub Motion in April 2025, which highlighted how a single malicious or compromised motion can expose secrets and techniques and construct artefacts throughout many initiatives concurrently. The incident bolstered requires tighter controls on third-party actions, pinning dependencies to particular commit hashes, and monitoring for sudden adjustments in CI tooling. Stenberg’s strategy addresses this straight: the curl CI jobs are configured to entry the supply repository read-only and are checked with the zizmor software to cut back the danger of insecure job configuration.
Petersson additionally pointed to the lifecycle problem, noting that an actual product typically has dozens of SBOMs that change on each CI run and that regulators can request the SBOM for a selected previous launch. He in contrast present follow to software program improvement earlier than model management: “Coping with SBOMs right this moment appears like managing supply code within the 90s, with patches despatched over e-mail.” This governance concern leans into Stenberg’s broader level. The tooling to supply, signal, and confirm software program artefacts exists, and the regulatory strain to make use of it’s constructing, so organisations ought to shut the loop by verifying what they devour.