This post is interesting, but it also commits the cardinal sin of supply chain security publicizing: it doesn't communicate the magnitude of impact, only the magnitude of malicious activity.
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.
tomashertus · 3h ago
It’s ultimately a numbers game. The more malicious seeds are planted, the higher the likelihood that one of them will be pulled into a real-world build pipeline. Platforms like GitHub, NPM, and other open repositories are ideal staging grounds because very few engineering organizations are willing to block traffic from them. That makes them near-perfect hiding spots for malicious content.
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.
woodruffw · 2h ago
> The more malicious seeds are planted, the higher the likelihood that one of them will be pulled into a real-world build pipeline.
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.)
rtaylorgarlock · 1h ago
In a world where PR-focused organizations (not saying it's right or that's how it should be, but that 'it do be like it is') actively work to hide breaches on occasion? Should they not publicly success a win and support 'open source' while celebrating a dub, while giving them a sales tool / credibility?
woodruffw · 1h ago
I don't think I understand the question, sorry.
tomashertus · 3h ago
This is a surprisingly common issue. In my day-to-day work, we analyze millions to look for malware, and it’s well-known in the security community that attackers frequently leverage “trusted” websites to host and deliver malware as an evasion tactic.
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).
danielvaughn · 3h ago
No date on the page, anyone know when this was posted?
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.)
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).