The following shows how your team might deal with issues as they arise:
We recommend you create an equivalent process for your team, to have a robust system to resolve issues.
The remainder of this page describes some processes and considerations when you resolve issues.
Fix by upgrade: test your fixes
Even when Snyk automatically creates fix PRs for vulnerabilities, you should still research and test these PRs, as with any change. An upgrade to a dependency may cause a change that breaks other parts of your code, especially if it is a significant upgrade. Do not just click Fix your vulnerabilities to magically solve a vulnerability, without your involvement.
Keep the packages you use up-to-date, by making regular upgrades as part of your normal code maintenance practices; this minimizes the need to 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’s not a breaking change. You do not want to fix a vulnerability, but break the application.
To do this, you’ll need to 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’ll need to go to the code itself for inspection.
Merge advice may be available to help decide if this is a breaking change; see Merge advice.
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 don’t just use Github, they will have their own IDE for coding, 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 become 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.
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’s no fix available, Snyk cannot provide a recommendation.
When this occurs, developers will need to 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.
Upgrading the dependencies in your application can cause breaking changes; Snyk can’t fix your entire code for you, you must ensure all changes are properly understood before making them.
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?