Disclaimer - I have read through all posts and linked issue FAQ and new docs to the best of my abilities
Our team is also currently in the process of investigation of optimal workflows for dependabot to access secrets, and honestly so far neither solutions seem to be appealing either from security perspective (because they restore attack vector which github tried to protect against) or from perspective of having worse DX.
The conclusion that I have come up with, is that there’s a problem with isolation when it comes to secrets and the way of what dependabot (or any other untrusted but automated actor) can access.
All the solutions proposed are either:
- removing access to secrets completely - good default
- assume the eventual presence of a trusted party and then give away access to entire secrets object - does not seem to be safe in light of our new knowledge
While I think that dependabot should not by default read repository secrets, I still need to store them in the repo for workflows other than dependabot. Hence things like pull_request_target or workflow_run while providing a “fix”, still leave attacker with a possibility to capture secrets, although not automated. The main reason for this - is that even if we introduce human interaction in between the process, it’s unlikely that humans are capable (or willing) of going through dependency chain and verifying that patches are actually legit. To build automations for humans we need secrets…
Github Actions have actually a good (but incomplete) candidate to manage this problem - environments.
https://docs.github.com/en/actions/reference/environments
We could create a special “Dependabot” environment where we add a set of secrets, which are accessible to dependabot. While setting up humans can make sure that those tokens are as minimal and downscoped as possible, thus even if because of human error somebody does toJson(secrets), damage will be at least manageable and contained. In combination with some automated monitoring on Github’s side, it would be possible to “invalidate” entire environment in case of a known widespread breach.
The problem with current implementation of environments, that environment secrets are superset of global secrets, thus some extra configuration checkbox is needed to be able to isolate environment from everywhere else. Or Github could create a standard dependabot environment which is later user-configurable and make it a default during an initial provisioning of dependabot.yml, which is also completely isolated from repo secrets (and potentially could allow selective cherry picking “safe” secrets from global pool).
I am aware of “Dependabot Secrets” on org level, but in my opinion it’s an ortogonal solution to repo-level secrets in actions, and it should not be recycled for repo-level access
In our fairly simple case we would like to perform yarn install on repository with a Github PAT to access private package registry. No other secrets are required (but many more are actually in the repo). Having isolated environment would allow us to somewhat safely use triggers like pull_request_target, have a required approval to secrets (built-in feature into environments) and even potential enable again access to secrets from pull_request and other downscoped triggers.
Not sure if you considered this @asciimike, but would be interesting to hear your thoughts.
