snyk-test
Configures and runs Snyk, a commercial multi-mode scanner: snyk test for SCA (dependency scanning), snyk code test for SAST (code security scanning), snyk container test for container images, snyk iac test for IaC (infrastructure-as-code), snyk monitor for continuous new-vuln alerts; policy file .snyk for ignore + patch. Use when the team has a Snyk license and needs SCA (dependency scanning) or continuous vuln monitoring; for open-source scanning without a Snyk license, prefer osv-scanner.
Install with skills.sh (any agent)
npx skills add testland/qa --skill snyk-testsnyk-test
Per github.com/snyk/snyk (opens in new window), companion subcommands cover adjacent surfaces:
| Subcommand | Surface |
|---|---|
snyk test | SCA (open-source dependencies) |
snyk code test | SAST (proprietary code) |
snyk container test <image> | Container image scanning |
snyk iac test | IaC scanning (Terraform, Kubernetes) |
snyk monitor | Continuous monitoring with new-vuln alerts |
This skill focuses on snyk test for SCA. For SAST coverage, prefer the OSS-first patterns in semgrep-rules (in the qa-sast plugin); for container scanning, see trivy-image (in the qa-sbom plugin).
When to use
Step 1 - Install + authenticate
Per sn-gh (opens in new window):
npm install -g snyk
snyk authThe snyk auth flow opens a browser window; the credential is stored at ~/.config/configstore/snyk.json. For CI, use SNYK_TOKEN env var (no snyk auth needed):
export SNYK_TOKEN=$(cat /path/to/snyk-token)
snyk testStep 2 - Basic SCA scan
Per sn-gh (opens in new window): "Run snyk test in a directory containing a supported package manifest (like package.json or pom.xml)."
snyk test # current dir; auto-detects manifest
snyk test --all-projects # recursive multi-manifest scan
snyk test --org=my-org # explicit org context
snyk test --severity-threshold=high # filter LOW + MEDIUM (less noise)
snyk test --fail-on=upgradable # only fail if upgrade availableCommon output format flags:
snyk test --json # JSON for parsing
snyk test --json-file-output=snyk.json # JSON to file
snyk test --sarif-file-output=snyk.sarif # SARIF for GHAThe JSON / SARIF output feeds downstream aggregation for cross-tool deduplication + prioritization.
Step 3 - snyk monitor for continuous tracking
snyk monitor --org=my-org --project-name=my-appPer sn-gh (opens in new window): "create dependency snapshots and receive alerts about newly disclosed vulnerabilities."
The snapshot lives on snyk.io/app/your-org; new CVEs disclosed against your pinned versions trigger email + Slack alerts (configured in Snyk dashboard).
Step 4 - .snyk policy + false-positive triage (MANDATORY)
Suppress false positives through a .snyk policy file at the repo root. Every per-vuln ignore must include an expires: field - Snyk validates this at scan time. Layer .snyk ignores (auditable in git) with dashboard ignores (org-wide) and the --severity-threshold= / --fail-on=upgradable CI filters, and re-review each ignore quarterly.
Full policy schema, the mandatory justification template, the suppression-layer table, and the re-review cadence: references/snyk-policy-and-triage.md.
Step 5 - CI integration
jobs:
snyk:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: snyk/actions/setup@master
- run: snyk test --severity-threshold=high --json-file-output=snyk.json
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
- run: snyk monitor # snapshot for continuous monitoring
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
if: github.ref == 'refs/heads/main'
- uses: actions/upload-artifact@v4
if: always()
with: { name: snyk-report, path: snyk.json }Step 6 - Multi-language support
Per sn-gh (opens in new window): Snyk scans "Open Source (via package managers)", "Application code vulnerabilities", "Container images and Kubernetes applications", and "Infrastructure as Code (Terraform, Kubernetes)."
Auto-detection covers package managers including npm / yarn / pnpm / pip / pipenv / poetry / Maven / Gradle / sbt / Composer / RubyGems / Go modules / Cargo / Hex / NuGet / CocoaPods / Swift Package Manager.
For unsupported / custom package managers, generate an SBOM and feed via snyk test --file=sbom.cyclonedx.json (post-2024 feature; verify against current docs).
Worked example
A team with a Snyk license adds SCA to a mixed npm + Maven monorepo. In CI they run snyk test --all-projects --severity-threshold=high --json-file-output=snyk.json, which auto-detects both package.json and pom.xml and reports 3 high-severity findings. One is SNYK-JS-LODASH-567746 in a lodash path that never receives user input. A reviewer verifies the attack path is unreachable, then adds a .snyk ignore with reason:, approved-by:, expires: '2026-12-15...', and a re-review-date, so the next scan passes the --severity-threshold=high gate. snyk monitor runs on main to snapshot the dependency tree, and the team pairs the run with osv-scanner for cross-database consensus. The .snyk ignore resurfaces in the quarterly re-review grouped by re-review-date.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
Run snyk test without --severity-threshold | Noise on first scan; team disables | Start --severity-threshold=high (Step 2) |
.snyk ignore without expires | Snyk policy rejects; OR debt persists forever | Mandatory expires: (Step 4) |
Skip snyk monitor on main branch | Newly-disclosed CVEs against pinned deps go undetected | Add to main-branch CI (Step 5) |
| Run only Snyk; skip OSV | Single-DB blind spots | Pair with osv-scanner (cross-ref) |
| Hardcode SNYK_TOKEN in scripts | Token leak | CI secret + redact (Step 5) |
Limitations
References
Snyk `.snyk` policy and false-positive triage
View source (opens in new window)Snyk .snyk policy and false-positive triage
.snyk policy file
Per Snyk's policy-file model (consult docs.snyk.io for current schema), .snyk lives at the project root and supports:
# .snyk
version: v1.0.0
ignore:
SNYK-JS-LODASH-567746:
- '*':
reason: "False positive; we don't pass user input to Lodash sortBy"
expires: '2026-12-15T00:00:00.000Z'
created: '2026-05-15T00:00:00.000Z'
patch: {}Per-vuln ignore can be scoped to specific paths (* > lodash, my-package > lodash) and must include an expires: field - Snyk policy validates this at scan time.
False-positive triage (MANDATORY)
Three suppression layers:
| Mechanism | Where | Use |
|---|---|---|
.snyk policy file ignore (with expiration) | Repo root | Per-vuln + per-path; auditable in git history |
| Snyk dashboard "Ignore" action | snyk.io/app | Org-wide; persistent; reviewer-tracked |
--severity-threshold= filter | CI flag | Scan-time noise reduction (not suppression) |
--fail-on=upgradable flag | CI flag | Only fail if a fix exists; soft gate |
Justification template (mandatory in .snyk):
ignore:
SNYK-JS-LODASH-567746:
- '*':
reason: |
Reason: Lodash sortBy not exposed to user input;
attack path requires admin context which is separately
controlled. Verified in code review (PR #1234).
approved-by: alice@example.com
expires: '2026-12-15T00:00:00.000Z'
created: '2026-05-15T00:00:00.000Z'
re-review-date: '2026-09-15T00:00:00.000Z'Cadence: every quarter, list .snyk policies grouped by re-review-date and process expired entries.
Related skills
bundle-audit-ruby
Use when a Ruby project has a Gemfile.lock and needs CVE/GHSA scanning or a CI SCA gate. Installs and runs bundler-audit against a Ruby Gemfile.lock, updating the ruby-advisory-db corpus, scanning for vulnerable gem versions and insecure sources, suppressing false positives via .bundler-audit.yml, and gating CI on non-zero exit. Ruby-only SCA scanner: for other ecosystems use npm-pip-maven-audit (multi-ecosystem dispatcher), snyk-test, or osv-scanner; cargo-audit-rust is the Rust analog; once findings exist, reachability-analyzer downranks unreachable gems - not this.
cargo-audit-rust
Configures and runs cargo-audit against the RustSec Advisory Database for Rust projects; covers `cargo audit` (vulnerability scan), `cargo audit fix` (automated dependency updates), `--deny unmaintained|unsound|yanked|warnings` exit-code control, `audit.toml` per-advisory suppression with mandatory `expires` + `reason`, SARIF output for GitHub Code Scanning upload, and `rustsec/audit-check` GitHub Actions integration. Use when the codebase has a Cargo.lock and needs Rust-specific SCA beyond what the multi-ecosystem npm-pip-maven-audit wrapper provides.
cve-exploitability-triage
Ranks known CVE findings by real-world exploitability instead of severity alone: enriches each CVE with its EPSS probability (the chance exploitation activity is observed in the next 30 days) and CISA KEV membership (confirmed exploited in the wild), applies OpenVEX status assertions to set aside vulnerabilities the product is not affected by, applies a reachability heuristic for vulnerable code that is never called, and assigns every finding to one of four buckets (Fix-Now, Fix-This-Sprint, Fix-Backlog, Accept-Risk) using documented EPSS thresholds. Treats a CISA KEV listing as non-waivable under any justification. Use when a dependency, container image, or SBOM vulnerability scan has produced more CVEs than the team can fix in the available window and someone has to decide which ones get fixed first and which can wait.
dependabot-config
Reference for `.github/dependabot.yml` - GitHub-native dependency-update orchestrator. Required keys (`version: 2`, `updates[]` array) plus per-update fields (`package-ecosystem`, `directory` / `directories`, `schedule.interval`); common optional fields (`ignore`, `groups`, `allow`, `labels`, `milestone`, `open-pull-requests-limit`, `target-branch`, `vendor`, `versioning-strategy`, `assignees`, `commit-message`); auto-rebase + grouped-PR + security-only updates. Use when authoring or reviewing Dependabot configs in GitHub-hosted repos.
npm-pip-maven-audit
Configures and runs native package-manager audit commands across ecosystems - `npm audit --audit-level=high` (npm), `yarn npm audit` (Yarn 2+), `pnpm audit` (pnpm), `pip-audit` (Python via PyPA), `mvn dependency:check` (Maven via OWASP Dependency-Check plugin), `cargo audit` (Rust), `bundle audit` (Ruby Bundler); fastest no-install-required SCA option. Use when the team wants fast, no-extra-tooling SCA in CI as a first line of defense, or pairs with snyk/osv-scanner for layered coverage.
osv-scanner
Configures and runs Google OSV-Scanner - open-source SCA against the OSV.dev vulnerability database; supports `osv-scanner scan -r ./` recursive scan + per-lockfile scan via `-L package-lock.json`; SBOM input (CycloneDX / SPDX) for non-standard package managers; `--format json|sarif|markdown|vertical|html` output; suppressions via `osv-scanner.toml` config. Use when the team needs OSS-native SCA without commercial-license overhead, or wants a second-opinion DB pair with Snyk's commercial DB.
reachability-analyzer
Runs dead-dependency analysis across JS, Python, and Rust projects using ecosystem-native static tools (`depcheck`/`knip` for JS, `vulture` for Python, `cargo-machete` for Rust), then cross-references the unused-dependency list against SCA findings to downrank vulns in code that is never loaded. Use when SCA output (from `osv-scanner`, `snyk-test`, or `npm-pip-maven-audit`) is too noisy to triage and the team needs to separate unreachable CVEs from exploitable ones before sprint planning; sibling cve-exploitability-triage ranks by EPSS/KEV exploitation signal, not code reachability.
renovate-config
Reference for `renovate.json` - Mend Renovate dependency-update orchestrator (multi-platform: GitHub / GitLab / Bitbucket / Azure DevOps / Gitea); top-level keys (`extends` for preset references, `schedule`, `prConcurrentLimit`, `vulnerabilityAlerts`); `packageRules[]` array with `matchPackageNames` / `matchUpdateTypes` / `automerge` matching; `ignoreDeps`, `addLabels`, `automergeSchedule`. Use when authoring or reviewing Renovate configs in any repo platform Renovate supports.