Skip to content

Resolving Vulnerabilities

As teams begin to get feedback from security scanning, you will need to determine a strategy to resolve vulnerabilities. How will you prioritize the work, and what is that workflow to resolve vulnerabilities?

How to prioritize

Snyk provides accessible tools to help teams identify which vulnerabilities to prioritize. The two primary approaches are Priority Score, which uses several inputs to determine priority, and Severity, which is identifies the impact of the vulnerability.

Severity. Vulnerabilities are classied as Critical, High, Medium, and Low. Currently, the app-scan job used for Snyk in your CircleCI workflows gates on Medium by default.

Score. Snyk has an algorithm to provide a Priority Score. Inputs that determine the score:

  • How severe is the vulnerability?
  • Is there a fix available?
  • Is there an identified exploit or potential for exploit?

Learn more about how Snyk determines score and severity.

Remediation workflow

  • Identify vulnerability. Only resolve one at a time in order isolate issues and resolutions.
  • Research solution. Leverage the available resources from Snyk and recommended remediation approaches.
  • Provide fix. Often the resolution will be version bumps, but in some cases aditional refactoring would be needed. If a fix is not currently available, add to the .snyk file to ignore.
  • Run test suite. Changing dependencies can have a ripple effect of how your application is built and run. Be sure to run the test suite locally to ensure you can still build and run unit tests before committing changes.

Several factors play in to fixing a vulnerability coming from an open source dependency. Below are some tips to consider when working on resolving a vulnerability found by the Snyk SCA scan. If Snyk provides a recommended fix check on the following:

  • Is the fix a version bump to the parent package of the vulnerable module? If so, great! If not, consider whether changing the version of the vulnerable module directly would affect compatibility.

  • Is the recommended fix a major version bump? If so, you'll want to thoroughly test compatibility of the change. If not, you are probably fine to proceed (but still make sure to test) - minor and patch versions are backwards compatible when semantic versioning is properly followed.

  • Is the version of the vulnerable module (or its parent package) being controlled by something external? Examples of this could be a Bill of Materials (BOM) in Gradle projects (The Java starter kit uses one of these) or a constraint on the version of your module causing that version to be selected. In cases like this your approach to pinning the version may differ from a typical dependency. You may have to go to the source, like the BOM, or you may have to introduce a constraint of your own.

Ignoring vulnerabilities

In some situations, there are no solutions to a vulnerability. In this case, teams can add a vulnerability to a list of ignores.

Although Snyk ignore can be managed in the app, we recomend using code. We can use the .snyk file to store ignores and append them manually or with through the CLI.

$ snyk ignore --id=<SNYK_VULNERABILITY_ID> --reason='<reason>'

Include:

  • Vulnerabilitity information
  • CVE information
  • Reason

Ignoring vulnerabilities are one of the responsibilities of the Org Admin. They should review these through PRs or notifications by team members. By default, Snyk ignores expire after a month and are added as a pending task on a monthly basis.

Ignored vulnerabilities will be audited regularly so ensure you have good reason to ignore a vulnerability before doing so and make sure the reason is clearly defined when you perform the ignore.

Git hooks

Some teams opt to use Git hooks to get automated feedback before the CI pipeline run. This is particularly helpful for teams using trunk based development committing directly to the main branch.

We recommend adding the snyk test and snyk code test commands to the pre-push Git hook. Decide as a team the best approach on how to embed security locally.

#!/bin/sh

echo "***** Running SNYK SCA scan *****"
snyk test --dev --prune-repeated-subdependencies
echo "***** Done running Snyk SCA scan *****"

echo "***** Running SNYK SAST scan *****"
snyk code test
echo "***** Done running Snyk SAST scan *****"