Each issue card has an ignore button that opens up a dialog where you can select why you want to ignore the issue, as well as for how long you want to ignore it.
Checking Ignore this issue until fix is available (which is checked by default if there is currently no remediation) will resurface the vulnerability as soon as we have a fix for it, and you can optionally give additional details on why you’re ignoring the issue.
 |
Note
An issue is ignored until ANY of the conditions happen - either the ignore period expires, OR the vuln becomes fixable.
When you ignore an issue in our UI, it will show who ignored it and allow you to edit or unignore it.
 |
Suppressing issues is possible via the CLI. For node.js projects, you can use Snyk wizard, which will give you the option of ignoring the vulnerability for a period of 30 days. If you want to ignore another supported language or if you want to specify a different duration, you can use the Snyk ignore command.
snyk ignore --id='npm:braces:20180219' --expiry='2018-04-01' --reason='testing'
When using Snyk wizard or Snyk ignore the .snyk policy file is updated with the path and given reason (if one was provided). Here’s an example:
'npm:moment:20170905': - moment: reason: The reason given expires: '2017-12-29T16:10:16.946Z'
More about ignoring issues in the CLI.
Since suppressing vulnerabilities carries a level of risk, there is a setting that allows you to decide whether this feature is available to admins only. To set this, go to your organization settings, and select Admin only in the “Ignores” section. When you enable Admin only for ignores, this will also disable ignores from being added via the CLI because we are unable to prevent non-admins from ignoring issues in this environment.
You can also choose to set the more details field to be a compulsory field when an issue is being ignored, requiring the user to enter a reason for each ignore.
Ignoring security issues shouldn’t be the default action, but it is sometimes necessary. The best practice is to fix or patch vulnerabilities, or to remove the vulnerable dependency, but there may still be reasons why you would want to suppress an issue – for example, if an issue doesn’t currently have a fix, you might want to snooze it until it does.
Some issues are irrelevant for certain projects (e.g. a DDOS attack for an internal service). Other times, an issue has a path that makes it non-exploitable. In these scenarios, Snyk would still recommend fixing the issue where possible, as just because the vulnerability is not exploitable today via the current code paths, it does not mean it will not be in the future if the code changes.
Issues can be ignored and viewed via the snyk.io UI using the issue filter on your project, via the Snyk APIs and via the CLI.
If you have access to our Reports feature, you will also be able to see an overview of how many issues in your organization’s projects are ignored, along with an option to filter these so you can drill down into each one. If the issue was ignored in our UI, we include a credit for additional accountability, so you can see who initiated it.