#SharePointProblems | Koskila.net

Solutions are worthless unless shared! Antti K. Koskela's Personal Professional Blog

Are we learning anything from the recent GitHub hack?

Koskila
Reading Time 9 min
Word Count 1514 words
Comments 0 comments
View

A week ago, GitHub announced they've been hacked. A hacker group called TeamPCP had extracted roughly 4000 private repositories and who-knows-how-much more data from GitHub's internal systems.

This sounds like a pretty big deal (and it is!), but I fear we're not taking the right lessons from it.

GitHub accidentally open-sourcing their internal systems? Sure, that'll lead to future breaches.

But the attack vector? That's the real kicker, and studying it should lead to the practical takeaways for practitioners.

Background

Probably worth reminding you that I'm not a cyber security professional. I'm just a software engineer reading the news and watching the world burn around me.

This isn't a deep dive into the information security landscape right now or a detailed incident report (that's up to GitHub to publish - they are usually pretty good about it). Instead, I'll try to keep this practical for anyone who... Well, I suppose anyone in the software industry, but especially developers, since they are the ones most likely to be affected by this.

Anyway - much has already been said about the recent GitHub hack, but I think most of the spit takes have been about the wrong takeaways.

Cutting through the noise

A lot of the reactions and discussions I've seen have been along the lines of "don't use GitHub", "Microsoft is running GitHub into the ground", or just revolve around the misleading (but very memeable) "Unofficial GitHub Status Page":

Unofficial GitHub status page showing recurring outages and incident noise
Unofficial GitHub status page showing recurring outages and incident noise

While "uptime" is not very accurate, there's no denying GitHub has been having a rough time lately. But rather than somehow having lost engineering talent, or having a management problem, or whatever other nonsense people are coming up with, I think the real problem is that state of the world - and GitHub is just a very visible example of it.

Admittedly, the situation has led to funny takes such as:

Making fun of GitHub's poor uptime IS funny
Making fun of GitHub's poor uptime IS funny

And don't get me wrong - I enjoy the memes as much as the next person.

But is this a GitHub problem? I don't think so.

I don't think the key takeaway from this should be "don't use GitHub". I don't even think we should be looking at GitHub and pity how Microsoft is running it into the ground.

Chart about GitHub average uptime after the Microsoft acquisition
Chart about GitHub average uptime after the Microsoft acquisition

A small piece of a much bigger problem

GitHub has grown exponentially. Accommodating exponential growth when building data centers is quite linear by nature (all of the hyperscalers being capacity constrained is a testament to that) is not just a technical and business problem, but more and more a political one as well.

Even if you're hosted on Azure - the second biggest hyperscaler in the world - how do you deploy another thousand Msv3s to run your, well, Runners, when the DC's cooling system is already running at 120°C (approximately 9000°F in Freedom Units) to cool down the racks running GitHub Copilot?

Visualization of GitHub usage and demand growth increasing rapidly over time
Visualization of GitHub usage and demand growth increasing rapidly over time

The ugly fact is that AI is squeezing all of us in the middle from all sides - compute is running out, but the velocity is increasing while the already large attack surface is growing ever greater.

And GitHub is right at the heart of that velocity - all the while AI is increasingly being used to find novel methods of attack, and to automate the process of finding and exploiting vulnerabilities.

That said, it doesn't sound like the vulnerability now was rocket surgery, but a relatively simple supply chain attack - a malicious extension being published to the VS Code marketplace, which was then automatically installed on a GitHub employee's workstation, which then had access to the internal systems, and was used to exfiltrate data from them.

Sure, this all probably ties back to the earlier hacks (possibly the Mini Shai Hulud hack, which was also a supply chain attack), where TeamPCP was already able to extract plenty of credentials and other confidential information using a similar method (malicious npm package version), and will probably cash these credentials in for access to more and more systems in the coming weeks.

Following the highway to the malware factory

Back in the days of yore, automatically updating your software was the best way to make sure you're running the most secure version of it. But in today's fast-paced world, where new vulnerabilities are being discovered every day, and the supply chain is being weaponized, the calculus has changed - dramatically so!

No matter how quickly you update, you will probably always be vulnerable. Delaying updates of course means exposing yourself to known vulnerabilities. But update too quickly, and you're pretty much inviting infected updates to be installed on your machine - and that's arguably worse!

I have, of course, been conditioned to never install any updates before everyone else have bricked their machines first (Windows has, over the years, made sure of that - see My 2025 Holiday Special - Windows 11 set-up fun! for a recent example of Windows Update blowing up.)

But the fact that a malicious version of a legit extension from a verified publisher could be published to the VS Code Marketplace - where absolutely ZERO vetting is being done - and then installed automatically on hundreds of thousands of machines.

Automatically updating VS Code extensions have now become a highway directly from the malware factory to millions of workstations. And very valuable workstations at that, since developers have all sorts of access tokens and credentials persisted on their machines - not due to any negligence on their part, but simply because that's how the tools work.

Spider-Man pointing meme with Microsoft blaming Microsoft for platform failures
Spider-Man pointing meme with Microsoft blaming Microsoft for platform failures

Of course, a Microsoft entity (GitHub) getting pwned via a Microsoft tool (VS Code) used to install a malicious extension from a Microsoft-controlled, "official" marketplace (VS Code Marketplace) is somewhat ironic. But we just have to assume that M365 Copilot usage is now so high, that Microsoft can't afford to spare any inference for less-important workloads - such as AI-powered reviews of VS Code extension updates...

It isn't a technical problem - but a business/policy problem instead. Users have been trained the wrong way (for all the right reasons), Microsoft is offering free tools (with little to no oversight), and the lack of security is simply the price we pay for all that.

The implications for practitioners

A few thoughts on what practitioners should do in light of this - not all directly related to the GitHub hack, but all related to where I see the world moving:

  1. Disable auto-update for your VS Code extensions
    • What used to be a great way to keep your extensions on a version with the latest security patches is now a liability.
  2. Kon-mari your workspace
    • It's more important than EVER to not have any unnecessary extensions installed.
    • Pay extra attention to the publisher of the extension (there are typo-squatted versions of all major extensions - and they get cleaned up slowly)
  3. Be wary of dependencies: AI coding tools love to pull in dependencies, and every single one of them opens you up to new supply chain attacks. AI project scaffolding can also make up the recommended extensions for VS Code to then try and install for you - which is scary!
    • Note that AI is also very good at rewriting whatever stuff it is you're pulling from the dependency in the first place - so instead of running npm i is-odd, just burn some tokens creating the functionality yourself, and be done with it.
    • For the dependencies you do pull in, make sure to pin them to a specific version, and keep an eye on the security advisories for them.
  4. Code is not an asset; it's a liability.
    • Sounds like I'm contradicting myself - but at least code that you created yourself is a liability you are aware of, as opposed to code that you pulled in from a dependency.
  5. Bad guys use AI - but you can too!
    • While Microsoft cannot afford to analyze the extensions on VS Code Marketplace (that's understandable in the case of such a cash-strapped startup), you can't afford to save in the wrong place! Use AI to analyze the autogenerated code and dependencies for security issues.

So in short: Vet your extensions, pin your dependencies, use AI mindfully, and be careful with automatic updates.

And sure, maybe don't ask Copilot to rewrite the whole axios library - but in the age of AI, code reusability or sprawl feels like a smaller problem than before, and the risk of supply chain attacks feels like a much bigger one.

Thoughts? Corrections? Opinions?

Feel free to share them in the comments (in whatever social channel you prefer, because I've still not implemented comments on this static site of mine 🙈)!

References

Comments

Interactive comments not implemented yet. Showing legacy comments migrated from WordPress.

No comments yet.

Whitewater Magpie Ltd.
© 2026
Static Site Generation timestamp: 2026-05-26T14:13:55Z