snyk-test

Per github.com/snyk/snyk, companion subcommands cover adjacent surfaces:

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

• 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

Limitations

• Commercial license required - pricing scales with project count
  • scanned manifests.
• 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