performing-sca-dependency-scanning-with-snyk

name	performing-sca-dependency-scanning-with-snyk
description	This skill covers implementing Software Composition Analysis (SCA) using Snyk to detect vulnerable open-source dependencies in CI/CD pipelines. It addresses scanning package manifests and lockfiles, automated fix pull request generation, license compliance checking, continuous monitoring of deployed applications, and integration with GitHub, GitLab, and Jenkins pipelines.
domain	cybersecurity
subdomain	devsecops
tags	["devsecops","cicd","sca","snyk","dependency-scanning","secure-sdlc"]
version	1.0.0
author	mahipal
license	Apache-2.0
nist_csf	["PR.PS-01","GV.SC-07","ID.IM-04","PR.PS-04"]

Performing SCA Dependency Scanning with Snyk

When to Use

• When applications use open-source packages that may contain known vulnerabilities
• When compliance requires tracking and remediating vulnerable dependencies (PCI DSS, SOC 2)
• When needing automated fix PRs for vulnerable dependencies in CI/CD
• When license compliance requires visibility into open-source license obligations
• When continuous monitoring is needed for newly disclosed vulnerabilities in deployed dependencies

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).

Coverage Gaps & Validation

• Transitive deps silently skipped: Snyk only resolves the full tree when a lockfile is present. snyk test against a bare requirements.txt or package.json with no package-lock.json/poetry.lock scans direct deps only. Generate the lockfile first and confirm the "Dependencies" count includes transitives, not just 47 direct.
• Vendored / monorepo deps missed: committed vendor/, sub-projects, and non-default manifests aren't found unless you pass --all-projects (or --file=). Verify each manifest appears in the test output.
• --severity-threshold=high hides exploitable lows: the threshold suppresses medium/low from the report entirely, not just the gate. Scan at --severity-threshold=low for inventory, gate separately.
• Gate not actually failing: snyk test exits non-zero on findings, but snyk monitor always exits 0. Use --fail-on=all (not just --fail-on=upgradable, which passes when no upgrade exists) and confirm the CI step's exit code.
• OS vs app libs: snyk test covers app dependencies; OS packages in an image need snyk container test. Run both.
• Reachability ≠ presence: "we don't call that function" is not proof — Snyk's reachability is best-effort and misses dynamic dispatch. Validate completeness by adding a knowingly vulnerable pin (e.g. lodash@4.17.4) and confirming it surfaces at the expected severity and trips --fail-on=all.