The technique is so pervasive that I did an extensive research on it. In fact, there are several well-funded and widely used applications, some generating millions in revenue, that unknowingly host malware on their infrastructure. In more concerning cases, these platforms are even repurposed as command-and-control servers for data exfiltration. We're increasingly seeing enterprises take the proactive step of blocking traffic to these high-risk domains entirely to strengthen their security posture (e.g. it's completely common to block all traffic from network to Dropbox or other file hosting services).
This is the same pattern that recurs with breathless reporting on malware in the NPM, PyPI, etc. ecosystems -- the fact that an actor has uploaded hundreds of malicious packages (repos, etc.) means very little if nobody actually downloaded or executed the code from those packages.
That isn't to say that that's what's happened here, but I think this post would be much better if it went beyond 2,400 malicious repositories and gave an indication of how many downstreams were actually affected.
And the asymmetry is stark: attackers only need to succeed once. It takes just a single developer installing a compromised package to trigger a breach with potentially massive downstream consequences. So while I agree that quantifying impact is critical, dismissing large-scale seeding campaigns because “no one might have downloaded it” ignores the risk.
Sure, but you still need to show the impact. Not all "seeds" are equal; that's why we categorize attacks as either opportunistic or targeted (and within that, there's the kind of "lazy" opportunism of package spam versus "motivated" opportunism of trying to trick developers into using a specific compromised package).
(And to be clear, I'm not ignoring the risk here! I believe we can do better about qualifying the risk, which does exist.)
brollie•4h ago