My team and I work on Actions at GitHub and I just wanted to stop by and add a bit more context. We definitely understand the concerns the article brings up and it's actually why we recommend in our documentation using SHA references when consuming third-party Actions. We also introduced the concept of verified Actions that extend an Organization's verification to Actions in the marketplace. We know there's more to do here to help prevent any malicious Actions and we're planning to continue to iterate. Thanks so much for the feedback and keep it coming.
I’m excited about Actions generally, so I’m glad to hear your team is aware of the challenges of building a reliable ecosystem of third party dependencies by reference to repos.
Still, recommending git SHAs has real ergonomic and maintainability issues, and while it’s more defensive it doesn’t prevent left-pad style broken builds due to disappearing content.
And at the same time, GitHub is investing heavily in package management infrastructure. I don’t say this lightly because designing good dependency management systems is much more subtle and difficult than people typically recognize, but from where I sit this appears to be fundamentally a dependency management concern. It seems a shame not to try to put GitHub Package Registry to good work here. Is that something potentially on the horizon?
This is an excellent point, and should solve the issue I put below about builds taking forever when pulling in a slow-building action.
If I'm using a marketplace action in my workflow, I want "foo/action@v1.0.0" to be treated like a binary package dependency, not a build from sourcecode.
In addition to the security aspect, it would be really great if you have the option to lock down or cache the Docker images used for actions. It was weird for me when I pulled in an action from the marketplace for a workflow, and now about 80% of my total build time is building of that action for each and every build I run (e.g. the Dockerfile is compiled for that action EVERY time I run my build). I should have the option to at least cache that built image for me after the first time I run a workflow.
It sounds like you should add an abstraction layer that makes the default depending on the SHA. Your product should be secure by default and it clearly is not right now.
Likely, you can still do this and migrate people fairly painlessly to a secure version.
Edit: even if you select a tag or something, it should use the underlying reference instead of the tag. You can add an escape hatch if you REALLY want to target the tag (there are obviously workflows where that makes sense), but it should be off by default and warm users of the security risks.
Hey there, I’m the Director of Engineering at GitHub with the team working on Actions. We really wanted to get an extremely flexible and powerful SDLC automation platform into our users hands as fast as possible. To do that we borrowed some code and infra from Pipelines to be able to offer a rock-solid CI/CD to every developer on GitHub sooner, and to be able to scale out to 40 million developers. With hosted runners, you’ll be able to run your Actions builds in any cloud, or even on your own hardware; if you don’t want to set that up, builds run on VMs and containers in Azure by default. You can use Actions to deploy anywhere and we have AWS, Azure, and Google Cloud actions to enable you to get started right away. If you want to read up a bit more about our virtual environments as well as what powers our runners check, we have some of that info in our docs here: https://help.github.com/en/articles/virtual-environments-for....
I feel like everyone who uses MS these days and still doesn't carry over distrust cultivated in the 90s knows that the problem isn't going to be lock in. But I'm sure MS's end game is to make you want to use Azure more, which is fair game.
