Dependabot doesn't see GitHub actions secrets

I agree.
So is there way to tell that dependabot is able to read secrets?

That’s only available per organization level, which exposes a huge security risk compared to what one would like to achieve - give access to secrets only for dependabot. Maybe there could either be settings per repo or a list of users to whitelist.

2 Likes

I know that this is a potential security risk and not a great solution, but I think for an organization with only private repositories it’s a “good-enough” workaround until there is a better solution.

This needs to be fixed.
Currently there are no secure way to have Dependabot access secrets in workflows.
Why aren’t the Dependabot secrets active in pull requests?

2 Likes

I have exactly same problem. I have a public repo with 2 access token stored as secrets. My dependabot pull requests started failing and I have to kick them off manually every time (which is far from perfect).

I setup my secrets (basically copied them) as per the official documentation: Managing encrypted secrets for Dependabot - GitHub Docs but dependabot still cannot read it.

Or… perhaps this option is not available to public repos or free accounts?

I actually switched from Travis 2 weeks ago and I’m thinking about switching back… My CI/CD is broken.

2 Likes

For my organization, the secret we’re having trouble with is Codecov on a private repository that we don’t allow forks of anyway, so I’m planning to include the Codecov token in the workflow yaml file instead of using a secret. This is not ideal, but because we do have public open source repositories in this organization that upload to PyPI, enabling that setting isn’t wise.

If this were not an option, it seems that splitting up our organization into two, one for public and one for private repos, would be the next best option. I really hate to multiply organizations for that purpose, though.

2 Likes

I too have this problem and I think it surfaced after going from legacy Dependabot to the GitHub native one (after merging its .github/dependabot.yml pull request).

I had secrets.GPR_TOKEN defined and working for my own pull requests, but Dependabot’s pull requests kept failing. After adding the secret under the Dependabot section in GitHub, some of Dependabot’s pull requests suddenly started working again, but not all.

While one is successful, another one fails. I’m unable to explain the discrepancy. If adding secrets used in a workflow as a “Dependabot secret” is supposed to work, it seems to be an undocumented, obscure and fragile feature. I at least can’t find any mention of it in the documentation.

4 Likes

Same issue on paid private account. PRs created by Dependabot cannot read secrets.

Fork pull request workflows section in Settings > Actions is greyed out and unable to amend that.

Added secrets in Repo Settings > Secrets > Dependabot

Bit stuck!

1 Like

Link: Dependabot cannot update this dependency (Private Registry) - #11 by david-guillot

This should be fixed…

Same issue here. Looks like there isn’t currently any way for dependabot to use secrets outside of opening up an organisation-wide security hole. This needs to be fixed

This post below might solve your problem:
Solution

And here further explanation: why?

The root of the problem seems to be that Dependabot does not have access to secrets as an external contributor to your repo. They are sort of treated like PR from forks. So you’ll have to approve the dependabot PR and re-run it so it can read secrets. I think the problem is that dependabot PRs, despite being like forked PRs, don’t wait to run workflows until an approval is provided by someone with repo write access. If GH could prevent running workflows in dependabot PRs automatically and wait for a comment trigger to start the workflow, that should solve this problem.

As a potential short-term “fix”, you could add also add a pull_request_review trigger to your workflow file in addition to pull_request, which would re-run the PR workflow as soon as you approve the PR. Without this, you’d have to manually re-run the failed run. Note that this still doesn’t prevent the workflow from running the first time as soon Dependabot creates the PR.

EDIT: The down-side to my suggestion is that it sucks when you have a successful PR and the pull_request_review will re-run it. So perhaps manually re-running a failed workflow after you’ve approved it is better.

1 Like

As @simoneb also pointed out, you should seriously consider the consequences of allowing PRs from forks to read repo secrets.

After more digging it seems like the pull_request_target event allows secrets to be shared with Dependabot. However, you need to instruct actions/checkout to checkout the correct SHA. The following blog post outlines how to do this by duplicating the actions/checkout step with if statements that take the github.actor and github.event_name into account:

2 Likes

We have this exact problem at Particular Software. In order to run tests, many of our components must create infrastructure like an Azure Service Bus namespace, or else spin up a service in Azure Container Instances.

This is our solution to the problem, you can see an example in the CI Workflow for our Azure Service Bus transport.

Notice how we are using both the pull_request event for internal contributors and the pull_request_target for Dependabot. We have a giant if statement that only runs one or the other, and pull_request_target only for Dependabot.

Then the very first step is we check for secrets so that we can exit early if this is going to be a giant waste of time.

After that we have 2 checkout steps. One for pull_request that allows the Checkout action to just do its thing. The other is for pull_request_target and gives a specific ref for the pull request, because otherwise what you’ll check out is the PR base branch.

We don’t know if this is the best approach. Likely it isn’t! Comments are welcome! We definitely do not have a solution for Fork PRs right now, but we really didn’t on TeamCity either. We’re hoping GitHub makes some improvements in this area.

Have you tried using the Dependabot section under secrets?

image

I believe this will allow you to define secrets that are visible to Dependabot.

That only allows Dependabot to check if updates for private packages area available. It has nothing to do with the secrets in GitHub Action Workflows.

1 Like

Aren’t these secrets available when a workflow run is triggered by Dependabot?

No, they’re not. Those secrets are available to Dependabot itself so that it can access an authenticated MyGet repository, for example. They’re not available to actions.

As proof, I created this workflow:

  
name: Test for Dependabot Secrets
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Check for Actions secrets
        env:
          ACTIONS_SECRETS: ${{ secrets.ACTIONS_SECRETS }}
          DEPENDABOT_SECRETS: ${{ secrets.DEPENDABOT_SECRETS }}
        shell: pwsh
        run: |
          $test1 = $(If ($env:ACTIONS_SECRETS -eq 'true') { 1 } Else { 0 })
          $test2 = $(If ($env:DEPENDABOT_SECRETS -eq 'true') { 1 } Else { 0 })
          
          echo "Actions Secrets = $test1"
          echo "Dependabot Secrets = $test2"

In both the Actions / Dependabot secrets settings, I set up the secrets named above with the value true, and this was the output:

1 Like

Here are the public docs as well as a FAQ for information related to this change.

For those of you asking if Dependabot secrets are available, it’s discussed in the above document (they aren’t), and links to a feature request on this board where you can ask the Actions to consider that functionality (here).