Fix your first vulnerability - deeper dive
Recap You have seen a simple example of how to fix vulnerabilities.
This section takes a detailed look at the fix process, exploring scenarios in more depth, to reflect more typical resolution processes.
Example process flowchart: see how you can design a fix process for your teams.
Upgrade fixes: examine a full robust process to use fix PRs.
Fixing a vulnerability with no suggested fix: what to do if Snyk cannot recommend actions.
Example process flowchart
The following shows how your team might deal with issues as they arise:
We recommend that 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:
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 the vulnerability until a fix is available:
Research whether the vulnerability is a false positive; if so, you can ignore it permanently:
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 and next step
Upgrading the dependencies in your application can cause breaking changes. Snyk cannot fix all of your code for you. Before you make changes, you must ensure those changes are properly understood.
You have seen how to understand and resolve a single vulnerability.
Look now at assigning fix work, and managing team work using Reports to see how can this work be managed and assigned for your applications for all identified vulnerabilities.
Last updated
