Do not use for scanning proprietary application code for logic vulnerabilities (use SAST), for runtime vulnerability detection (use DAST), or for container OS package scanning alone (use Trivy for a free alternative).
# Install Snyk CLI
npm install -g snyk
# Authenticate with Snyk
snyk auth $SNYK_TOKEN
# Test the connection
snyk test --json | jq '.summary'
# .github/workflows/dependency-scan.yml
name: Dependency Security Scan
on:
push:
branches: [main]
pull_request:
branches: [main]
schedule:
- cron: '0 8 * * 1' # Weekly Monday 8am
jobs:
snyk-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Run Snyk to check for vulnerabilities
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: >
--severity-threshold=high
--fail-on=upgradable
--json-file-output=snyk-results.json
- name: Upload results to Snyk
if: always()
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
command: monitor
args: --project-name=${{ github.repository }}
- name: Upload SARIF
if: always()
run: |
npx snyk-to-html -i snyk-results.json -o snyk-report.html
# Python project scanning
snyk test --file=requirements.txt --severity-threshold=high --json > snyk-python.json
# Java/Maven project
snyk test --file=pom.xml --severity-threshold=medium --json > snyk-java.json
# Go module scanning
snyk test --file=go.mod --severity-threshold=high --json > snyk-go.json
# Docker image dependency scanning
snyk container test myapp:latest --severity-threshold=high --json > snyk-container.json
# Monorepo: scan all projects
snyk test --all-projects --severity-threshold=high --json > snyk-all.json
# IaC scanning (bonus)
snyk iac test terraform/ --severity-threshold=medium --json > snyk-iac.json
# .snyk policy file
version: v1.25.0
ignore:
SNYK-JS-LODASH-1018905:
- '*':
reason: "Prototype pollution in lodash. Not exploitable in our usage - no user input reaches affected function."
expires: 2026-06-01T00:00:00.000Z
created: 2026-02-23T00:00:00.000Z
SNYK-PYTHON-REQUESTS-6241864:
- '*':
reason: "SSRF in requests redirect handling. Mitigated by allowlist at proxy layer."
expires: 2026-04-01T00:00:00.000Z
patch: {}
# Severity threshold for CI failures
failOnSeverity: high
# Snyk fix: generate fix PRs for vulnerable dependencies
snyk fix --dry-run # Preview changes
# Apply fixes locally
snyk fix
# Enable auto-fix PRs via Snyk dashboard:
# 1. Navigate to Organization Settings > Integrations > GitHub
# 2. Enable "Automatic fix pull requests"
# 3. Set "Fix only direct dependencies" or "Fix direct and transitive"
# 4. Configure branch target (main or develop)
# Check license compliance
snyk test --json | jq '.licensesPolicy'
# Snyk license policy configuration via organization settings:
# - Approved licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC
# - Restricted licenses: GPL-3.0, AGPL-3.0 (copyleft risk)
# - Unknown licenses: Flag for manual review
| Term | Definition |
|---|---|
| SCA | Software Composition Analysis — identifies vulnerabilities and license risks in open-source dependencies |
| Transitive Dependency | A dependency of a direct dependency, often invisible to developers but still a vulnerability vector |
| Fix PR | Automated pull request generated by Snyk that upgrades a vulnerable dependency to a patched version |
| Snyk Monitor | Continuous monitoring mode that watches deployed projects for newly disclosed vulnerabilities |
| Exploit Maturity | Snyk's assessment of whether a vulnerability has known exploits, proof-of-concept, or no known exploit |
| Reachable Vulnerability | A vulnerability in a function that is actually called by the application code, not just present in the dependency |
| License Policy | Organization-level rules defining which open-source licenses are approved, restricted, or require review |
Context: Snyk reports a critical RCE vulnerability in a transitive dependency (log4j in a Java application). The direct dependency has not released a patch.
Approach:
snyk test --json and examine the dependency path to identify which direct dependency pulls in the vulnerable transitive<dependencyManagement> section to force the safe version of the transitive dependencyoverrides section in package.json to pin the safe versionPitfalls: Ignoring transitive vulnerabilities because "we don't use that function directly" is risky. Attackers can chain vulnerabilities across dependency boundaries. Version overrides can break API compatibility between the direct and transitive dependency.
Snyk Dependency Scan Report
=============================
Project: org/web-application
Manifest: package.json
Dependencies: 342 (47 direct, 295 transitive)
Scan Date: 2026-02-23
VULNERABILITY SUMMARY:
Critical: 1 (1 fixable)
High: 4 (3 fixable)
Medium: 12 (8 fixable)
Low: 23 (15 fixable)
CRITICAL:
SNYK-JS-EXPRESS-1234567
Package: express@4.17.1 (direct)
Severity: Critical (CVSS 9.8)
Exploit: Mature
Fix: Upgrade to express@4.21.0
Path: express@4.17.1
HIGH:
SNYK-JS-JSONWEBTOKEN-5678901
Package: jsonwebtoken@8.5.1 (transitive)
Severity: High (CVSS 7.6)
Exploit: Proof of Concept
Fix: Upgrade passport@0.7.0 (which upgrades jsonwebtoken)
Path: passport@0.6.0 > jsonwebtoken@8.5.1
LICENSE ISSUES:
[RESTRICTED] GPL-3.0: some-package@1.2.3 (transitive via other-pkg)
QUALITY GATE: FAILED (1 Critical with fix available)