Dependency review action on main branch?

[JordanLongstaff]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Misc

Discussion Details

Is the dependency review action intended only for pull requests? It's technically runnable on the main/master branches too when PRs merge, but is there any benefit? It appears to be merely a reporting tool, leaving a comment in the PR that runs it, and that report is accessible for pushes to main/master too if you know where to look, but I'm not sure if anything is lost by disabling it on those branches.

[ZyFoxX]

Should Dependency Review Action run on PRs or on push to main?

Short answer: run it on pull_request. That’s where it prevents risky dependency changes from getting merged. Running it on push to main is optional and mostly useful for visibility when you allow direct pushes or want post-merge auditing.

TL;DR

• pull_request: Best for prevention and clear PR feedback (checks and UI).
• push to main: Optional, good for teams that allow direct pushes or want extra auditing after merge.
• If you only merge via PRs, you won’t lose much (if anything) by disabling it on main.

Why run on pull_request

• Catches vulnerable or disallowed dependency changes before they land.
• Presents actionable feedback directly in the PR (status checks, annotations, and the “Dependency review” UI).
• Lets you block merges if the check fails.

When to also run on push to main

• Your team allows direct pushes to the default branch.
• You want additional, post-merge visibility or auditing on dependency changes.
• You use other automations that bypass PR checks (not recommended, but sometimes happens).

---

Recommended Workflow Examples

1) PR-only (recommended for most teams)

Triggers only when dependency manifests/lockfiles change.

name: Dependency Review (PR)

on:
  pull_request:
    types: [opened, synchronize, reopened]
    paths:
      - '**/package-lock.json'
      - '**/pnpm-lock.yaml'
      - '**/yarn.lock'
      - '**/requirements.txt'
      - '**/Pipfile.lock'
      - '**/poetry.lock'
      - '**/Gemfile.lock'
      - '**/pom.xml'
      - '**/build.gradle'
      - '**/build.gradle.kts'
      - '**/go.sum'
      - '**/Cargo.lock'

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          # Fail the check when new vulns at or above this severity appear
          fail-on-severity: high

2) PR + push to default branch (for direct pushes / extra auditing)

Adds a second trigger for pushes to main. This won’t block changes already merged, but it surfaces issues on the main branch.

name: Dependency Review (PR + Main)

on:
  pull_request:
    types: [opened, synchronize, reopened]
    paths:
      - '**/package-lock.json'
      - '**/pnpm-lock.yaml'
      - '**/yarn.lock'
      - '**/requirements.txt'
      - '**/Pipfile.lock'
      - '**/poetry.lock'
      - '**/Gemfile.lock'
      - '**/pom.xml'
      - '**/build.gradle'
      - '**/build.gradle.kts'
      - '**/go.sum'
      - '**/Cargo.lock'
  push:
    branches: [main]
    paths:
      - '**/package-lock.json'
      - '**/pnpm-lock.yaml'
      - '**/yarn.lock'
      - '**/requirements.txt'
      - '**/Pipfile.lock'
      - '**/poetry.lock'
      - '**/Gemfile.lock'
      - '**/pom.xml'
      - '**/build.gradle'
      - '**/build.gradle.kts'
      - '**/go.sum'
      - '**/Cargo.lock'

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high

---

Practical tips

• Keep it fast by scoping to manifests/lockfiles with the paths filter.
• Use branch protection rules to require the “Dependency Review (PR)” check before merging.
• Avoid pull_request_target for this use case unless you know exactly why you need it—it has security trade-offs with forks.

Human summary

If your team merges everything through PRs, just run Dependency Review on pull_request and call it a day. If people sometimes push straight to main (or you want that extra belt-and-suspenders audit), add a push trigger for main too. The real value is in catching problems before merge—so PRs first, push-to-main only if you really need it.

References

• Dependency Review Action: https://github.com/actions/dependency-review-action
• About Dependency Review: https://docs.github.com/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review
• Using the Dependency Review Action: https://docs.github.com/code-security/supply-chain-security/recording-dependencies-during-build/using-the-dependency-review-action