Really cool to see all the hard work on Trusted Publishing and Sigstore pay off here. As a reminder, these tools were never meant to prevent attacks like this, only to make them easier to detect, harder to hide, and easier to recover from.
Good recommendations, including a neat tool to audit your GHAs: <a href="https://github.com/woodruffw/zizmor">https://github.com/woodruffw/zizmor</a> , “A static analysis tool for GitHub Actions”.
As a user of PyPI, what’s a best practice to protect against compromised libraries?<p>I fear that freezing the version number is inadequate because attackers (who don’t forget, control the dependency) could change the git tag and redeploy a commonly used version with different code.<p>Is it really viable to use hashes to lock the requirements.txt?
Anyone know of a tool like zizmor for GitLab CI/CD? Pretty confident my setup is unsafe after reading through this.<p>Honestly safety in CI/CD seems near impossible anyways.
So the Python package `ultralytics` had their GitHub CI/CD pipeline compromised which allowed an attack to be inserted and then published on PyPI?
Sadly, popular open source projects are vulnerable to this vector. A popular package that is adopted by a large vendor (Redhat/Microsoft) may see a PR from months or a year ago materialize in their product update pipeline. That is too easy to weaponize so that it doesn't manifest until needed or in a different environment.
> What can you do as a publisher to the Python Package Index?<p>Does PyPI rate publishers based on how well they comply to these rules? Can users see which publishers are more reliable than others?
I appreciate PyPI's transparency and the proactive measures to mitigate future risks. Are there plans to further educate developers on secure workflow practices to prevent similar incidents? This seems like a vital area for community collaboration and awareness.