For things pushed to github, github has quite sophisticated secret scanning. They have a huge list of providers where they will automatically verify if a potential key is real and revoke it automatically [2], and a smaller list of generic patters they try to match if you enable the matching of "non-provider patterns".
This seems to be a case of someone accidentally publishing their github token somewhere else. I'm not sure how github would cheaply and easily prevent that. Though there are third party tools that scan your web presence for secrets, including trying wordlists of common files or directories
GitHub wants to sell a service. Keys are convenient. Better alternatives in authorization and authentication exist, and GitHub is very aware of them. They even offer and facilitate them. For example, see OIDC. But many users either want keys because they're used to them or GitHub is sure they do, so they continue to offer them to avoid friction. The alternatives require more parameters, thought, and coordination between services.
GitHub has deprecated classic tokens, but the new tokens are not backwards compatible. The deprecated tokens have also continued to be available for some time. Real security professionals will tell you flatly "tokens are bad", and they're right. They're leakable attack vectors. The tokens are the problem and discontinuation is the solution. Scanning is simply symptom treating, and given what I know about Microsoft culture, I doubt that's going to change soon or quickly.
This seems to be a case of someone accidentally publishing their github token somewhere else. I'm not sure how github would cheaply and easily prevent that. Though there are third party tools that scan your web presence for secrets, including trying wordlists of common files or directories
1: https://docs.github.com/en/code-security/secret-scanning/int...
2: https://docs.github.com/en/code-security/secret-scanning/int...