Great write-up! There's a few things you can do as either a producer or consumer to thwart this sort of attack:

Producers:

* Self-hosted infrastructure should not be running anonymous code. PRs should be reviewed before code executes on your infrastructure. Potentially should be a GitHub default when using self-hosted runners?

* Permissions for workflows and tokens should be minimal and fine-grained. "permissions: read-all" should be your default when creating a new workflow. Prevents lateral movement via modifying workflow code.

* Self-hosted infrastructure should be isolated and ephemeral, persistence was key for lateral movement with this attack.

Consumers:

* Use a lock file with pinned hashes, either --require-hashes or poetry/pipfile

* Review the diff of the file getting installed, not the GitHub source code. This will get easier when build provenance becomes a feature of PyPI.

* If your organization is large enough, consider mirroring PyPI with approved releases so the manual review effort can be amortized.

* More coming in this space for Python, like third-party attestations about malware, provenance, build reproducibility, etc. Stay tuned! :)