Interpreting and prioritizing Snyk findings

The Snyk Priority Score is a good reference when prioritizing Snyk findings, and should be taken into consideration. Be mindful that Snyk reports on potential vulnerabilities, so you will still need to investigate if the reported issue is a true positive or not.

For issues with a fix available, you can trigger Snyk to create a pull-request which addresses the issue. The fix usually involves upgrading the dependency to a vulnerability free version or with a patch. This upgrade might break the code and Snyk will indicate this in the pull-request created. The reviewer is responsible to ensure that the changes in the PR won't cause issues with the project.

In most languages, a minor (1.1.x → 1.2.x) or patch (1.1.1 → 1.1.2) release is considered “non-breaking”. Whilst a major version (1.x.x → 2.x.x) contains breaking changes.

For issues with no fix available it is up to the developers to evaluate how to handle this - whether it be explicitly ignoring the issue until a fix is available, replacing the dependency, or removing the dependency all together as you discover it is not really needed.

On a side-note:
It is a good practice to define Security Requirements for your applications. In the context of adopting Snyk, it makes a lot of sense to add a requirement covering the how long exposure window is tolerated for your application.

Ex.

The remediation time of newly discovered vulnerabilities for our application will take no longer than:
Critical: < 7 days
High: < 30 days
Medium-Low: Resolve based on availability

For more information, see Snyk's documentation