Rupert Marais is a leading voice in the world of endpoint security and network management, bringing a wealth of tactical knowledge to the fight against evolving cyber threats. As a specialist in cybersecurity strategies, he has witnessed a dramatic transformation in how attackers infiltrate the software supply chain. Rather than relying on simple human error, modern adversaries are now leveraging the very logic of development workflows to plant sophisticated traps in plain sight, making his expertise more critical than ever for organizations trying to secure their build pipelines.
How has the landscape of malicious open-source packages shifted away from simple typosquatting, and why should this change concern development teams today?
The shift we are seeing is a calculated move toward sophistication where attackers no longer rely on a developer’s “fat-fingered” typing mistakes. Our latest analysis of 4,309 malicious packages revealed a startling reality: a massive 91% of these threats used naming-variant tactics rather than the classic typosquatting we have spent years defending against. Only about 9% of the packages were actually dependent on spelling slips, which means our traditional defenses are essentially looking for the wrong signals. By disguising themselves as plausible plugins or configuration helpers, these packages feel like a natural part of a professional environment, allowing them to bypass the initial gut-check a developer might perform during a routine installation.
With suffix addition accounting for nearly half of these cases, how do attackers use the natural language of coding ecosystems to bypass a developer’s intuition?
Attackers have become students of the developer’s daily rhythm, adopting the suffixes, prefixes, and versioning styles that feel familiar and safe. Suffix addition is currently the most dominant tactic, used in 43.6% of the cases we recorded, because it mimics how legitimate software development kits and wrappers are organized. When a developer sees a package appended with terms like “plugin,” “config,” or “sdk,” it rarely triggers an alarm because they expect popular frameworks to have a long tail of these helper modules. This gives attackers the breathing room they need to hide multi-stage malicious behavior right under the nose of even the most diligent engineering teams.
When these disguised packages successfully infiltrate a system, what specific malicious behaviors are most commonly observed, and what are the stakes for the organization?
Once these components are pulled into a local environment, they quickly transition from harmless-looking code to active instruments of theft. The most common behaviors we’ve identified are the exfiltration of host data and secrets, which can expose everything from environment variables to private API keys. We are also seeing a heavy use of droppers and backdoors that turn a standard dependency install into a wide-open door for follow-on compromises and deep credential theft. It’s a gut-wrenching realization for a security team to discover that a “helper” tool has been silently vacuuming up sensitive data from a developer’s machine for weeks.
React and ESLint have become primary targets for these adjacent package attacks; what specific vulnerabilities in how we use these tools allow attackers to hide so effectively?
The popularity and vastness of these ecosystems create the perfect camouflage for malicious actors who are looking to blend into the crowd. React topped our list as the most targeted ecosystem with 540 malicious packages, followed closely by the ESLint and Tailwind library ecosystems. These platforms are attractive because they are heavily reliant on add-ons and external configs, creating a noisy environment where it is easy to lose track of every single dependency. We are seeing a clear industrialization of these threats, where the same infrastructure and naming patterns are reused across entire campaigns, making it a professionalized effort to exploit the trust within these specific communities.
Given that traditional reputation checks are failing, how should security teams evolve their defense strategies to handle these campaigns at a publisher level?
We have reached a point where checking a single package’s reputation or looking for a typo is like bringing a knife to a gunfight; it’s simply not enough anymore. Organizations must begin adding intentional friction for any “first-seen” dependencies, treating anything that looks framework-adjacent with a high degree of skepticism. Instead of looking at components in isolation, defenders need to assess threats at the campaign and publisher levels to spot the reused identities and patterns that reveal a larger attack. We have to scrutinize the behavior and history of the publisher before any component is allowed to enter the build process, or we risk letting the wolf right through the front door.
What is your forecast for the future of open-source security?
I believe we are entering an era where the “reputation” of a package will be much harder to define, as attackers start copying the structure and habits of real software ecosystems with terrifying precision. We will see more “sleeper” packages that sit on a machine to build a fake history of legitimacy before ever executing a malicious payload. As these naming-variant tactics become the industry standard for hackers, the only way to stay ahead will be through automated, behavioral-based analysis that can spot these multi-stage threats in real-time. Our reliance on open source isn’t going away, so our ability to verify the “who” and the “how” behind a package will become the most important metric in any security stack.
