Snyk

Snyk (pronounced "sneak," from "so now you know") is a commercial application-security platform built around one pitch: a scanner shouldn't just tell you what's broken, it should hand you the fix. Where a classic SCA tool matches your dependency tree against a vulnerability database and prints a report, Snyk's test command does the same match but then goes a step further — it computes the smallest version bump that clears the vulnerability without breaking your semver range, and its GitHub/GitLab/Bitbucket integration can open that bump as a pull request on its own. That single design choice — findings plus a computed remediation, not findings alone — is Snyk's whole developer-first argument, and it's the thread this page follows through its architecture, its free tier, and its overlap with the two open-source tools most teams compare it against: Trivy and OWASP Dependency-Check.

What Snyk is, and the problem it solves

☺ Like you're 10: It's a scanner that also does the annoying part — figuring out which new version to use and asking git to make the change for you.

Snyk Ltd. (London and Tel Aviv, founded 2015) ships a family of products under one CLI and one web platform: Snyk Open Source (software composition analysis — vulnerable dependencies), Snyk Container (OS-package and application-layer vulnerabilities inside an image), Snyk IaC (misconfigurations in Terraform, CloudFormation, Kubernetes manifests, and ARM templates), and Snyk Code (a SAST engine, built on technology from Snyk's 2020 acquisition of DeepCode). This page is scoped to the three that overlap most directly with SAST, DAST & SCA's software composition analysis category — Open Source, Container, and IaC — since Snyk Code is a separate product with a separate engine and belongs alongside Semgrep, SonarQube, and CodeQL instead.

The problem Snyk targets isn't detection — matching a package.json or a base image against a CVE feed is a solved problem, and OWASP Dependency-Check and Trivy both do it for free. The problem is what happens after detection: a report lands in a channel nobody reads, or a Jira ticket sits in a backlog because figuring out whether lodash@4.17.15 → 4.17.21 is safe to take means checking a changelog, checking whether anything else in the tree pins an incompatible range, and then actually doing the bump — work that's small in isolation and enormous multiplied across hundreds of dependencies across dozens of services. Snyk's bet is that a huge share of that remediation work is mechanical enough to automate, and that automating it is worth more to a busy team than a marginally better detection rate.

Architecture: a CLI that phones home, not a fully local scanner

☺ Like you're 10: Your computer figures out the shopping list, but the checking against "which of these are recalled" happens on Snyk's servers, not on your laptop.

This is the single biggest architectural difference from Trivy and OWASP Dependency-Check, and it's worth being precise about it because it drives almost every gotcha later on this page. Snyk's CLI does not ship an offline vulnerability database you download once and match against locally. For Snyk Open Source and Snyk Container, the CLI resolves your project's dependency graph (or unpacks an image's layers) entirely on your machine, then sends that graph — package names, versions, and the resolved tree structure, not your source code — to Snyk's cloud API, which matches it against the Snyk Intel Vulnerability Database and returns prioritized results. Snyk Code is a further step in that direction: it uploads your actual source for its semantic analysis engine to run against, which is why some organizations restrict Snyk Code to an on-prem broker deployment or skip it entirely while running Open Source and Container freely.

Contrast that with Trivy and OWASP Dependency-Check: both download a vulnerability feed once (trivy image --download-db-only, or Dependency-Check's NVD data mirror) and then match entirely offline, with no account, no login, and no data leaving the machine. That's a real trade, not a strict downside for either side — Snyk's cloud round-trip is what lets its database stay curated and enriched (exploit maturity, reachability signals on some plans, a "fix available" flag) in a way a periodically-synced open feed can't easily match, but it also means Snyk requires network access and an account to function at all, which matters for air-gapped environments and for organizations uncomfortable sending their dependency graph to a third party even when no source code is involved.

The developer-first pitch: fix suggestions and auto-PRs, not just findings

☺ Like you're 10: Instead of leaving you a note that says "this is broken," it leaves a note that says "this is broken, and here's the fixed version already written for you to approve."

Three mechanisms carry this pitch, and they layer on top of each other:

• Direct upgrade. When the vulnerable package is a direct dependency and a newer, non-vulnerable version exists within (or reachable by relaxing) your declared semver range, Snyk computes the minimum version bump that clears the vulnerability and proposes exactly that — not "jump to latest," which risks unrelated breaking changes.
• Transitive remediation. When the vulnerable package is buried several levels deep — something your own package.json never mentions by name — a plain version bump at the top level often can't reach it. Snyk computes a remediation path and, where the ecosystem supports it, writes a lockfile-level override (an overrides entry for npm, a resolutions entry for Yarn) that pins the nested package directly, without waiting for every intermediate maintainer to release a new version.
• Fix PRs, opened automatically. With the GitHub, GitLab, Bitbucket, or Azure Repos app integration installed on a repository (a separate connection from the CLI — this is the platform watching a repo continuously, not something snyk test triggers), Snyk opens a pull request carrying the computed remediation, titled and described with the CVE, the severity, and the fix rationale. Repositories accumulate these automatically as new vulnerabilities are disclosed, on a schedule independent of your own commits.

The important discipline this doesn't remove: a Fix PR is still a pull request, not a merge. It should run through the same CI, the same test suite, and the same review your team requires for any dependency bump — Snyk computing a "safe" version from semver metadata is not the same guarantee as your own integration tests passing against it. Treat auto-PRs as pre-drafted work that saves the research step, not as an unattended auto-merge pipeline, unless your team has deliberately decided the risk of an unreviewed bump is lower than the risk of the ticket rotting in a backlog.

Config and day-to-day usage

☺ Like you're 10: One command to check, one to keep watching after you've checked, and a policy file for the handful of things you've decided to live with on purpose.

# install and authenticate — auth opens a browser and links the CLI to your Snyk account
$ npm install -g snyk
$ snyk auth

# Open Source (SCA): test the current project's manifest against the Intel Vuln DB
$ snyk test
$ snyk test --all-projects                    # every manifest found in this directory tree (monorepo)
$ snyk test --severity-threshold=high          # exit non-zero only on high/critical — the usual CI gate
$ snyk test --json > results.json              # machine-readable, for a dashboard or DefectDojo

# monitor: SNAPSHOT the dependency tree to your Snyk dashboard for ongoing alerting.
# This does NOT fail a build — it's how you get notified about a vuln disclosed AFTER this commit shipped.
$ snyk monitor

# Container: OS-package and application-layer vulnerabilities inside an image
$ snyk container test node:18-alpine
$ snyk container test node:18-alpine --file=Dockerfile   # ties findings back to the exact Dockerfile line
$ snyk container monitor node:18-alpine                   # continuous alerting for a shipped image, same idea as monitor above

# IaC: misconfigurations in Terraform, CloudFormation, Kubernetes manifests, ARM templates
$ snyk iac test main.tf
$ snyk iac test --report                       # also uploads results to the dashboard

# attempt automatic local remediation — applies the computed upgrade to your manifest/lockfile directly
$ snyk fix

snyk test and snyk monitor answer different questions and get confused constantly. test is a point-in-time gate: it exits non-zero on a qualifying finding, which is what a CI check should call. monitor takes a snapshot and uploads it, then relies on Snyk's backend to notify you later if a new CVE is disclosed against something already in that snapshot — it always exits zero, so it will never fail a build, and a team that wires monitor into a required status check and wonders why nothing ever blocks has made exactly this mistake.

The .snyk policy file is the equivalent of a baseline or suppression list — the same discipline Semgrep's nosemgrep comments and a SAST tool's baseline serve, applied to dependency findings instead of code findings:

# .snyk — lives at the repo root; snyk test reads it automatically
version: v1.5.0
ignore:
  SNYK-JS-LODASH-590103:
    - '*':
        reason: >-
          No fix available upstream yet. Mitigated by a WAF rule blocking
          the exploited endpoint pattern. Re-check when lodash 4.17.22 ships.
        expires: 2026-10-01T00:00:00.000Z
patch: {}

An expiring, reasoned ignore is the load-bearing detail — an ignore with no expires is a permanent hole nobody revisits, exactly the failure mode this course keeps flagging for any suppression mechanism. Wiring the gate into CI looks like any other status check:

# .github/workflows/snyk.yml — illustrative; pin real action versions before using
name: snyk
on: [pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high --all-projects

SNYK_TOKEN is itself a credential — store it the way secrets management requires for any pipeline secret, not as a plaintext repository variable, and rotate it the same as any other long-lived API token.

Free-tier limits

☺ Like you're 10: Free is real, but it's rationed — a certain number of checks a month, not unlimited checks forever.

Snyk's free plan has, at various points, been described as capped on the number of monthly tests across Open Source, Container, and IaC combined, on the number of tracked projects, and on the number of contributors/collaborators on an organization — with Snyk Code carrying its own, typically smaller, free allotment separate from the others. These exact numbers are commercial terms Snyk has changed more than once, so treat any specific figure here as illustrative rather than current, and check snyk.io/plans before sizing a rollout around them. What's stable across those changes is the shape of the limit, and it's worth planning for regardless of the exact numbers:

• Tests are metered, not unlimited. Every snyk test invocation — including one triggered automatically by a PR check — consumes against the monthly allotment. A monorepo with --all-projects scanning fifteen manifests, run on every push to every open PR, burns through a free allotment far faster than a single-repo team expects.
• Fix PRs and continuous monitoring are typically gated behind a paid tier for anything beyond a small number of projects — the free tier tends to let you see a finding on more projects than it lets you get ongoing monitoring or automated remediation for.
• Private-project count is capped on the free tier; public open-source repositories have historically been treated more generously, which is part of why Snyk shows up so often sponsoring or scanning open-source projects specifically.

The practical consequence: a free-tier pilot on one or two repositories tells you little about what a fleet-wide rollout will cost, because the metering scales with commit and PR volume, not with team size. Budget a real evaluation against the paid tiers' pricing before committing a whole organization to the workflow, the same way you'd hedge any vendor's advertised limits before building a rollout plan around them.

Gotchas and failure modes

☺ Like you're 10: Most of the surprises trace back to the same two facts — it needs the internet to work, and "fixed" means "a version bump was proposed," not "someone verified it still works."

• No network, no scan. Unlike Trivy or OWASP Dependency-Check, an air-gapped build agent or an offline environment cannot run snyk test against the hosted service at all. Snyk does sell an on-prem/broker deployment for regulated environments, but that's a separate, enterprise-tier architecture, not the default CLI experience.
• monitor is not a gate. Covered above, and worth repeating because it's the single most common misconfiguration: snyk monitor always exits zero. A pipeline that calls monitor expecting it to block a build on a known vulnerability will never block anything.
• A Fix PR changing your lockfile can still break your build. The proposed version satisfies semver and clears the vulnerability; it does not guarantee your test suite, your transitive peer-dependency constraints, or a breaking change the maintainer shipped without a major-version bump won't bite you. Require the PR to pass the same CI as any other change before merging it.
• License findings inherit registry metadata's own accuracy problems. Snyk's license compliance check reads whatever license field the package registry publishes, which is sometimes missing, stale, or simply wrong. Treat a license flag as a prompt to verify, not as ground truth — see dependency & license risk management for the fuller discipline around this.
• Test-count metering can throttle a gate silently. A free or under-provisioned org that exhausts its monthly test allotment mid-sprint can see scans start failing or getting skipped for reasons that look nothing like a security finding — budget and monitor usage the same way you'd monitor any other quota-limited dependency in a pipeline.
• Container scanning still needs an SBOM-shaped mental model. snyk container test tells you what's vulnerable in the image you built; it doesn't replace generating a durable, portable inventory of what's actually in that image for downstream consumers. See software bills of materials and Syft & Grype for the tool built specifically around producing that artifact.

Snyk vs. Trivy vs. OWASP Dependency-Check: overlap and differences

☺ Like you're 10: All three can tell you a dependency is bad. Only one of them will also write the fix for you — and that convenience is exactly what costs money and needs the internet.

All three genuinely overlap on the core question — "does this dependency tree contain something with a known CVE?" — and a team running any one of them is doing real SCA. The differences are architectural and commercial, not about which one is more "correct":

The decision most teams actually face isn't "replace Trivy/Dependency-Check with Snyk" — it's whether the remediation automation and curated prioritization are worth a commercial license and a cloud dependency on top of tools that already do the detection half for free. A common, defensible pattern: run Trivy as the free, fast, always-available gate on every build (container images especially — Trivy's image-layer scanning is fast and requires nothing beyond a cached database), and layer Snyk on top for the repositories where the Fix PR workflow actually gets used and the team has budgeted for it, rather than paying for Snyk everywhere and getting Trivy's coverage for free nowhere. Neither choice is a downgrade — see software composition analysis in depth for how a mature pipeline usually ends up layering more than one SCA source rather than picking exactly one, and IaC security & policy as code for where Snyk IaC's misconfiguration checks sit next to infrastructure-as-code hardening's broader toolchain.