Perhaps it's too obvious but ... just running the publish process locally, instead of from CI, would help. Especially if you publish from a dedicated user on a Mac where the system keychain is pretty secure.
In CI they could easily have moved `trivy` to its own dedicated worker that had no access to the PYPI secret, which should be isolated to the publish command and only the publish command.
Privilege escalation on macOS is very hard indeed. Apple have been improving security for a long time, it is far, far ahead of Linux or Windows in this regard. The default experience in Xcode is that a release-mode app you make will be sandboxed, undebuggable, have protected keychain entries other apps can't read, have a protected file space other apps can't read, and its own code will also be read-only to other apps. So apps can't interfere with each other or escalate to each other's privileges even when running as the same UNIX user. And that's the default, you don't have to do anything to get that level of protection.
App Store apps are the exception, which is great, but presumably we're not talking about that? If we are, then yeah, app stores solve these problems by making things actually sandboxed.
What I'm saying is that it's very easy now to take some arbitrary task - doing a compile/release cycle for example - and quickly knock up a simple signed macOS .app that sandboxes itself and then invokes the release script as a subprocess. Sandboxing is transitive and the .app itself can authenticate to the OS to obtain creds before passing them to the subprocess.
In the past I've thought about making a quick SaaS that does this for people so they don't have to fiddle with it locally and maybe some day I still will. But you can easily do it locally especially with Xcode and AI now. You wouldn't have to know anything about macOS development.