Open source
supply chain attacks are not primarily a technical problem - they are a
governance problem. And most projects are solving the wrong one.
By Alan DeKok, CEO, InkBridge Networks
Two incidents have stood out in the open-source supply chain security conversation recently.
The xz utils backdoor, discovered in early 2024, was a sophisticated, patient attack. Someone spent years building trust within a project before inserting malicious code close enough to production systems to compromise SSH logins on millions of Linux machines.
The RubyGems incident, which unfolded in September 2025, was an organisational takeover. A maintainer and a foundation executive locked out the volunteer team that had built and run the project for over a decade, then revoked their publishing access to critical software packages.
Different methods that both resulted in the loss of control over software that millions of people depend on.
Most coverage of these incidents focuses on the technical details - what the backdoor did, how the exploit chain worked, what the attacker changed in the repository. To add to that, I want to highlight an important pattern.
Both attacks succeeded because the underlying processes were opaque. Nobody had a clear, documented, tested answer to the question: who actually controls this? When things went wrong, people were surprised, because they had assumed the project worked one way, and it worked another.
Attackers exploit those assumptions. Both incidents are a reminder that open-source supply chain security is as much a governance problem as a technical one.
Why engineers are easy targets
Open-source maintainers tend to be engineers. Engineers work on trust. You do good work, you earn commit access, and eventually you are trusted with critical systems. That model works well until someone exploits it - and the exploit does not have to be technical.
In the xz utils case, the attacker cultivated a relationship with a maintainer who was burnt out and publicly struggling. Over time, they made themselves useful, earned trust, and eventually obtained the access they needed.
In the RubyGems case, access was simply taken, using organisational permissions that nobody had thought to restrict.
Both attackers succeeded because the people running these projects were focused on the engineering and paying little attention to who was accumulating influence around them.
I have been running FreeRADIUS for nearly 30 years. In that time, I have watched more than a few open-source projects get derailed by people who were better at organisational manoeuvring than at writing code. Working maintainers are often too busy building things to notice. I don’t fault their character. But this is a predictable vulnerability, and patient attackers have learned to use it.
People-pleasing as an attack vector
The xz utils attack also illustrates the role of social pressure in open-source supply chain security.
Engineers feel an obligation to create a good product and to help the people who use it. Bug reports feel like an indictment of your work, so you respond to them. Someone complains that a fix is taking too long, so you feel pressure to move faster. Someone shows up offering help and relieving that pressure, so you let them in.
An understandable instinct that becomes dangerous when you do not know who you are dealing with.
If someone files a bug report and you do not know who they are, you owe them nothing. Your interest in improving your project should be driven by engineering judgement, not by social pressure from strangers. It is perfectly acceptable to respond to a bug report with "Thanks, please submit a patch, as I don't have time to work on this right now." Some people will find that unkind. That is their problem.
I have personally had companies making real money from FreeRADIUS contact me to say a bug is costing them revenue, asking when I plan to fix it. My answer is usually that I will get to it when I get to it, or they are welcome to share some of that revenue and I will prioritise accordingly. Very few have taken me up on that offer.
There seems to be a prevailing attitude that if someone is generous enough to give away software, it is acceptable to demand they also give away their time indefinitely. I know how to mow my own lawn. I still pay someone to do it, because my time is better spent elsewhere, and they do in five minutes what would take me 45. I do not walk over to my neighbour and demand he mow mine as well. But that is exactly what happens to open-source maintainers.
The first thing many of us need to learn is how to say no.
How to protect an open-source project for real
Open-source supply chain security guidance tends to focus on scanning tools and signing frameworks. Those things matter, but most projects end up failing at governance. Here is what actually works.
Vet contributors seriously
Not every contributor deserves commit access. If someone is using a random Gmail address, has no public history in open source, and has never done anything verifiable outside this project, treat them with serious suspicion.
Contrast that with someone who works at a known company, has a public track record, and can be held accountable. Verification is basic risk management.
Do not give away the keys to the kingdom
This is the single biggest vulnerability I see.
DNS records change rarely. You can manage that yourself. Do not give anyone else access to DNS.
Do not give unfettered access to critical infrastructure. Ensure you have local backups that you can restore from quickly if someone vandalises your servers or your GitHub repository. Look at what happened with RubyGems: once organisational access was granted, it was used.
PGP sign all commits and releases
We have been PGP signing FreeRADIUS releases for decades. If the signature is correct, you know the release came from a trusted source. Do not share the signing keys with anyone.
If every commit is signed, any modification to the repository is provably tracked to a specific person. If something bad happens, you know exactly who did it and when.
Keep the project's scope narrow and explicit
A code of conduct that addresses broad social topics gives politically motivated actors a lever to use against you. You eventually violate something, and then the process of removing you begins.
A code of conduct that says "all topics outside the technical scope of this project are out of scope" removes that lever entirely. The goal is to make the project unattractive to people who are more interested in control than in the software.
Think carefully before accepting free hosting
Free hosting is fine. Giving away control of DNS or infrastructure to the entity providing that hosting is not.
Make sure that for any external hosting, you have backups you can spin up on short notice. Accepting dependence is a risk.
These defences work together because they make the project an unattractive target. An attacker who looks at a project and sees signed commits, verified contributors, clear ownership of DNS, and a narrow technical scope will move elsewhere. Most attacks follow the path of least resistance.
The AI pull request problem
I also want to name an emerging threat vector: AI-generated contributions. The risks are twofold.
First, AI allows enthusiastic amateurs to generate code that looks reasonable but is subtly flawed. The person submitting it may have no way of knowing whether the patch is sound, so vulnerabilities get introduced without malicious intent.
Second, AI contributions can be automated. Where a person might create one or two contributions a day, an AI agent can generate hundreds or thousands. That is effectively a denial-of-service attack on a maintainer's time and attention - and a maintainer under that kind of pressure is more likely to make errors in review.
What I recommend is that maintainers use AI themselves, proactively. The models have improved significantly in the past year (that is, since early 2025).
I am not suggesting you use them to generate code. I am suggesting you use them to check your code for vulnerabilities. There is a documented case of a few simple questions to Claude Code finding remote code execution vulnerabilities in widely used tools.
Governments and black hats are already using these tools to probe open-source projects. Maintainers should be using them to get ahead of that.
For a broader look at where AI-generated code introduces risk in network management contexts, our earlier analysis covers the terrain in detail.
What organisations that depend on open source should do
Most of the guidance above is directed at maintainers. But if your organisation depends on open source software (and nearly every organisation does), you have both an exposure and a responsibility.
The exposure is this: the open-source projects in your software supply chain are, in many cases, maintained by a small number of people working without compensation, under social pressure from users who feel entitled to free support. That is a brittle foundation for critical infrastructure.
The responsibility is simple: pay people.
You pay your engineers to build your product. You pay your suppliers for equipment. You pay Microsoft or Google monthly fees for cloud services. Why not pay the open-source maintainers behind the tools you rely on?
Pick three or four critical open source projects in your supply chain. Contact the maintainers. Pay them $5,000 a year each. I can tell you from experience that expense will not touch your bottom line - and maintainers who are compensated pay a great deal more attention to the needs of the organisations that compensate them. They also have the resources to do better engineering.
This is what we do at InkBridge Networks, and it is why I think about software supply chain risk differently from most. We are active participants in open source. That matters when something goes wrong.
For organisations evaluating their RADIUS authentication infrastructure specifically, the same principles apply. Knowing who controls your authentication software, how releases are signed, and what the governance structure looks like is basic risk management.
The CrowdStrike outage in 2024 demonstrated what happens when organisations treat critical software infrastructure as a commodity to be consumed rather than understood. The lesson from an update gone wrong at that scale is the same lesson from xz utils and RubyGems at a smaller one: you cannot outsource accountability for the software your organisation depends on.
Need more help?
If you're evaluating your network security posture or looking for expert support on authentication infrastructure, we'd like to hear from you. InkBridge Networks works with ISPs, enterprises, and universities worldwide to build network access systems that are secure, reliable, and built to last. Reach out to request a quote.
Frequently asked questions about open source supply chain security
What are the most common open-source software supply chain risks?
The most common risks are governance failures: unclear ownership of critical assets like DNS and signing keys, excessive trust extended to unverified contributors, and maintainers operating under social pressure without adequate compensation or support. Technical scanning tools help, but they do not address the underlying vulnerability.
How do I assess software supply chain risks in my organisation?
Start with an inventory. Identify the open-source projects your organisation depends on, then ask: who maintains them? How are releases signed and verified? Who controls the DNS and infrastructure? What is the contributor vetting process? If you cannot answer these questions, you have a risk you have not yet measured.
How can I prevent supply chain attacks on open source projects I maintain?
Vet contributors carefully before granting commit access. PGP sign all commits and releases. Retain control of DNS and critical infrastructure - do not delegate it. Keep the project's scope narrow and explicitly technical. Maintain local backups you can restore from quickly. Make your project an unattractive target by removing the levers that social engineering attacks rely on.
Why is open source software considered a supply chain risk?
Open-source software is a supply chain risk for the same reason any dependency is: if it is compromised, everything built on top of it is potentially compromised. The additional factor is that many critical projects are maintained by small, under-resourced teams, making them vulnerable to both technical infiltration and organisational takeover.
How do you prevent software supply chain attacks?
Prevention requires action at two levels. Maintainers should implement strong contributor vetting, signed releases, and careful control over critical infrastructure. Organisations that depend on open source should fund the projects they rely on. An under-resourced maintainer working under constant social pressure is a vulnerability. A well-supported one with the time to do proper security reviews is not.
Related Articles
Big Tech Concentration Made CrowdStrike Update a Catastrophe
As we dissect the CrowdStrike outage, we’ll find the human error was multiplied by the concentration in Big Tech, says network security expert Alan DeKok of InkBridge Networks.
AI intrusion detection
AI excels at pattern-matching for intrusion detection but fails spectacularly when building security systems. The same technology that can spot anomalous network behaviour also generates insecure code. Understanding this paradox is the difference between a secure network and a data breach waiting to happen.