Ignoring vulnerabilities with Snyk

Ignore a vulnerability? That sounds like a paradox. Why would anyone want to ignore a vulnerability?

While ignoring security issues should not be your default practice, it is still sometimes necessary. Development and security teams today face vulnerability backlogs consisting of thousands of issues. To maintain rapid development, they must be able to effectively prioritize their work.  Which vulnerabilities require immediate attention, which can be tackled at a later time, and which can be totally ignored?

Not all vulnerabilities are equal. Some are critical, while others are of lower severity. Some have an immediate fix available while others don’t. Some vulnerabilities are irrelevant for certain projects (e.g. a denial of service vulnerability in an internal-facing service). These, among other vulnerability characteristics, are valid reasons why you might wish to ignore a vulnerability when triaging.

Security solutions must enable developers to suppress vulnerabilities, but they must also provide security teams with the right degree of control over who ignores what (and why). Again, ignoring a vulnerability is not a best practice, but rather an action that should be taken in moderation and in alignment with your organization’s policies.

Ignoring options in Snyk

The Snyk platform provides various ways to ignore issues — via the Snyk CLI, API, UI, or using the .snyk policy file. The method you use depends on your specific use case, but one principle that is important to understand is that ignores in Snyk are local in nature.  This means they are restricted to a project, integration type, and organization. For example, the same issue that is ignored in a project imported via GitHub will not be ignored in a project imported via the Snyk CLI.

Let’s take a closer look.

Using the Snyk CLI

The Snyk CLI is an extremely useful tool that helps you find and fix vulnerabilities, either manually in your local development environment, or automatically as part of your CI/CD pipeline. You can scan your project using the snyk test command. The scan returns a list of all issues identified in the project, as well as upgrade and fix recommendations if available. 

If you want to ignore a specific vulnerability for any of the reasons described above — either in your local testing or in your build pipelines — you can use the snyk ignore command, which contains optional subcommands (in square brackets). The subcommands help you define the scope of the ignore action: an expiration date for the ignore rule and a reason for the rule. The command below is ignoring an information exposure vulnerability in the hbs npm package because there is no fix available:

1snyk ignore –id=SNYK-JS-HBS-1566555 [--expiry=2022-05-30] [--reason=no fix available]

The id is a unique ID assigned to issues by Snyk. You can locate it in a few places in the Snyk UI – but if you’re using the Snyk CLI, you will see the ID appended to the URL of the issue in the Snyk vulnerability database.

Upon execution of this command, a new rule is added to the .snyk policy file. If the .snyk policy file doesn’t already exist, this command creates the file and adds the rule to it. Any subsequent scans run using snyk test will follow this rule.

Pro tips:

• Not sure about the Snyk CLI syntax for ignoring issues? Just enter snyk ignore –help.

• You can limit the ability to ignore issues to admin users only via your organization’s settings, within the Snyk UI.

• For Snyk Code and unmanaged dependency tests within Snyk Open Source, it may be more useful to ignore directories instead of individual issues. Using snyk ignore supports this functionality as well.

Using the .snyk policy file

As described above, the snyk ignore command creates a new file called the .snyk policy file. This file is generally used to configure the behavior and scope of the snyk test and snyk monitor CLI commands, as well as tests executed via the Snyk API and Snyk UI and language settings. You can also manually create the .snyk policy file within the project’s root directory, or within a specific directory inside the project.

For ignoring vulnerabilities, the file needs to include a header:

1# Snyk (https://snyk.io) policy file, patches or ignores known vulnerabilities.
2 version: v1.22.1

It also needs to include the following YAML syntax for each ignore rule:

1Ignore:
2  snyk-vulnid:
3    - path to library using > seperator :
4      reason: 'text string'
5      expires: 'datetime string'

Be aware that if the .snyk policy file is stored within a sub-directory in your project, you will need to specify its location when you execute the snyk ignore command in the Snyk CLI.

As a best practice, we recommend managing the .snyk file with Git. This ensures that testing executed via the Snyk UI complies with the rules that are set locally. For additional information on the .snyk policy file, how to create it, and how to use it for ignoring vulnerabilities, refer to our .snyk policy file documentation.

Using the Snyk UI

Ignores can also be applied using the Snyk UI: just click the Ignore button on any issue card. This opens up a dialog where you can select the reason for the ignore and specify how long you want the issue ignored. (You can even decide to ignore an issue until a fix becomes available.)

After you apply the Ignore option to an issue via the Snyk UI, a few things happen — but it's important thing to remember that the issue itself does not disappear. Don’t worry if you just ignored a critical vulnerability!

The issue will not appear, but by default, you can still view it on the project’s page by using the Ignored filter. Importantly, any ignore action done via the Snyk UI is recorded (including information about who ignored the issue, when they did it, and why):

1Ignore:
2  snyk-vulnid:
3    - path to library using > seperator :
4      reason: 'text string'
5      expires: 'datetime string'

Pro tips:

• Ignores applied via the Snyk UI to projects imported into Snyk via the Snyk CLI (using snyk monitor) are synced with your local project. However, ignores applied via the Snyk UI to projects imported into Snyk via a Source Control Management (SCM) integration (e.g GitHub, Bitbucket) are not.

• You can require a reason for each ignore action executed via the Snyk UI from within your organization’s settings.

Using security policies (Snyk Open Source and Snyk Container only)

For most organizations, a more automated way of ignoring issues at scale is important.

Snyk’s security policies are, essentially, rules you can use to automatically prioritize or deprioritize issues. They are defined on the group level via the Policies tab on the navigation bar in the Snyk UI, and can be applied to either specific organizations or specific projects (using the Project Attributes option). This gives you granular control over how to apply your ignore rules.

Ignoring issues using Snyk’s security policies is done by first defining the conditions that must exist for Snyk to ignore an issue, then selecting the ignore option.

Ignores applied with a security policy will ignore all vulnerabilities that match the conditions specified in the rule. They will ignore all existing vulnerabilities that match the conditions, and all future instances of it that are identified. Issues ignored via a security policy will be marked as such.

This directory traversal vulnerability in the popular Python Django package, for example, was ignored by a policy set in place for internal projects:

Pro tip: When setting the Ignore action in a security policy, you can select Won't fix and Not vulnerable as ignore types, and add the reason you want displayed for the ignore action. This information appears on the issue card in your project.

Using the Snyk API

You can use the Snyk API to apply more global ignore rules. We recommend using this with extreme caution, as this approach could produce false negatives further down your testing road.

A path-based ignore rule using the Snyk API will look something like this:

1POST https://snyk.io/api/v1/org/orgId/project/projectId/ignore/issueId

The API payload would look something like this:

1{ 
2“ignorePath”:””,
3“Reason”:”no fix available”,
4“reasonType”:”wont-fix”,
5“disregardIfFixable”:true
6}

You can also use the API to create a list of ignored issues. This is recommended for keeping track of global ignores across the organization:

1https://snyk.io/api/v1/org/orgId/project/projectId/ignores

Additional best practices for ignores

The Snyk platform provides various options for using ignores in a measured way, with a degree of control to ensure that critical issues don’t slip under the radar. Below are some best practices for working with these methods.

Require reasons for ignores

We recommend requiring that your developers provide reasons for using ignores. As mentioned above, admins can set this requirement for ignores applied via the Snyk UI. For ignores applied from the Snyk CLI or API, you need to instruct your development teams to follow this practice.

Limit ignores to the admin role

We recommend enabling the option to use ignores for each of your organizations in Snyk. (This permission can also be set via the Snyk UI.) Note, however,  that this only limits ignores executed in the Snyk CLI and Snyk API. Developers will still be able to set ignore rules in the .snyk policy file.

Review ignores on a regular basis

For an additional layer of visibility, regularly monitor the ignores executed in your Snyk account by your different teams. To do this, you can use the curl command shown above to automatically pull and review a list of issues ignored. You can also refer to the Reports tab, where Snyk shows the number of issues ignored

Ignore with caution

Ignoring a security issue, or a license issue for that matter, should always be an exception to the rule rather than a widespread practice. Set the right balance between developer productivity and security measures by carefully defining the accepted ignore policy in your organization and giving developers the tools that enable them to ignore issues within your guardrails.

Let’s review a few points on how ignores are handled in Snyk Code and Snyk Infrastructure as Code (Snyk IaC):

• Ignoring Snyk Code issues via the Snyk UI might capture a wider range of issues compared to Snyk’s other products. To understand why, please refer to our documentation. Our Secure coding with Snyk Code: Ignore functionality with a twist blog post dives deeper into ignoring with Snyk Code.

• There are some semantics to consider when using the .snyk policy file to ignore issues identified by Snyk Infrastructure as Code, such as narrowing the scope to a single file. More information is available in our Improve security by knowing when to ignore IaC vulnerabilities blog and in our documentation.

Happy ignoring!