snyk-test
Per github.com/snyk/snyk, 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;
for container scanning, see trivy-image.
When to use
- The team has a Snyk license and uses Snyk as primary SCA.
- Multi-language project with mixed package managers - Snyk's
auto-detect simplifies setup vs running per-ecosystem audit
commands.
- Continuous-monitoring requirement (vuln alerts on
newly-disclosed CVEs against pinned dependencies).
- Layered with
osv-scanner for
cross-DB consensus signal.
Step 1 - Install + authenticate
Per sn-gh:
npm install -g snyk
snyk auth
The 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 test
Step 2 - Basic SCA scan
Per sn-gh: "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 available
Common 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 GHA
The 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-app
Per sn-gh: "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: 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
- Commercial license required - pricing scales with project count
- Snyk's vuln database has its own coverage profile; pair with
osv-scanner for OSV.dev consensus.
- Container scanning is a separate product line; this skill targets
SCA only.
- For pure-OSS workflows without Snyk,
osv-scanner
npm-pip-maven-audit cover
similar ground.
References
- sn-gh - repository, install, basic commands
- references/snyk-policy-and-triage.md -
.snyk policy schema, suppression layers, justification template, re-review cadence
- docs.snyk.io - full documentation
- docs.snyk.io/snyk-cli/commands/test -
snyk test reference
- snyk.io/security-rules - vuln database
osv-scanner - open-source SCA alternative