Opt-in to allow secrets on Dependabot workflows

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 opt-in to allow Dependabot triggered workflows access to secrets.

As an example:

name: Dependabot Workflow
on:
  pull_request

jobs:
  do-stuff:
    runs-on: ubuntu-latest
    **can-access-secrets: true**
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - uses: ...

Or:

name: Dependabot Workflow
on:
  pull_request

jobs:
  do-stuff:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - uses: ...
         with: 
           some-secret-value: ${{allow_insecure_secret_access.MY_SECRET}}
17 Likes

I have a scenario that makes me wish this were an option. If someone has a potential for how to solve this nicely, I’m all ears.

Our products leverage a private repo to pull internal artifacts. Because of this, accessing secrets (to authenticate against the private repo) is a requirement just to be able to build the service. This can’t be solved by using separate privileged/non-privileged workflows.

We also use CodeQL to scan the source and report any issues. As the source is Java, it must be built in order to be scanned. A passing CodeQL check is required in order to merge to main.

We discovered that running CodeQL against the pull_request_target event breaks CodeQL as it thinks it’s scanning code against the target branch (main) instead of the PR branch. So results are not annotated in the PR itself. Instead, the results show up in the code scanning results of the repo against “main”. This is definitely not ideal, but I suspect it’s “by design” when using pull_request_target.

However, if I use pull_request, I can’t build the product. Now, in this case, I wouldn’t expect CodeQL results to change simply because of an updated dependency. So bypassing or rubberstamping it is an acceptable outcome. But GitHub Actions doesn’t give me a way to either:

  1. Make a check required only if it’s determined that it needs to run, or
  2. Terminate a check early without failing

So as far as I can tell, I’m stuck choosing between less than ideal outcomes:

  1. Don’t make the CodeQL check required.
  2. Let the dependabot PRs fail. A user can manually re-run the CodeQL check to get a green checkmark or an admin can simply override and merge anyways.
  3. Update the CodeQL check job to skip every step on dependabot PRs so that it passes.

I’d love to hear options 4+ that others might have to solve this issue.

One idea is: in the same action, create a job that checks if dependabot is running the action (e.g. “check-dependabot”). Then create a second job that performs the codeql (“needs: check-dependabot” and if the user is not dependabot) – so it will be skipped if the user is dependabot. Last, create a third job (“verify-codeql”) that “needs” both jobs but uses “if: always()” so that it runs even if the codeql check fails or is skipped. In that job, you can fail if the codeql job fails or if the user is not dependabot. Then, you can make that last job (verify-codeql) required for the branch.

Personally, I would use an output value in the first job set to whether the user is dependabot (so the logic is in one place) and then use that value in the other jobs.

Thanks for the suggestion. I’ve used this approach in the past to solve a similar problem. However, it won’t work here in this case. The second job would use the codeql-action/analyze action to perform the actual analysis. The results of this action are reported back to GitHub asynchronously using a job-id / check that matches that of the job that executed the action. This check is the one that needs to be required since it’s pass/failure status takes into consideration the repo’s check failure configuration for code scanning.

In other words, the result of the 3rd job in your proposal would only determine if the scan was executed successfully (or skipped) rather than the results of the actual scan.

Ah, very true. Oh, well. We have the same issue with a SonarQube scan. That being said, in the recent release Sonar created an action that is supposed to provide the status of the scan so that it can be checked in code, though I have not tried it yet. I wonder if Github will do the same for CodeQL.

2 Likes

I agree with this feature request!

As a company with private repositories and disallowed forking I just want to have an option to let dependabot read all secrets in all workflows.

I don’t want to complicate our workflows by having 1 unprivileged and 1 privileged one.

Seems to me that this particular case wouldn’t be affected by any potential security vulnerabilities.

3 Likes

This is very annoying issue. Almost all dependabot pr’s in our private repos are failing to pass checks, cause we need to pull packages/images from private repos to build application and we can’t do it without secrets.

@asciimike Here but also there: Dependabot triggered Actions cant access secrets or use a writable token · Issue #3253 · dependabot/dependabot-core · GitHub, it seems to me that you’re describing possible solutions to give Dependabot access to secrets based on Github Actions YAML job descriptions but that’s not how we configure Dependabot. We’re using the .github/dependabot.yaml configuration file, which means that, AFAIK, none of the solutions you suggest is working for us.

Would it be possible to configure the secrets we give Dependabot access to in this .github/dependabot.yaml file?

Something like:

  - package-ecosystem: "gradle"
    directory: "/"
    schedule:
      interval: "daily"
    commit-message:
      prefix: "[update]"
    labels:
      - "dependencies"
    secrets:
      - GITHUB_TOKEN
      - OTHER_SECRET
      - ETC.

These secrets coming from the “normal” secrets, not the Dependabot ones.

This issue is, as others suggest in this thread, really annoying. We have other things to do than spending hours trying to understand how to configure this bot.

2 Likes