Snyk GitHub Integration: Scan Repos and Block PRs (2026)

The Snyk GitHub integration isn’t just about finding vulnerabilities; it’s a gatekeeper that can prevent insecure code from ever reaching your main branch.

Let’s see it in action. Imagine a developer pushes a new commit to a feature branch that introduces a dependency with a known critical vulnerability.

# .github/workflows/snyk.yml
name: Snyk Security Scan

on:
  pull_request:
    types: [opened, synchronize, reopened]
  push:
    branches:
      - main # Or your default branch

jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Initialize Snyk
        uses: snyk/actions/node@master
        id: snyk
        env:

          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Run Snyk test
        run: snyk test --fail-on=high

When this workflow runs on a pull request, Snyk analyzes the package-lock.json (or equivalent for other languages). If it finds a vulnerability that meets the criteria (in this case, high severity or higher), the snyk test --fail-on=high command will exit with a non-zero status code.

GitHub Actions, by default, interprets a non-zero exit code in any step as a job failure. This failure causes the GitHub Actions run to stop. If this is happening on a pull request, the PR will show a failed status check.

Here’s the crucial part: you can configure your repository’s branch protection rules to require that all status checks pass before a pull request can be merged. This is how Snyk effectively blocks PRs. The developer sees the red X on their PR, Snyk has flagged the vulnerability, and until that vulnerability is addressed and the code is re-scanned successfully, the PR cannot be merged into main.

The problem this solves is shifting security left. Instead of discovering vulnerabilities in production or during a late-stage security review, you’re catching them at the earliest possible point in the development lifecycle: when code is being proposed for integration.

Internally, Snyk’s GitHub Action leverages the Snyk CLI. When you use uses: snyk/actions/node@master, it’s essentially downloading and running the Snyk CLI configured for your specific environment (Node.js in this example). The SNYK_TOKEN authenticates your GitHub Action to your Snyk account, allowing it to access Snyk’s vulnerability database and report findings back to your Snyk project.

The snyk test command is the workhorse. It analyzes your project’s dependencies (and in other configurations, your IaC or code itself) against Snyk’s vast, continuously updated vulnerability database. The --fail-on=high flag is a policy enforcement mechanism. You can adjust this to --fail-on=critical, --fail-on=medium, or even --fail-on=all depending on your team’s risk tolerance. For IaC or code scanning, you’d use snyk iac test or snyk code test respectively, with similar --fail-on options.

The exact levers you control are:

• The Snyk Token: This is your API key, managed as a GitHub secret, linking the action to your Snyk project.
• The Scan Type: snyk test for open-source dependencies, snyk iac test for Infrastructure as Code (Terraform, CloudFormation, etc.), snyk code test for custom application code. You can add multiple steps for different scan types.
• The Failure Threshold: --fail-on=high (or critical, medium, etc.) dictates the severity level that will cause the action to fail.
• The Target Branch(es): The on: push: branches: directive ensures scans also run on merges to your main branch for a final safety net.
• Branch Protection Rules: In your GitHub repository settings, under "Branches," you configure which status checks are required for merging. You’ll add the "Snyk Security Scan" (or whatever you name your workflow) to this list.

One thing most people don’t realize is that Snyk’s GitHub Action can be configured to automatically open issues in your GitHub repository for vulnerabilities that don’t block a PR (e.g., if you set --fail-on=critical but want to track high vulnerabilities as issues). This is achieved by adding snyk monitor to your workflow. snyk monitor continuously monitors your project for new vulnerabilities and can report them to Snyk and optionally create GitHub issues.

The next step is often integrating Snyk into your CI/CD pipeline after the PR is merged, to catch any new vulnerabilities introduced by post-merge deployments or unexpected changes.