The GitHub Breach Through VS Code Is the One I Warned About

If you haven’t heard the news, GitHub confirmed unauthorized access to internal repositories through a malicious VS Code extension. I’ve been warning about this. I predicted it would happen in my talk Compromising Developers with Malicious Extensions last December at Black Hat MEA, where I presented several flaws in VS Code and the marketplace and how people can use them to run supply chain attacks.

We still don’t have the full details yet, but here’s how I see it.

We’ve always had a problem prioritizing risks as an industry. Supply chain attacks have always been underrated. For example, NPM packages are not a new attack surface; they’ve been known as one of the risks for a long time, and the industry only started building security around them in the past four years. SBOM has been the standard. Have people used it? Not really. Did it prevent attacks? No, I don’t think so. The Trivy breach was an alert that this was going to happen, and that it was just the beginning.

With my research on VS Code extensions, I presented an attack surface that people have been ignoring for years. The VS Code marketplace has been there since 2018. Whatever controls exist today, this incident validates they are not sufficient. It’s not that people didn’t know about this - they did.

What we should be doing is figuring out why this extension was allowed to the marketplace in the first place. In my talk, I presented a set of defenses people could implement, and I shared controls Microsoft could implement to enhance the marketplace. I’m unaware of any changes that have been made since.

And that’s not all. We’ve also failed as an industry to address this. With all the noise around AI and the race to AGI, we forget the basic foundations, and the supply chain is one of them.

This is not the first breach of its kind, and it’s not going to be the last. GitHub is the first company to publicly share that they were compromised in this campaign. A large part of that is because of their mature security controls - they were able to detect the attack.

It would not surprise me if there are dozens of organizations, maybe a few hundred, that have been compromised through malicious or compromised extensions and these organizations don’t know about it yet. We will probably never see that data or learn about these breaches too.

The question is: what are we going to do about it?

Last year, I recommended having an allowlist of dependencies. Unfortunately, there are no open source tools to facilitate building security controls for IDEs across an organization. This is a good candidate for an open source proxy. There are a few commercial vendors I’ve tested and they work on solving the problem. This post isn’t an endorsement of any one of them, do your own research. A lot of people are working on the same problem.

Roughly 3,800 repositories were compromised in this campaign according to the hacking group that claimed responsibility for the breach. The same kind of issue exists in OpenVSX - the marketplace that powers Cursor is vulnerable to the same attacks I presented.

This is not an IDE problem. It is a software supply-chain governance problem.

I’ll end with one question: if this attack were replicated inside your organization, would you be able to detect it?

Best Regards,
Mazin