“Recent attacks show that hackers keep using the same tricks to sneak bad code into popular software registries,” writes long-time Slashdot reader selinux geek, suggesting that “the real problem is how these registries are built, making these attacks likely to keep happening.” After all, npm wasn’t the only software library hit by a supply chain attack, argues the Linux Security blog. “PyPI and Docker Hub both faced their own compromises in 2025, and the overlaps are impossible to ignore.” * Phishing has always been the low-hanging fruit. In 2025, it wasn’t just effective once — it was the entry point for multiple registry breaches, all occurring close together in different ecosystems... The real problem isn’t that phishing happened. It’s that there weren’t enough safeguards to blunt the impact. One stolen password shouldn’t be all it takes to poison an entire ecosystem. Yet in 2025, that’s exactly how it played out... Even if every maintainer spotted every lure, registries left gaps that attackers could walk through without much effort. The problem wasn’t social engineering this time. It was how little verification stood between an attacker and the “publish” button. Weak authentication and missing provenance were the quiet enablers in 2025... Sometimes the registry itself offers the path in. When the failure is at the registry level, admins don’t get an alert, a log entry, or any hint that something went wrong. That’s what makes it so dangerous. The compromise appears to be a normal update until it reaches the downstream system... It shifts the risk from human error to systemic design.

And once that weakly authenticated code gets in, it doesn’t always go away quickly, which leads straight into the persistence problem... Once an artifact is published, it spreads into mirrors, caches, and derivative builds. Removing the original upload doesn’t erase all the copies... From our perspective at LinuxSecurity, this isn’t about slow cleanup; it’s about architecture. Registries have no universally reliable kill switch once trust is broken. Even after removal, poisoned base images replicate across mirrors, caches, and derivative builds, meaning developers may keep pulling them in long after the registry itself is “clean.”

The article condlues that “To us at LinuxSecurity, the real vulnerability isn’t phishing emails or stolen tokens — it’s the way registries are built. They distribute code without embedding security guarantees. That design ensures supply chain attacks won’t be rare anomalies, but recurring events.“BR> So in a world where “the only safe assumption is that the code you consume may already be compromised,” they argue, developers should look to controls they can enforce themselves:

• • Verify artifacts with signatures or provenance tools.*
• • Pin dependencies to specific, trusted versions.*
• • Generate and track SBOMs so you know exactly what’s in your stack.*
• • Scan continuously, not just at the point of install.*