4 ms·
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
by SethMLarson 3y ago
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! :)
- tlarkworthy 3y ago> Self-hosted infrastructure should be isolated and ephemeral, persistence was key for lateral movement with this attack. Half the point of self hosting is to reuse cached resources.
- SethMLarson 3y agoIsolation and ephemerality can still be accomplished using virtualization while providing the benefits of self-hosted resources.
- sroussey 3y agoI just wish python would isolate all the pip install stuff and put in the project folder like has been done with nodejs for years.
- bloopernova 3y agoPython's virtualenv does something similar by keeping all files under one directory.
- sroussey 3y agoYes, but it should be the default
- YetAnotherNick 3y ago> PRs should be reviewed before code executes on your infrastructure Very often local tests results can't be trusted specially for projects with architecture level codes like pytorch. Before merging the test results needs to be checked. And it doesn't require just PR review to be safe, it requires review of all the commits as the contributor is making the changes to fix the testcase. Even if we assume that the maintainer will review each of the commit within a day, it could take weeks or months for the contributor to fix the failing testcase with this and maintainer to be looking at the same PR everyday.