ouch, this is a case where things like red october by cloudflare could be a great idea. Having to have a minimum number of signers to agree to sign a package would be a good way to prevent this.
Even simpler, have the releases performed by a human account. It can still be compromised but you're not going to be storing your own GitHub credentials on a server or inside a CI flow so it can automatically write on your behalf. You probably shouldn't be releasing so often that it's a pain in the ass to perform it manually (in terms of tagging in git rather than doing a full on deploy to a server or something).
It also means that maintainers are accountable for each release and if something like this happens, you know exactly who you need to talk to to get the situation resolved, which might be something as simple as setting a stronger password or not committing a GitHub token into their public dotfiles.
This approach is probably an overkill, but this project called Cothority[0] can be used to verify binaries by semi-independent authorities to be released. One of the applications referenced in their dotSecurity talk[1] was this usecase.
