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"
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.
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.