How to Keep Your Open Source Projects Safer
One Misspelled Package Exposed the Trail of Modern Software Supply Chains.
Installing a Package? Why Every Dependency Matters
On the morning of his PyCon US talk, Dave Ferguson, a cybersecurity expert of 20 years, thought he’d prepared everything. The slides were polished. The demo code was tested. He typed the final example onto the screen—an import statement for the Python package “requests.” But his fingers slipped.
“reqquuests.”
The code still ran. No errors. No warnings.
What Ferguson had just done, in front of hundreds of developers, was accidentally import a fake package—one seeded into the open source ecosystem by someone banking on a typo. It could have been anything: a crypto miner, a credential stealer, a surveillance tool. This one, mercifully, was already flagged by his colleagues in ReversingLab’s database. But in another context, on another day, it might have gone unnoticed. And the damage could have been catastrophic.
That’s the nature of today’s software supply chain. What looks like a simple mistake might be the first domino in a breach so complex, it takes months—or years—to detect.
The Oregon Trail, Rewritten in Code
In the 1990s, children across America learned frontier survival skills not from history books, but from a game: The Oregon Trail. You loaded a wagon in Missouri, picked a profession—banker, farmer, carpenter—and set off west. The goal was: survive.
You could starve, drown, get cholera from bad water, or die of snakebite. Every choice mattered. Which supplies you carried. Which rivers you crossed. Whether you slowed down for a sick companion or pressed on.
Kadi McKean, who leads the open source community at ReversingLabs, believes this game still holds lessons. Only, now, the settlers are developers. The rivers are build systems. And the diseases? They live in the code.
During a recent talk for the Open Source Architect (OSA) Community, McKean and Ferguson reframed modern development as a digital Oregon Trail. A journey where collaboration, caution, and a healthy fear of ambush determine whether your code makes it to production—or dies somewhere along the way.
Departure: Packing the Wagon
A developer needs to ship a feature. She installs a package. It has a familiar name. It works. She moves on.
But was it safe?
In 2021, ua-parser-js—a Node.js package downloaded seven million times a week—was hijacked. For five days, it distributed malware from trusted channels. The package name never changed. The functionality didn’t either. But somewhere upstream, the river was poisoned.
The assumption that “popular means secure” no longer holds.
Typosquatting Can Compromise Your App
Imagine a wagon train. Dozens of travelers, each with a role. The developer is the scout. The operations team manages the supplies. Security? They’re the ones scanning the horizon for danger.
The trouble is, they don’t always talk.
Developers tend to prioritize speed. Features. Deadlines.
Security teams tend to value integrity. Audit logs. Threat models.
Operations teams focus on uptime. Stability. Rollbacks
They want different things, at different times, with different incentives. And that’s when mistakes happen—not just individual errors, but also systemic blind spots.
Fatigue creates blindspots. And attackers know this. When thousands of security alerts pour in daily, teams tune them out.
Typosquatting—like the one Ferguson demoed—is part of the attacker’s fatigue strategy. A single character swapped in a package name can redirect entire systems to malicious payloads. And in a modern environment moving faster than ever, it often works.
The River Crossing: Build Systems
In The Oregon Trial, rivers were the most dangerous part. You had to choose: caulk the wagon, ferry across, or ford it directly. Pick wrong, and you could lose supplies, livestock, and even lives.
In software, the river is the build system. CI/CD pipelines. Jenkins servers. GitHub Actions workflows. The place where code is assembled, tested, and prepared for release.
In 2020, attackers slipped past SolarWind’s build pipeline. They poisoned the output. Signed binaries, trusted by governments and Fortune 500 companies alike, were carrying backdoors.
Build systems themselves can often be the most dangerous part of a developer’s journey.
Forts and Waypoints: When to Stop and Scan
ReversingLabs built secure.software to be a kind of digital trading post—a free portal where developers can scan packages across npm, PyPl, NuGet, RubyGems, and VS Code extensions. The goal isn’t just to flag malware, but to surface “bad behavior”—unexpected script execution, obfuscated files, privilege escalations.
They advocate reproducible builds. Behavior-based assessments. And hash comparisons between environments. If two identical builds don’t produce identical results, something’s gone wrong.
Snake Bite: Log4Shell and the Myth of the Clean Codebase
On December 9, 2021, a teenager posted a strange proof-of-concept on GitHub. It looked innocent. Harmless, even. Within 48 hours, that line of code had become the most weaponized vulnerability in internet history.
It became known as Log4Shell.
The most astonishing detail was that the vulnerable line of code had been sitting in the open since 2013.
That’s the real terror of the software supply chain. It’s not the code you wrote that kills you. It’s the code you imported, trusted, and forgot to check.
When AI Joins the Party
If traditional software is a wagon train, AI is a thunderstorm.
Developers are using large language models to generate code. Helpful, yes. But risky. McKean and Ferguson cited instances where LLMs unknowingly injected insecure boilerplate—or worse, embedded known vulnerabilities.
In machine learning, Python’s pickle files are often used to serialize models. But at deserialization, these files can activate arbitrary code.
Jim Manico, a respected secure coding advocate, is working on AI prompt guidelines to prevent such mishaps. But until tools natively bake in security, we’ll be treating symptoms instead of disease.
The New Security Mantra
“Shift left” has been the security mantra for a decade. Test early. Catch issues at the source.
But Ferguson sees a more urgent shift.
SolarWinds is one example.
In all wide-spread cases, the attacks didn’t happen in production. They happened in the pipeline. Trusted systems were compromised before deployment ever began.
So now the mantra is: shift everywhere.
Pre-commit:
Scan dependencies, secrets, and licenses.
Build time:
Verify artifacts. Compare hashes. Enforce policies.
Post-deploy:
Monitor for drift, abuse, and anomalies.
The Software Supply Chain Trail
The paradox of modern software is that it moves faster than many can understand it. Code ships before it is reviewed. Libraries are trusted before they’re known. What should be a chain of logic is often a trail of faith.
But something else is happening too.
Travis Oliphant, the creator of NumPy and founder of OpenTeams, put it best:
“These community-led projects allow for global cooperation and sharing that inspires and enables us all. They allow anyone in the world to go from interested user to contributor to maintainer to project leader—if given the interest, ability, and opportunity.”
We’re progressing from an engineering model to a social one. Anyone can contribute. Anyone can be the secret piece we all need.
We’re walking with others—checking often, sharing knowledge, and remembering what’s behind each package.
That’s how we go far. Together.
That’s the story of open source.
Watch the Full Session
Watch the full session, Surviving the Software Supply Chain Trail, on the OpenTeams YouTube channel. Join the OSA Community public feed on LinkedIn to connect with fellow open source software trail blazers.
Thanks to Kadi McKean and Dave Ferguson of ReversingLabs, and to Inessa Pawson of OpenTeams.