Build & Defend Newsletter 16

Today's topic is: permission surfaces. It's much more apropos after this morning's Github compromise....

Not trusting tools.

Trusted tools.

That distinction matters.

Because a lot of modern security advice still sounds like it was written for 2007:

Don't click suspicious links. Don't enter your password on weird websites. Use MFA. Don't download strange attachments from people claiming to be Nigerian princes, tax authorities, parcel companies, or your CEO urgently needing Apple gift cards.

All good advice. Still true.

But increasingly, the dangerous click isn't "Enter your password", it's: "Install this extension", or "Authorise this app", or "Grant this permission", "Connect this website", "Log in through here", or, most recently: "Let this AI tool access your repo so it can help you build."

This morning (I'm glad I got lazy last night), GitHub — yes, Microsoft-owned GitHub — said it had detected and contained a compromise involving an employee device and a poisoned Visual Studio Code extension.

(Is it karma for them giving my email address to the Democrats? Probably.)

The attackers claimed to have exfiltrated thousands of internal GitHub repositories.

GitHub's current public assessment, as I understand it, is that the activity involved GitHub-internal repositories, not customer repositories. They also said they were rotating secrets and prioritising the highest-impact credentials. That's good. It's the least they can do at this point.

But the interesting part is not only GitHub.

The interesting part is the path in.

A developer tool - a VS Code extension. That was supposed to be helpful. It was, I guess, for the attackers.

Something that, by design, lives inside the environment where the valuable stuff is.

I love useful tools. This should be obvious by now.

I use AI agents. I use local AI. I use cloud tools. I use code editors (well, XCode, and Sublime). I use extensions. I use automations. I use terminals, scripts, plugins, APIs, and all sorts of little bits of software that make the computer do more of what I want. Been doing that for forty-five years now. Yes, that long.

That's kinda the whole point of computers. They give you leverage! Especially now with AI .... I no longer do system set up for example. AIs can format your code, autocomplete your work, find bugs, connect to services, manage containers, run tests, check spelling, talk to GitHub, talk to Jira, talk to Slack, talk to cloud providers, talk to AI models, and quietly become part of your working life.

Which is exactly why these tools are so valuable to attackers.

The closer a tool is to your workflow, the closer it is to your secrets.

A VS Code extension might be able to see:

Maybe not all of that in every case. Permissions and architectures differ. But still. Developer tools are not just conveniences. They are part of the supply chain.

The same is true outside software development.

A browser extension can see what you browse. An OAuth app can access your email, calendar, files, Slack, Google Drive, Microsoft 365, or GitHub account. A mobile app can ask for contacts, location, photos, microphone, Bluetooth, local network access, notifications, or background refresh. A package from npm or PyPI can run during install or import. A GitHub Action can touch your build pipeline. An AI coding assistant can see your repo and sometimes write to it. An automation platform can sit between all your accounts like a cheerful little octopus with API keys.

This is the modern productivity stack. It's also the modern attack surface.

And that's the tension.

We want leverage.

But leverage means trust.

And trust means blast radius.

The old security model was mostly about login. Who knows the password?

Then it became:

Who has the password and the second factor?

Now it is also:

What have you already authorized? That is the bit people miss. MFA is good. You should use it. I have said this before and will say it again, probably until my final newsletter is just the words "turn on MFA" repeated until someone unsubscribes me from life.

But MFA doesn't solve everything. If you install a malicious extension, MFA may not help. If you grant an OAuth app access to your mailbox, MFA may not help. If a package steals a token from your environment, MFA may not help. If a tool gets access to a developer machine that already has credentials, MFA may not help. Because the attacker isn't always trying to log in as you from scratch. Sometimes they are using the trust you already gave to something else.

That's the permission surface.

Not 'attack surface' in the abstract.

Permission surface.

All the things you have allowed to act near you, for you, or as you.

And most people have no idea what that surface looks like.

I don't say that smugly. I am included in "most people" often enough. Everyone accumulates things.

Old browser extensions. Old OAuth apps. Old GitHub tokens. Old npm tokens. Old SSH keys. Old automations. Old automations. Old mobile apps. Old API keys. Old test accounts. Old "temporary" permissions from three years ago. Old things you installed because one tutorial told you to.

Individually, each one seems harmless.

Collectively, they become unmanaged infrastructure.

Which is my least favourite kind, because it is still infrastructure, except now it is lying to you. (Or you're lying to you - sometimes the line is very blurry.)

So how do we defend this?

First, review your editor extensions.

If you use VS Code, Cursor, Xcode, or anything else with plugins/extensions, take ten minutes and look at what is installed.

Ask:

Don't treat download count as holiness. Popular things get compromised too. Sometimes malicious authors create bots to download their own packages to inflate download counts. Either way, obscurity plus broad access plus neglect is not a combination I love.

Second, review connected apps.

Google has this. Microsoft has this. GitHub has this. Slack has this. Notion has this. Nearly every serious SaaS has some version of "apps connected to your account."

Go look.

You will probably find something weird.

Remove anything you don't actively use.

Third, rotate tokens when something smells wrong.

If a machine, extension, package, or automation is suspected of compromise, don't just uninstall the thing and go make coffee.

Assume nearby secrets may be exposed.

That might mean rotating:

This is annoying. And tedious. And annoying and tedious.

Security is often the art of doing annoying things before they become catastrophic things.

Fourth, separate workspaces.

Your experimental AI/coding/plugin playground should not have the same access as your production environment. This is one reason I like the idea of private agent servers and controlled infrastructure, but it is also why I don't want every random tool to have every key to every kingdom.

Use separate accounts where it makes sense. Separate machines or VMs where it makes sense. Separate browser profiles. Separate tokens. Separate roles. Isolation is not just for keeping your billing obvious, it limits blast radiuses as well.

Boring separation is underrated. Really underrated.

Fifth, treat developer machines like production-adjacent systems.

A developer laptop is not "just a laptop."

It may have more access than the production server.

That machine may have the keys to build, deploy, modify, exfiltrate, or destroy the thing.

If your developer machine can push code, access secrets, deploy builds, or run agents, then it is part of the security boundary.

This matters even more with AI agents. An AI can help; an agent can do things.

It's going to take a few hours, and you're probably not going to want to do it. Put it in Sunsama, and then every day, move it to the next day. Eventually, it'll have been there so long that you'll just do it because you're so annoyed at having to keep moving it. Not that that's how I work or anything....

Create a trust inventory.

Not a full enterprise asset management system. Not a 400-page compliance exercise. Just a list.

Make a note called something like: "Things I Have Authorised"

Then list:

(also check Gitlab, which is what I use because I try not to use Microsoft anything)

For each one, write:

That last question is the useful one. (Not so much the mirror universe part, but the turning evil bit.)

(On shuffle just now: "Devil with the Green Eyes", Matthew Sweet. What is the universe trying to say!?!?)

What happens if this turns evil?

If the answer is "it can read everything and deploy to production," maybe give that one a little more thought.

This is also a good job for an AI agent, carefully constrained.

Not an agent with authority to delete everything. An auditor agent.

One that checks, reports, and like a good spouse, nags at you.

Every month:

Then it sends you a report.

Not glamorous.

Just a really very intelligent system. (See what I did there?)

As I said last week, maybe agents are not just builders.

Maybe some of the best agents are watchers. (Quis custodiet ipsos custodes? (I love Latin. Really glad I took it in high school.))

The Hacker News: GitHub Investigating TeamPCP Claimed Breach of ~4,000 Internal Repositories
Useful summary of the reported GitHub incident and the poisoned VS Code extension angle.

GitHub Docs: Reviewing your authorized OAuth apps
Worth doing if you use GitHub for anything important.

Microsoft / GitHub Security Best Practices
Especially around tokens, secret scanning, and least privilege.

OWASP: Software Supply Chain Security
Because your dependencies, extensions, packages, and build tools are part of your security story now.

Simon Willison: The Lethal Trifecta for AI Agents
Still one of the best simple framings for why tools with access to private data, untrusted content, and external actions need guardrails.

Mastering the Command Line for AI: 50 Essential Commands for the Age of AI
Plugging my own book in my newsletter…. who’d have thought?

No one as of yet has responded on the whole "should I report rental income as passive income" debate, but I appreciate that at least three of you are new here. I'm going with "Still at $325 per month" in passive income for now.

Like the newsletter? Feel free to tell someone else! 😄

Thanks for reading this newsletter! Feel free to respond any time.

Thomas

Was this forwarded to you? Subscribe at builddefend.fyi.

Had enough? [Unsubscribe] - no hard feelings.*

* Well, a little bit.