Software supply chain risk stopped being a story about code in 2025. It became a story about people. The fastest way into a company this year was not a zero-day or a brute-forced password. It was a tired volunteer maintainer clicking a convincing login page, and the poisoned package that rode their trusted name downstream to everyone who depended on it. Your dependencies are now your attack surface, and the weakest link in that surface is usually human.

I am Amelia Gagne, CEO of Kief Studio. I want to walk through what actually changed this year, because the headlines keep covering each incident as if it were a freak event. It is not. There is a clear pattern underneath, and once you see it, the right response stops looking like fear and starts looking like ordinary good hygiene.

What software supply chain risk looks like in 2026

The numbers are not subtle. In 2025, Sonatype identified more than 454,600 new malicious packages, pushing the cumulative total of known and blocked open-source malware past 1.23 million. Over 99% of it landed in a single ecosystem, npm, which tells you attackers go where the dependencies are deepest and the trust is most automated.

The sophistication climbed with the volume. The year produced the first self-replicating worm in the npm ecosystem, Shai-Hulud, which stole maintainer tokens and used them to publish poisoned versions of still more packages, turning every compromised pipeline into a new launch point. One variant even managed to compromise packages carrying valid SLSA Build Level 3 provenance, the exact attestation that was supposed to prove a build had not been tampered with. When the integrity control itself can be defeated, you learn quickly that no single control is enough.

This is the modern shape of what supply chain attacks actually are: the risk does not break down your door. It arrives inside something you already invited in.

A single hot-pink chain link under tension with a hairline fracture, illustrating software supply chain risk concentrating at one weak point — The break rarely happens where the chain is strongest. It happens at the one link under quiet, unwatched tension.

The attacker's easiest path is the person, not the package

Look at how the big 2025 incidents actually started. On npm, a maintainer of chalk and debug, libraries pulled billions of times a week, got caught by a phishing email. Weeks earlier on PyPI, four maintainers handed credentials to a spoofed login page, and malicious versions of trusted packages briefly slipped into production pipelines. Two different registries, the same play, run a few weeks apart.

As Sonatype put it plainly, the path of least resistance is still the human sitting behind a maintainer account. That is not a knock on maintainers. These are mostly unpaid volunteers holding up infrastructure the entire economy runs on. It is a statement about where the soft spot is, and it should change where you point your attention. The same logic behind how phishing actually works against your own staff applies to every maintainer in your dependency tree.

The AUR incident is the lesson in miniature

If you want one clean example, look at what happened to the Arch User Repository. In June 2026, attackers took over roughly 1,500 abandoned community packages, not by breaking anything, but by using the legitimate process that lets a volunteer adopt a project when the original author walks away. They inherited years of accumulated trust and changed only the build instructions, never the visible code. My team wrote the full leadership breakdown in Trust Was the Target, and it is the best short case study I know of for this entire category of risk.

What makes the AUR a useful teacher is that its trust model is honest about itself. There is no code review before a package goes live. You are trusting a stranger's build script to do exactly what it claims. That transparency is a feature, because it makes the verification step obvious instead of hidden. The same gap exists in npm and PyPI; it is just buried under more automation, which is precisely why your lockfile is a threat surface worth treating as one.

Verification can be cheap, free, and built in

Here is the part the fear coverage skips. The answer to all of this is not to abandon open source or to buy an expensive platform. It is to make verification so cheap and habitual that it stops feeling like work. Read the build script before you build. Treat a freshly adopted package, or one that suddenly grows new install hooks, with the caution you would give a stranger at your door. Check what an artifact declares against public reputation data before you run it.

This week gave a nice illustration of the ecosystem self-correcting. FOSS Linux published a hands-on AUR security guide by Sarah L. on June 20, 2026, walking Arch users through manual PKGBUILD audits and the new yay v13 Lua security hooks. In it, the author independently points readers to two free scanning tools that detect common malicious PKGBUILD patterns, noting they are not a substitute for manual review but are a strong first pass. One of those tools, ks-aur-scanner, is one my team maintains. We give it away on purpose. If our response to a community under attack were to put the remedy behind a paywall, we would have misunderstood our own values.

The free ks-aur-scanner home page, a Kief Studio tool that reads an AUR package and its dependency tree before anything runs, reducing software supply chain risk — The free ks-aur-scanner reads a package and its whole dependency tree before anything runs. Verification as a cheap first pass, not a substitute for reading the build script yourself.

Threat intelligence view of ks-aur-scanner, checking a package's declared hashes and source URLs against public reputation data — The scanner checks what a package declares against public reputation data before you build it. The kind of habitual verification the 2025 supply chain incidents made urgent.

That is the standard I would set for any verification tooling you adopt: it should make the safe path the easy path, and it should be honest about its limits. A scanner that promises to catch everything is selling you a feeling, not a control. Pair tooling with human review and you get something durable. This is also why I treat free tools as proof of work rather than charity, and why the questions in what to ask your vendors about security matter as much as any product you buy.

What this means for how you run a business

You extend trust to vendors, contractors, dependencies, and tools every single day. You have to, or nothing ships. The job is not to stop trusting. It is to pair trust with verification cheap enough to actually use, so that trusting is a decision rather than a gamble. That is the same instinct behind understanding what a vendor's security posture means for you, and it is why we hold that compliance is a side effect of how you build rather than a quarterly audit you run after something breaks.

None of this requires alarm. It requires the same prevention habits that cost a fraction of recovery, applied to the dependency layer with the same seriousness you already give your passwords and your backups. Trust the people in your supply chain. Verify the artifacts they ship. Both, every time.

kief.dev developer tools home page, where Kief Studio publishes free tools for reducing software supply chain risk across package ecosystems — Our developer tools site, kief.dev, puts the free dependency-verification tooling in one place. Giving the basics away is the point, not the exception.

Frequently Asked Questions

What is software supply chain risk?

Software supply chain risk is the exposure your business inherits from the third-party code, dependencies, and vendors you rely on to build and run software. In 2025, Sonatype counted more than 454,600 new malicious open-source packages, most of them on npm, meaning the dependency layer is now an active attack surface rather than a background detail.

Why are maintainers being targeted instead of code?

Because it is easier. The major 2025 incidents on npm and PyPI began with phishing emails and spoofed login pages aimed at trusted maintainers, not with software exploits. Stealing a maintainer's credentials lets an attacker publish a poisoned version under a name millions of people already trust, which spreads far faster than breaking any single system.

How do I reduce software supply chain risk without slowing my team down?

Make verification cheap and habitual. Read build scripts before running them, treat newly adopted or suddenly changed packages with caution, and check artifacts against public reputation data using free scanning tools as a first pass. Pair automated scanning with human review, since no scanner catches everything.

Is open source too risky to depend on?

No. Open source is not broken because it runs on community trust; it is incomplete when that trust is not paired with verification. The healthy response to incidents like the AUR takeover is to make the commons more resilient through built-in verification, not to retreat from it.

The free scanner my team maintains: github.com/KiefStudioMA/ks-aur-scanner. Kief Studio helps good people do good things.

Sources: Sonatype State of the Software Supply Chain 2026, SecurityWeek: Shai-Hulud, and FOSS Linux: AUR Supply Chain Security.

Software Supply Chain

Software Supply Chain Risk Is a People Problem Now