In a single week, three distinct supply chain attack campaigns surfaced — each targeting a different link in the software supply chain.
What Happened #
AppsFlyer SDK Compromise. A widely-used mobile analytics SDK was compromised, turning it into a distribution mechanism for cryptocurrency-stealing malware. Every app developer using the affected version unknowingly shipped the stealer to their users.
GlassWorm GitHub Hijacking. A threat actor dubbed GlassWorm hijacked hundreds of GitHub repositories using blockchain-based command and control infrastructure. The campaign injected malicious code into open source projects that downstream consumers pull into their builds.
Clinejection. A prompt injection attack targeted the AI-powered issue triager for Cline, a popular developer tool. The attack compromised Cline’s production releases — meaning a tool developers trust to help them write code was itself compromised through its own AI features.
Three attacks. Three different vectors. One common theme: organizations were compromised not through their own systems, but through the software and services they depend on.
Why This Keeps Happening #
Supply chain attacks are attractive because they offer leverage. Compromise one SDK, and you reach every application that uses it. Poison one GitHub repo, and you reach every project that imports it. Subvert one developer tool, and you’re inside every developer’s environment.
The economics are simple: why attack one target when you can attack the tool that a thousand targets use?
And the problem is getting worse. As organizations improve their perimeter security, attackers shift to the weakest link — which is often a third-party dependency that nobody’s actively monitoring.
What Most Organizations Get Wrong #
Vendor risk is treated as a procurement exercise. The standard approach — send a questionnaire during onboarding, file the responses, revisit annually — doesn’t match the speed at which supply chain attacks evolve. A vendor can be secure on Monday and compromised on Tuesday.
Software dependencies aren’t tracked as vendors. When security teams think “vendor risk,” they think SaaS platforms and managed service providers. They don’t think about the 200+ open source packages in their build pipeline. But as the GlassWorm and Clinejection attacks demonstrate, those dependencies carry just as much risk.
There’s no continuous monitoring. Annual assessments capture a point-in-time snapshot. Supply chain attacks happen in between those snapshots.
What to Do About It #
Inventory your dependencies. You can’t manage risk you can’t see. Software composition analysis (SCA) tools and software bills of materials (SBOMs) are table stakes in 2026. If you don’t have a current picture of what third-party code runs in your environment, start there.
Tier your vendors by impact. Not every vendor carries the same risk. An SDK embedded in your product has a different blast radius than a marketing analytics tool. Focus your deepest scrutiny on vendors and dependencies that have access to sensitive data or sit in your critical path.
Monitor continuously. Subscribe to security advisories for your key dependencies. Use automated tooling to flag when a dependency publishes an unexpected update or changes maintainers. Set up alerts for vendor breaches.
Have a supply chain incident response plan. When a dependency is compromised, how fast can you identify whether you’re affected? How quickly can you roll back to a known-good version? If you don’t have answers to these questions, you’re not ready.
The Uncomfortable Reality #
A vendor breach is your breach. That’s not a scare tactic — it’s the operating reality of modern software. The organizations that recognize this and build vendor risk programs with the same rigor they apply to their own security are the ones that will weather these incidents.
The ones treating vendor risk as a compliance checkbox will keep being surprised.