One Volunteer From a Breach: Open Source and the AI Supply Chain
A single unpaid volunteer can be the reason your AI system is breached.
That is not a warning about the future. It is a description of the layer your models already run on. Underneath the orchestration framework, underneath the vector store, underneath the container image and the inference server, sits a short list of libraries that almost every piece of software on the internet depends on, and a much shorter list of people who maintain them. The internet has already run this experiment twice, ten years apart, and published the results both times.
[BOOK IMAGE: row 112 - millions of applications on a handful of packages]
Boards are used to asking who the vendor is. The harder question, one layer down, is who is keeping the vendor's foundations working, and what that person is paid.
Treat that as a supply-chain governance fact rather than a piece of open-source folklore, because that is what it is. The dependency is real, it is contractual nowhere, and it does not appear on any register that a board currently reads. Your model vendor has a contract with you. Nobody has a contract with the person whose library your model vendor imports at build time, and in several documented cases nobody was paying that person anything at all.
Two dates carry the whole argument. April 2014, when a bug in one library broke encryption for two-thirds of the web. March 2024, when a backdoor in another library came within days of reaching every production server. The first was an accident. The second was deliberate.
7 April 2014
A security advisory disclosed a vulnerability in OpenSSL, designated CVE-2014-0160 and branded Heartbleed. It was a missing bounds check in the TLS heartbeat extension, and it let an attacker read up to 64 kilobytes of a server's private memory per request, repeatable indefinitely. Private keys, session tokens, credentials, whatever happened to be adjacent in memory at the moment of the request.
OpenSSL secured over two-thirds of active websites, according to Netcraft's April 2014 survey. Yahoo, Imgur, Stack Overflow, and the Canada Revenue Agency were among those affected. Canada temporarily shut down online tax filing.
[BOOK IMAGE: row 103 - how Heartbleed leaked adjacent memory]
The mechanism is why the incident scaled. Nobody had to break the encryption. An attacker asked the server a well-formed question, and the server answered with whatever happened to be sitting next to the answer, and the question could be asked again indefinitely. Sixty-four kilobytes is a small window. Repeated without limit, it is the contents of the machine.
The bug was introduced on 31 December 2011 by Robin Seggelmann and reviewed by Stephen Henson, one of OpenSSL's four core developers. It shipped with OpenSSL 1.0.1 on 14 March 2012 and stayed undetected for over two years. Nobody was careless in the way boards imagine carelessness. The code was written, reviewed, released, and then left in place because the people who might have found it had other work to do.
What the maintenance actually cost
At disclosure, OpenSSL was maintained by a handful of volunteers, only one of them full time. Stephen Henson earned roughly 20,000 dollars a year. The OpenSSL Software Foundation had never exceeded one million dollars in gross annual revenue, and yearly donations ran at approximately 2,000 dollars.
Two thousand dollars a year to maintain the library securing two-thirds of the world's web traffic.
The software engineer John Walsh framed the resourcing problem plainly: two full-time people for 500,000 lines of business-critical code. That is the whole finding. The vulnerability was a consequence of the arithmetic, not a departure from it.
In thirty years of running open-source infrastructure in production and presenting cyber and architecture risk postures at board level, I have found this the hardest single point to land in a governance conversation, because it does not look like a security problem until it becomes one.
Set those donations against the security budgets of the organisations on the affected list and the gap explains itself. The money existed. It had no route to the code. The library was free, the licence asked for nothing in return, and a procurement process built around invoices has no line item for a dependency that never sends one.
The industry's response was fast. Jim Zemlin of the Linux Foundation conceived the Core Infrastructure Initiative on the night of 24 April 2014. Amazon, Facebook, Google, IBM, and Microsoft each pledged roughly 100,000 dollars a year, giving an initial annual budget of about 1.2 million dollars, a rounding error against the founders' revenue. The immediate crisis was addressed. The structural problem was not.
28 March 2024
Andres Freund, a Microsoft engineer and PostgreSQL developer in San Francisco, noticed an SSH login taking roughly 500 milliseconds longer than expected. He traced the latency to the xz compression library, versions 5.6.0 and 5.6.1, and found not a bug but a deliberately obfuscated backdoor. Under specific conditions it could intercept SSH authentication and enable remote code execution, gated by an Ed448 key so that only the attacker could trigger it.
He disclosed on 29 March. Red Hat assigned CVE-2024-3094 at the maximum CVSS score of 10.0.
The backdoor was inserted by a GitHub account operating as "Jia Tan" (JiaT75), created on 26 January 2021, which had built trust over months of legitimate contributions before it was given the access it needed. The manuscript's assessment is blunt: a state-sponsored actor spent 2.6 years exploiting the human fragility that unpaid, unsupported maintenance creates. Discovery was luck. The margin between discovery and catastrophe was measured in days.
The shape of that operation matters more than its outcome. The contributions were real. The help was real. A stretched volunteer project received sustained, competent, unpaid assistance over months, and accepting it was the reasonable thing to do, because that is how every healthy open source project grows. The attack did not defeat a control. It used the only mechanism the project had for getting work done, and it waited for that mechanism to do exactly what it is designed to do.
What stopped it was an engineer at another company being bothered by half a second of latency. That is the whole detection story.
Heartbleed was an accident produced by an underfunded maintenance model. The xz backdoor was somebody deciding that the same underfunded maintenance model was the cheapest route into every production server on earth. That is the sharper proof, because it means the exposure is not only structural. It is targetable.
The pattern, in full
[BOOK IMAGE: row 106 - the same imbalance, three times]
Between 2014 and 2024 the shape held. Critical infrastructure gets built on volunteer labour. The labour stays invisible because working software generates no headlines. The infrastructure is fragile in a way nobody has priced. A crisis reveals it. Institutions respond with money and commitments. Attention fades. The next crisis finds the same conditions waiting.
Two instances between the bookends make the point without needing the drama of either.
In November 2018, a New Zealand maintainer, Dominic Tarr, handed over a package called event-stream with 1.5 million weekly downloads to a stranger who had volunteered to help. The stranger inserted malware. Tarr had not been paid for the work and had stopped using the package himself, which is exactly the position the model puts a maintainer in.
On 9 December 2021, Log4Shell arrived: CVE-2021-44228, another maximum CVSS score of 10.0, in a logging library maintained by sixteen unpaid volunteers.
Four incidents, one mechanism.
The reason attention fades is not indifference. It is that the fix each crisis calls for is boring, recurring, and has no completion date. Funding a maintainer is not a project. It does not close, it does not produce a milestone, and the person holding the budget gets no visible result for it, because the visible result of a well-maintained library is that nothing happens. Every incentive in a corporate planning cycle points away from it, which is why the same conditions were waiting in 2018, in 2021, and again in 2024.
What the institutions did about it
[BOOK IMAGE: row 107 - each response, outlived by the next crisis]
Executive Order 14028, signed in May 2021, mandated a software bill of materials for federal contractors. The European Union's Cyber Resilience Act, adopted in 2024, imposed security obligations on software producers selling into the European market.
Both are real instruments and both do something useful. Each addressed symptoms. Neither addressed the economic model that makes open source free to consume and expensive to maintain. A bill of materials tells you what is in the building. It does not tell you whether anyone is being paid to keep the roof on.
The board consequence
Here is where the argument becomes mine rather than the record's. The AI supply chain inherits the same unfunded single points of failure, and it inherits them with more layers and less visibility. A model-serving stack pulls in hundreds of packages transitively. Some of them are maintained by teams. Some of them are maintained by one person, at night, unpaid, for reasons that have nothing to do with your risk register.
Supply-chain governance is not optional at this layer, and it is not the same activity as vendor management. Vendor management asks who you have a contract with. This asks who is keeping alive the code your contracted vendor depends on, which is usually somebody your organisation has never heard of and has no relationship with at all.
Provenance and maintenance funding are the assurance question. A software bill of materials gets you the first. The second has no procurement process attached to it yet, which is why it keeps producing incidents.
The practical version is smaller than it sounds, and it starts with a list an organisation can generate today. Take the twenty dependencies your most important system would stop working without. For each one, write down how many people can merge a change, how many of those are paid to do it, and by whom. Most of that is visible in public repositories in an afternoon. The output is not a risk score. It is a short list of names your organisation is depending on and has never contacted, which is the finding, and it is what belongs in front of a board that has just approved an AI programme.
The open-source dimension of this is not the licence. Every project named here, OpenSSL, xz Utils, Log4j, and event-stream, was published under terms that gave everyone the right to use the code and obliged nobody to keep it working. The Core Infrastructure Initiative was the community's own answer to that gap, and its first budget tells you how partial an answer it was. What a consuming organisation can do is read the maintenance profile before it adopts a dependency: how many people hold commit rights, how many of them are paid to, and what becomes of the project if the paid one stops. That information is public for every project named in this article. Almost nobody reads it.
Both of the instruments that followed these incidents point at the same layer. Executive Order 14028, signed in May 2021, required a software bill of materials, an SBOM, from federal contractors. The European Union's Cyber Resilience Act, adopted in 2024, placed security obligations on software producers selling into the European market. Both make the substrate legible. Neither pays anybody to maintain it. The xz case is why that distinction matters where supply-chain assurance turns into a sovereignty question: a patient, well-resourced, state-sponsored actor spent two point six years earning commit rights on a compression library, and what it exploited was not a coding error but a maintenance model. An inventory of what an organisation depends on is a different control from an answer to who is keeping it alive.
When your organisation last brought a foundation library into production, did anybody check how many people are paid to maintain it, and what did you do with the answer you got?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at andreas@thehambergerreport.com. Free as in Theft: The Hidden History of Open Source Software traces the openness, adoption, enclosure, and resistance cycle from the first shared source tapes to the AI licensing wars.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
References
[1] Hamberger, A. "Free as in Theft: The Hidden History of Open Source Software." Te Pono Limited, 2026. ISBN 978-0-473-78455-3. (Chapter 18, primary; Chapter 19, supporting.)
[2] OpenSSL Project. "OpenSSL Security Advisory [07 Apr 2014]." 7 April 2014. https://openssl-library.org/news/secadv/20140407.txt
[3] European Commission. "Cyber Resilience Act." Regulation (EU) 2024/2847, entered into force 10 December 2024. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
[4] Wikipedia contributors. "XZ Utils backdoor." Wikipedia, The Free Encyclopedia. Accessed 30 August 2026. https://en.wikipedia.org/wiki/XZ_Utils_backdoor