Snyk and GitHub Actions: How to Wire Up CI Scanning

To use Snyk with GitHub Actions, add one of Snyk's official actions from the snyk/actions repository to your workflow, store your Snyk API token as a repository secret, and let it scan dependencies on every push or pull request. The integration is well-documented and takes only a few lines of YAML, but the details that matter — which action to pick for your language, how to fail builds without blocking every merge, and how to surface results in GitHub's own security tab — are where teams get tripped up. This guide walks through a working setup and the decisions behind it, factually and without hand-waving.

The official actions and how they're organized

Snyk publishes a set of actions in the snyk/actions repository, and the key thing to understand is that there isn't one action — there's one per language or build tool. You pick the action matching your ecosystem:

• snyk/actions/node for npm and Yarn projects
• snyk/actions/python for pip and Poetry
• snyk/actions/maven and snyk/actions/gradle for the JVM
• snyk/actions/golang, snyk/actions/ruby, snyk/actions/dotnet, and others

There's also snyk/actions/setup, which just installs the Snyk CLI into your runner so you can call snyk directly. That's the more flexible option when you already configure your own toolchain and want full control over the CLI invocation. Note that as of August 2025, Snyk moved these actions to a closed-contribution model — development stays public for transparency, but the core team owns the roadmap.

A minimal working workflow

Here's a functional Node.js example that scans on every push and pull request:

name: Snyk Security
on:
  push:
    branches: [main]
  pull_request:

jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

The one thing you must get right is SNYK_TOKEN. This is your Snyk API token, and it must never be hardcoded — store it as a GitHub encrypted secret (repository or organization settings, Secrets and variables, Actions) and reference it through ${{ secrets.SNYK_TOKEN }}. A leaked Snyk token lets someone consume your scanning quota and read your project data, so treat it like any other credential.

By default the action runs snyk test, which fails the step — and therefore the build — when it finds vulnerabilities at or above the configured severity threshold. That default is often too aggressive for a repo with an existing backlog, which brings us to the next decision.

Controlling what fails the build

If you drop Snyk into a mature repository, the first run will likely fail on pre-existing issues and block every pull request until the backlog is cleared. That's a fast way to get the whole check disabled. Two levers manage this.

Set a severity threshold so only serious issues break the build:

      - uses: snyk/actions/node@master
        with:
          args: --severity-threshold=high
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

And decide whether the step should fail at all versus just report. If you want the scan to run and record results without blocking merges during a rollout period, add continue-on-error: true to the step. The pragmatic path is to start in report-only mode, drive the existing backlog down, then flip to failing on new high and critical issues once the noise is manageable.

Surfacing results in GitHub's Security tab

Raw action logs are easy to ignore. The better pattern is to output SARIF and upload it to GitHub code scanning, which puts findings in the repository's Security tab and annotates them inline on pull requests. Snyk's actions support a --sarif-file-output argument, and GitHub's codeql-action/upload-sarif step ingests it:

      - uses: snyk/actions/node@master
        continue-on-error: true
        with:
          args: --sarif-file-output=snyk.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      - name: Upload result to GitHub Code Scanning
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: snyk.sarif

Note the continue-on-error: true on the scan step here — you want the upload step to run even when the scan finds issues, otherwise a failing scan short-circuits the workflow before results reach the Security tab. Code scanning upload requires the security-events: write permission on the job, so add a permissions: block granting it.

Where GitHub Actions Snyk integration fits in a strategy

Wiring GitHub Actions Snyk scanning into CI covers one important slice: catching known-vulnerable open-source dependencies before they merge. It's worth being clear-eyed about the boundaries. This setup does software composition analysis on your dependency tree; it isn't a substitute for dynamic testing of your running app or for reviewing your own code's logic. Layer it alongside those, don't treat it as the whole program.

It's also fair to note this is a competitive space, and Snyk is one option among several. If you're evaluating alternatives, our Snyk comparison breaks down the differences feature by feature, and a tool such as Safeguard offers a similar GitHub Actions scanning model with its own approach to prioritizing findings by reachability. Whichever you choose, the CI integration pattern — scan on PR, threshold on severity, upload SARIF — is the same, and it's the part that actually reduces risk. For pricing considerations across options, verify each vendor's current plans directly, and see our pricing page for one reference point.

FAQ

Which Snyk GitHub action should I use?

Pick the action matching your language or build tool from the snyk/actions repository — for example snyk/actions/node for npm/Yarn or snyk/actions/maven for Maven. Use snyk/actions/setup instead when you want to install the Snyk CLI and call it directly with full control over the command.

How do I store my Snyk token securely in GitHub Actions?

Add it as an encrypted secret under the repository or organization's Actions secrets, then reference it as ${{ secrets.SNYK_TOKEN }} in the workflow's env. Never hardcode the token in YAML — a leaked token exposes your project data and scanning quota.

How do I stop Snyk from failing every pull request?

Set a --severity-threshold (such as high) so only serious issues break the build, and consider continue-on-error: true during an initial rollout so the scan reports without blocking merges. Clear the existing backlog first, then enforce failing on new high and critical issues.

How do I see Snyk results in GitHub's Security tab?

Run the scan with --sarif-file-output=snyk.sarif, keep continue-on-error: true on that step so a failing scan doesn't short-circuit the upload, then use github/codeql-action/upload-sarif to ingest the file. Grant the job security-events: write permission so code scanning can record the results.