Snyk Explained: How It Tests Dependencies, Code, Containers and IaC, and How to Use It

Snyk is the tool many engineers meet first in application security, because it runs where developers already work: the command line, the IDE, pull requests and CI. In an interview, knowing the product names matters less than knowing what each test reads, how a result becomes a fix, and why a green check is not proof of safety.

What it is

Snyk is a developer-facing application security platform with four long-standing products:

• Snyk Open Source is software composition analysis (SCA). It reads manifest and lock files, builds the dependency tree and matches it against Snyk's vulnerability and licence data.
• Snyk Code is static application security testing (SAST) for first-party code.
• Snyk Container tests images for operating system packages and, by default in current CLI versions, the application dependencies inside them.
• Snyk IaC tests Terraform, CloudFormation, Kubernetes manifests, ARM templates and Terraform plan output.

Newer additions include secrets detection (snyk secrets test, generally available since October 2026), an AI bill of materials (snyk aibom) and a set of agent-security and "Evo" agentic products launched through 2026, several of them still in preview. Snyk bought Invariant Labs, an agent-security start-up, in June 2025 and the DAST company Probely in late 2024.

How it works

Two ways in. You can import repositories through an SCM integration (GitHub, GitLab, Bitbucket or Azure Repos), which lets Snyk run pull request checks and open fix pull requests. Or you can run the CLI locally and in CI. Most teams use both: the integration for coverage and fix PRs, the CLI for gates in pipelines that the integration does not see.

Dependencies need a resolved project. snyk test detects supported manifests automatically, but some ecosystems need the build tool to have run first. For .NET it reads project.assets.json, so dotnet restore must come before the scan. A scan that runs before dependencies resolve tests the wrong thing.

Code analysis runs in Snyk's cloud. The CLI sends code for analysis. Snyk's data-handling page says source is deleted after analysis and only the call graph and function names are kept. That is a question a security reviewer should ask of any SaaS SAST tool.

Reachability builds the application's call graph and checks for a path to the vulnerable function identified from the upstream fix. It is generally available through SCM integrations for Java, JavaScript and TypeScript, and Python, and in Early Access from the CLI with --reachability=true. Results are REACHABLE, NO PATH FOUND or NOT APPLICABLE.

How to use it

Day one: authenticate and run the first scans

snyk auth                      # or set SNYK_TOKEN in CI
snyk test                      # open source dependencies
snyk code test                 # first-party code (SAST)
snyk container test app:1.4 --file=Dockerfile
snyk iac test infra/

Passing --file=Dockerfile to a container test adds base-image upgrade advice, which is usually the biggest single fix. For a monorepo, --all-projects tests every detected manifest.

Week one: triage the backlog

1. Start with fixable, high-severity, reachable issues. --fail-on=upgradable only fails when an upgrade exists, which keeps early gates from blocking on problems nobody can fix yet (it is not supported for Go).
2. Fix the base image before individual packages. One base-image bump often clears dozens of container findings.
3. Record exceptions with a reason and an expiry. snyk ignore writes to the .snyk policy file in the repository, so the decision is reviewed like code.
4. Turn on fix and upgrade pull requests for repositories with owners who will merge them. Upgrade PRs are only available on GitHub, GitHub Enterprise and Bitbucket Cloud.

Every day: gate and monitor

In CI, a failing test returns exit code 1, a command failure returns 2, and "no supported project" returns 3. Treat 2 and 3 as failures too, or a broken scan becomes a silent pass. A typical gate is snyk test --severity-threshold=high --sarif-file-output=snyk.sarif, with the SARIF uploaded to wherever developers see findings. After a merge to the main branch, run snyk monitor so a vulnerability published next month raises an alert for code you already shipped.

Where it stops

• "No path found" is not "safe". The documentation says so explicitly, and reflection and dynamic loading can hide real paths.
• SCA sees declared dependencies. Vendored code, binaries copied into an image without a package manager, and dependencies fetched at run time can be missed.
• A scan is a point in time. Without snyk monitor or an imported project, nothing tells you about next week's advisory.
• AI fixes need review. Snyk Agent Fix proposes code changes; like any generated patch, it needs tests and a human reviewer.

How it comes up in interviews

• "Snyk reports 4,000 vulnerabilities across our services. Where do you start?" Talk about fixability, reachability, exposure, base images and owners, not the raw count.
• "How would you stop vulnerable dependencies reaching production without blocking every build?" Describe severity thresholds, --fail-on, exceptions with expiry, and monitoring after release.
• "What can SCA not tell you?" Exploitability in your deployment, vendored and run-time-fetched code, and malicious packages that have no CVE yet.

Sources

Checked on 13 November 2026: Snyk CLI command reference and snyk test, snyk code test, snyk container test and snyk iac test documentation (docs.snyk.io); Snyk reachability analysis documentation; "How Snyk handles your data"; Snyk press releases on Probely (12 November 2024), Invariant Labs (24 June 2025), Agent Security (23 March 2026) and Evo Agentic AppSec (15 October 2026).