Dependabot and internal repos

[tyson-benson]

Would be nice if it were more obvious how to setup Dependabot to work with internal repo's that have workflows that access secrets, while there seems to be documentation around this (pull_request_target), I haven't seen a clear example of a workflow that demonstrates how this should be done.

Dependabot happily creates PRs, but the workflows fail because they cannot access the secrets they depend on. My workaround is to manually replicate the changes dependabot suggests and submit my own pull request, feels like there's gotta be a better way.

The documentation about pull_request_target suggests there are security implications for using this trigger, but given it isn't a public repo, is this even a concern? If not, it would be good if the documentation reflected this as context is important.

[Fryie]

Hi @tyson-benson ,

I agree the current state is not very satisfactory, as it requires some work setting this up correctly. Here's an example which should work:

name: My Workflow

on:
  pull_request:
  # for dependabot, see: https://github.com/dependabot/dependabot-core/issues/3253#issuecomment-841656411
  pull_request_target:

jobs:
  test:
    if: |
      (github.event_name == 'pull_request' && github.actor != 'dependabot[bot]') ||
      (github.event_name == 'pull_request_target' && github.actor == 'dependabot[bot]')
    name: Run Tests
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v2
        with:
          ref: ${{ github.event.pull_request.head.sha }}
   
      ...

Couple of things to note:

• You want pull_request_target for dependabot, because that flow allows access to secrets
• However, pull_request_target executes in the context of the target branch (e.g. main), so you need to manually specify the ref in your checkout action. Don't forget this or your PRs will succeed even if the code is broken because it doesn't run on the changes.
• It's best to only allow this for dependabot (hence the if), see below.

As for the security implications:

• If your repo is private and PRs from external sources are not otherwise allowed, there is no security issue that I can see
• Otherwise, the argument is that an external person might submit a PR that uses the workflow to e.g. send the values of the secrets to a place controlled by the attacker. If the workflow runs automatically, this could happen before you even see that PR.
• Even so, when the actor is dependabot, we can assume it's benign, so what we're doing in the above example is explicitly whitelisting dependabot.