How do you scan open source dependencies for vulnerabilities using Snyk?

Imagine your project is a building made of bricks, and each brick is an open source library. You chose the bricks carefully, but each brick is itself made of smaller bricks (transitive dependencies) that you never directly selected. Snyk inspects every single brick in the wall, not just the ones you picked, to find cracks that attackers could exploit.

When you run 'snyk test' inside a project directory, Snyk first identifies the package manager by looking for manifest files: package.json and package-lock.json for npm, pom.xml for Maven, requirements.txt or Pipfile for Python, go.mod for Go, Gemfile for Ruby, and many others. It then resolves the full dependency tree, including transitive dependencies that your direct dependencies pull in. For the payments-api project using Express.js, Snyk might find that Express depends on body-parser, which depends on qs, and qs version 6.5.2 has a prototype pollution vulnerability. Even though you never explicitly installed qs, it is in your dependency tree and poses a risk.

Snyk matches each resolved package and version against its vulnerability database. The results show the vulnerability name, CVE identifier, severity level (critical, high, medium, low), the vulnerable package path (showing the transitive chain), whether a fix is available, and the recommended upgrade path. For npm projects, Snyk can distinguish between dependencies and devDependencies, allowing you to focus on production-relevant issues. The 'snyk test' command exits with a non-zero code when vulnerabilities are found, making it easy to fail CI/CD pipeline builds that introduce new security issues.

In a production workflow for the order-processing-service, teams typically run 'snyk test' as a gate in the CI pipeline. When a developer opens a pull request that adds a new dependency or updates an existing one, the pipeline runs 'snyk test' and blocks the merge if critical or high severity vulnerabilities are detected. Beyond one-time testing, 'snyk monitor' takes a snapshot of the dependency tree and uploads it to the Snyk dashboard. Snyk then continuously monitors that snapshot and sends alerts when new vulnerabilities are disclosed that affect any package in the tree. This is crucial because a dependency that was safe yesterday might have a vulnerability disclosed today.

A key detail beginners miss is the difference between 'snyk test' and 'snyk monitor.' The test command is for gating: it checks the current state and reports pass or fail. The monitor command is for ongoing surveillance: it uploads the project snapshot so Snyk can alert you about future disclosures. Production teams use both: test in CI to catch issues before merge, and monitor on the default branch to catch new disclosures against already-deployed code.