Links

Fix your first vulnerability - deeper dive

Introduction

This section takes a detailed look at the fix process, exploring scenarios in more depth, to reflect more typical resolution processes.

Example process flowchart

The following shows how your team might deal with issues as they arise:
Use this example triage process for your own processes
Use this example triage process for your own processes
We recommend you create an equivalent process for your team, to have a robust system to resolve issues.

Fix by upgrade: test your fixes

When Snyk automatically creates fix PRs to upgrade a dependency, you should still research and test these PRs, as with any change. An upgrade, especially a significant one, may cause a change that breaks other parts of your code. You should not simply click Fix your vulnerabilities and submit the PR, without any research.
Tip Keep the packages you use up-to-date, by making regular upgrades as part of your normal code maintenance practices; this minimizes the need for major changes which are more likely to impact your code.
So as part of a fix, you should understand the impacts of an upgrade, to ensure that it is not a breaking change. You do not want to fix a vulnerability but break the application.

Research impacts

To understand the fix fully, you should research the change, examine the impacts, and make any needed secondary changes to your code, to ensure that the upgrade does not cause any problems. To do this, you should inspect the code itself.
For significant upgrades, you may decide to ignore the vulnerability temporarily (say, for 30 days), allowing you time to understand the impacts of the upgrade.

Working in your coding environment

Of course, developers do not just use Github, they have their own IDE, such as JetBrains:
View PR impacts by inspecting code in the IDE
View PR impacts by inspecting code in the IDE
If you have the relevant Snyk IDE extension (see Snyk for IDEs), you can review the vulnerability in that IDE, allowing you to inspect the impacts of changes in your own code environment. You can then manage the PR from your IDE, and push this change up to GitHub as normal.

Processing upgrade fixes

How you process upgrades (whether Snyk Fix PR advice becomes the actual PR submitted) may be driven by your own team processes. Factors involved may include the level of upgrade (major/minor/patch), the team code processes, and the areas of code impacted.
For example:
  • A large established team with mature processes and released applications to maintain might have practices to ensure that all developers always check and test all upgrades for breaking changes.
  • A startup team, with unreleased applications in development, might accept that all developers can process minor or patch upgrades, to aid speedy development.
  • Your team might have processes that state junior developers must have all changes reviewed by senior mentors before making the change, but that senior developers can have more autonomy for changes.
  • Your team may have a flexible approach, with processes to mandate different levels of oversight / review based on the size of the upgrade.
You can configure settings for your code repository integration, to disable Snyk’s ability to open fix PRs, if this is seen as too risky - for example, see GitHub integration.

PRs for open source / application code

  • Fixing vulnerabilities in open source libraries (scanned by Snyk Open Source) typically involves upgrading existing packages. After review, you may find impacts (breaking changes) in different files; if so, you’ll need additional changes to those files, with additional PRs.
  • Fixing vulnerabilities in your own application code (scanned by Snyk Code) typically involves improving quality in specific areas - "fix these lines of code”. These changes may be less likely to cause breaking changes; if so, you may not need to make additional PRs.

Fixing a vulnerability with no suggested fix

If there is no fix available, Snyk cannot provide a recommendation.
When this occurs, developers should provide an alternative solution to address the vulnerability. Possible actions include:
  • Accept the risk by ignoring the vulnerability for a period of time. For example, if this vulnerability is assessed as low-risk for your application at this point:
Ignore a vulnerability temporarily
Ignore a vulnerability temporarily
  • Ignore the vulnerability until a fix is available:
Ignore a vulnerability until a fix is available
Ignore a vulnerability until a fix is available
  • Research whether the vulnerability is a false positive; if so, you can ignore it permanently:
Ignore a vulnerability if it is a false positive
Ignore a vulnerability if it is a false positive
  • Change your code: write a code solution to address the vulnerability; perhaps even providing a suggestion for the open source code to address it, contributing to the open source community.
  • Replacing the vulnerable dependency with other code.

Summary

Upgrading the dependencies in your application can cause breaking changes; Snyk cannot fix your entire code for you, you must ensure all changes are properly understood before making them.

What's next?

You understand now how to understand and resolve a single vulnerability. But how can this work be managed and assigned for your applications for all identified vulnerabilities?