Re:We Executed a Critical Supply Chain Attack on PyTorch
by snnn on Sunday January 14, 2024 @11:28PM
(#38997460)
Let me summarize it a little bit:
1. Their GITHUB_TOKEN has write permissions, while it doesn't have to.
2. They have a pull request pipeline that can be auto-triggered without being reviewed by the PyTorch team first.
3. Their build machines are not stateless.
So here are my suggestions:
1. Set your GITHUB_TOKEN to readonly. If you have a workflow that can approves PR without human interaction, people who get the token can do the same. And they even can do a release for you, then deploy the new version to thousands of your customers.
2. If you can consider using Azure DevOps pipelines, last year they released a key feature that add a centralized control for building PRs from forked GitHub repos. Which means you can enforce every external PR must be reviewed before building. You can enforce the rule at an org level. If your are the VP of engineering, you can let it take effect immediately for all the pipelines your company owns.
3. Azure DevOps has a nice feature that it allow using Azure Virtual Machine Scale Sets to running self hosted agents(runners), which mean you can have fine control on the machine's lifecycle. For example, you can let it automatically tear down virtual machines after every use, and setup auto-provisioning rules to avoid waiting too long for a new agent being ready.
4. If you use Azure DevOps pipelines, you can put your pull request pipelines and packaging pipelines in to different orgs, so that access tokens used by the pull request pipelines wouldn't have any access to your release and release artifacts.
5. Securing Supply Chain is far more than what are mentioned above. I bet Meta's security engineers know more than me and they can give better advice(I am not a security engineer) . But people need to listen to them. We all need to invest more on this topic.
I am not advocating Azure DevOps. I was just using it as an example to show what kind of security measures could be helpful.
1. Their GITHUB_TOKEN has write permissions, while it doesn't have to.
2. They have a pull request pipeline that can be auto-triggered without being reviewed by the PyTorch team first.
3. Their build machines are not stateless.
So here are my suggestions:
1. Set your GITHUB_TOKEN to readonly. If you have a workflow that can approves PR without human interaction, people who get the token can do the same. And they even can do a release for you, then deploy the new version to thousands of your customers.
2. If you can consider using Azure DevOps pipelines, last year they released a key feature that add a centralized control for building PRs from forked GitHub repos. Which means you can enforce every external PR must be reviewed before building. You can enforce the rule at an org level. If your are the VP of engineering, you can let it take effect immediately for all the pipelines your company owns.
3. Azure DevOps has a nice feature that it allow using Azure Virtual Machine Scale Sets to running self hosted agents(runners), which mean you can have fine control on the machine's lifecycle. For example, you can let it automatically tear down virtual machines after every use, and setup auto-provisioning rules to avoid waiting too long for a new agent being ready.
4. If you use Azure DevOps pipelines, you can put your pull request pipelines and packaging pipelines in to different orgs, so that access tokens used by the pull request pipelines wouldn't have any access to your release and release artifacts.
5. Securing Supply Chain is far more than what are mentioned above. I bet Meta's security engineers know more than me and they can give better advice(I am not a security engineer) . But people need to listen to them. We all need to invest more on this topic.
I am not advocating Azure DevOps. I was just using it as an example to show what kind of security measures could be helpful.