How do you view and interpret Snyk scan results?

Think of Snyk scan results as a medical report for your application. The CLI output is like the doctor's verbal summary in the exam room: quick, direct, and actionable. The Snyk dashboard is like the full lab results portal: detailed, historical, and organized by system. Both present the same underlying data but serve different audiences and use cases.

When you run 'snyk test' in the terminal, the CLI displays results grouped by vulnerability. Each entry shows the vulnerability title, the Snyk ID (like SNYK-JS-LODASH-590103), the severity level (critical, high, medium, or low), the CVSS score, the vulnerable package name and version, the dependency path showing how that package entered your project, and whether a fix is available. If a fix exists, Snyk tells you exactly what to do: upgrade a direct dependency to a specific version, or apply a Snyk patch. The summary at the bottom shows total counts by severity. If the scan finds issues, the command exits with code 1, which CI pipelines interpret as a failure. If no issues are found, it exits with code 0.

The Snyk web dashboard at app.snyk.io provides a richer view. When you run 'snyk monitor' or connect your Git repository, the dashboard shows each project with its vulnerability counts, Priority Scores, and fix suggestions. You can drill into a specific project to see every issue, filter by severity or exploitability, and view the dependency graph visually. For the payments-api project, the dashboard might show 3 critical, 12 high, 25 medium, and 40 low severity issues, with a trend chart showing whether the count is going up or down over time. The reporting section aggregates data across all projects in your organization, helping security teams understand which repositories carry the most risk and which teams are fixing vulnerabilities fastest.

For CI/CD integration, JSON and SARIF output formats are essential. Running 'snyk test --json' produces machine-readable output that pipeline scripts can parse. The JSON includes every field needed for automated decision-making: vulnerability ID, severity, Priority Score, fix availability, and the complete dependency path. SARIF (Static Analysis Results Interchange Format) output integrates with GitHub Code Scanning, VS Code, and other tools that consume standardized security results. The checkout-service team might pipe JSON results into a custom script that posts a formatted summary to their Slack channel, highlighting only critical findings with available fixes.

A practical detail beginners should know is how to read the dependency path in scan results. A path like '[email protected] > [email protected] > [email protected]' means the vulnerability is in qs, which was pulled in by body-parser, which was pulled in by express. You cannot fix this by directly upgrading qs in your package.json because you do not directly depend on it. Instead, you need to upgrade express or body-parser to a version that pulls in a fixed version of qs. Understanding this transitive dependency chain is fundamental to interpreting and acting on Snyk results effectively.