Use Dependabot secrets instead of Actions secrets in Dependabot workflows

Code to Cloud GitHub Actions
#1

Currently, Actions that run off Dependabot PRs don’t have access to secrets, as they are treated like PRs from forks (c.f.: GitHub Actions: Workflows triggered by Dependabot PRs will run with read-only permissions | GitHub Changelog).

Dependabot users in Dependabot cant read secrets anymore · Issue #3253 · dependabot/dependabot-core · GitHub have a desire to allow Dependabot triggered workflows access to secrets, potentially swapping the Actions secrets for Dependabot secrets.

This has the same attack vector as the original issue, but the scope is Dependabot’s secrets (which are presumably not your AWS deploy keys) rather than Action’s secrets (which may well be).

2 Likes
Dependabot doesn't see GitHub actions secrets
#2

Secrets used to be available in workflow runs triggered by Dependabot and stopped working, thereby breaking many workflows where secrets are necessary.

They are certainly an attack vector but they are equally a necessary feature to have, as workflows using them will most likely not work if the secrets are not there.

I wonder how other CI systems like Travis and CircleCI have (always) handled this. I assume they expose the same attack vectors as GitHub Actions, maybe they have simply not been widely exploited yet?

I would generally consider Dependabot a trusted user because as a repository owner I must have explicitly enabled it, hence I am expecting it to create PRs and to be able to execute workflows. Clearly, somebody publishing a malicious dependency version could trigger the creation of a Dependabot PR which updates that dependency and that dependency, if executed during the workflow run, could steal the secrets. Yet, I’m not sure if the solution lies in making secrets inaccessible to such workflows, as the vulnerability lies in the malicious dependency version which could probably exploit in many other ways other than during a workflow run.