[alexfoo]

The problem is that the main target for these repos are the internal IaaS type repos that contain much of the juicy information.

A fine grained token is likely to have read access to the IaaS repo as that is likely the very repo they are operating on when the malware compromises them.

3800 repos up for blackmail may make a good headline but it's likely that Github don't really care about 3798 of those repos being made public. It'd be annoying for those 3798 to be made public but they can deal with that. It's the 2 repos that contain really important stuff that they really don't want to be made public. You can't rely on fine grained tokens to limit the leak of these things as, at some point, someone with that very access will get compromised.

Limiting TTL on tokens/auth isn't a perfect solution either. If the token is leaked via some malware it can be used to clone repos within minutes (even seconds) of being leaked. No-one wants to have to perform 2FA every few seconds in order to get on with their day.

IP based restrictions may help, but then the malware would probably evolve to include a tailscale/wireguard key so that the clone/exfiltration is done from the existing IP address and then the data is proxied away separately.

Future dev environments are going to be heavily sandboxed in terms of "do github stuff in this sandbox, copy files to another sandbox to do package updates, vet everything coming back, etc"

[schpet]

i was more thinking like, if i am working on project ABC for org XYZ it's understandable that if my dev vm gets owned that ABC is leaked. it's not that acceptable if all of org XYZ's repos that i have access to get leaked. and especially not acceptable if everything i have access to, including other orgs, and the admin ability to do destructive operations on them, gets exposed. but status quo is that that's absolutely the case, and you basically need org specific github accounts to reduce the risk of that. or use the knee-capped fine grained PATs that github offers but don't work for common things like seeing if your PR is green.

agree generally with what your getting at though: doesn't solve this problem. but even just a basic reduction in blast radius would be nice.

[alexfoo]

I completely agree, but I don't think many developers will enjoy the new hoops that will need to be jumped through in order to do various things more securely.

Having to switch between accounts with different tokens with vastly pared down access is going to feel quite restrictive and suffocating.

Some devs won't have the patience to wait for some other department to vet and import a new npm package, or the latest update to it, before it can be used.

Some devs will be frustrated not being able to run their favourite IDE which isn't on the approved list, or their favourite plugins which haven't been vetted yet.

Some devs will get annoyed that they have to reboot more and more frequently to get the latest OS updates because things like Copy-Fail/CVE-2026-31431 appear out of nowhere and can be weaponised by malware to break between accounts or out of VMs and other sandboxed envs to get access to more keys/PATs/etc.

Another alternative is endless MFA requests which leads to request fatigue and accidentally approving the malicious/unwanted action.

It's going to be interesting how the industry deals with all of this. I can see it getting a lot worse with some even more significant breaches before it starts to get better.