Dependabot pull requests fail on repositories with maven-dependency-submission action

[thomasturrell]

When creating a new workflow using the suggested "Java with Maven" it includes the maven dependancy submission action.

For example:

name: Java CI with Maven

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: maven
    - name: Build with Maven
      run: mvn -B package --file pom.xml

    # Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive
    - name: Update dependency graph
      uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6

However if dependabot is enabled for the repository then when dependabot opens a pull request the action fails with the following error:

HTTP Status 403 for request POST https://api.github.com/repos/x/y/dependency-graph/snapshots

I am not sure if this is a bug or a configuration issue. Any advice gratefully received.

[cmergenthaler]

Dependabot PRs are handled like PRs from forked repositories. Therefore the workflow's GITHUB_TOKEN only gets read permission. You can try to assign write permission for the workflow:

# The API requires write permission on the repository to submit dependencies
permissions:
  contents: write

[mr-c]

Thank you @cmergenthaler ; that solved the problem for me. Your tip should be added to the README of this repo

https://github.com/common-workflow-language/cwljava/actions/runs/4251012827/jobs/7392826690#step:6:497

https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api

[ecki]

permissions:
contents: write

BTW: I dont think giving write permission is something you should document. In fact I think the template should instead contain a conditional to not run the actvitiy on PRs (or not run it if it has no token permission) or run it but not fail the post.

[felickz]

If you intend to not run this snapshot submission on Dependabot PRs ( to avoid granting write permissions when pulling in new potentially untrusted dependency versions ) - this is the prescribed methodology:

if: github.actor != 'dependabot[bot]'

Feedback for this repo: https://github.com/actions/starter-workflows/blob/main/ci/maven.yml

[ecki]

The github.actor is interesting, but is this the right condition? After all non-dependabot pull requests would pass, and those are the ones i dont want to have a write token.

But I agree, A example condition really should be inside the template because it really encourages insecure practice. The number of places people recommend to use write tokens is insane.

I am currently using:

 if: ${{ github.ref == 'refs/heads/main' && github.event_name == 'push' && vars.DISABLE_MAVEN_DEPENDENCY_SUBMISSION != 'true' }}

This way I can also turn it off, when it is broken again :)

[felickz]

After all non-dependabot pull requests would pass, and those are the ones i dont want to have a write token.

Sure, you are absolutely right to have concern about what a 3rd party/dependency may have the ability to do with a write token! It is unfortunate that this api is guarded by writing contents instead of a fine-grained permission unto itself. This issue OP created was around dependabot failing so that is what my response was targeted at - as needed, you could implement any logic to guard this or continue on failure.

I am currently using:

if: ${{ github.ref == 'refs/heads/main' && github.event_name == 'push' && vars.DISABLE_MAVEN_DEPENDENCY_SUBMISSION != 'true' }}

Note that if you use the actions/dependency-review-action to scan on PR - this can now diff against submitted snapshot dependencies. To do that you must also commit the snapshot against the PR HEAD commit (via retry-on-snapshot-warnings) and therefore the logic you show would not work against this. As such, I would hesitate to recommend it in the starter workflow.

This is a starter template so there is limited depth in those - agreed on they should be using secure practices 💟.

I have proposed to split the suggested starter workflow into distinct jobs for maven build vs submit dependency graph snapshot to enforce a least privilege model here (dependabot being one of the scenarios where this fails): actions/starter-workflows#2338

[ecki]

The action could also just skip itself if it has no write token. Instead of failing just log a warning. Then it needs no further if.

or, can you check in a „if“ the token role, then you could put that in the starter template as a skip condition. The starter template must not be ready for all eventualities, but at least it should not fail by default when the user enables recommended bots. (Having said that, your suggested if is only half bad :)