The most surprising thing about Snyk ignore policies is that they don’t actually ignore anything; they just tell Snyk to stop reporting on specific vulnerabilities.
Let’s see this in action. Imagine you’ve scanned a project and Snyk found a vulnerability in a dependency you can’t immediately update, but you’ve assessed the risk and decided it’s acceptable for now.
Here’s a package.json file:
{
"name": "my-app",
"version": "1.0.0",
"dependencies": {
"lodash": "4.17.10"
}
}
And here’s the output of snyk test:
Testing /path/to/my-app...
✗ High severity vulnerability found in lodash
Description: Prototype Pollution
Info: https://snyk.io/vuln/npm:lodash:20190313
Introduced through: lodash@4.17.10
From: lodash@4.17.10
Remediation:
// Update to the latest version of lodash
// npm uninstall lodash
// npm install lodash@latest
...
Organization: my-org
Package manager: npm
Project name: my-app
Tested version: 1.0.0
2 vulnerabilities found.
You’ve decided the Prototype Pollution in lodash@4.17.10 is a known-acceptable risk for this specific project because the vulnerable function isn’t called in your application’s execution path. To stop Snyk from flagging this on every scan, you create a .snyk file in the root of your project.
Here’s what that .snyk file would look like to ignore that specific vulnerability:
version: 1.0.0
ignore:
- npm:lodash:20190313
Now, when you run snyk test again:
Testing /path/to/my-app...
...
Organization: my-org
Package manager: npm
Project name: my-app
Tested version: 1.0.0
1 vulnerability found.
Notice how the Prototype Pollution vulnerability is no longer reported. The .snyk file is a YAML document that tells Snyk which vulnerabilities to suppress. The ignore key takes a list of vulnerability IDs. These IDs are typically in the format [package-manager]:[package-name]:[vulnerability-id]. For npm vulnerabilities, the ID is often the Snyk vulnerability identifier (like SNYK-JS-LODASH-101895, but in the .snyk file, it’s commonly represented by the CVE-like identifier or a Snyk-specific identifier which can be found in the vulnerability details on the Snyk website). In this case, npm:lodash:20190313 is a common way to represent it, derived from the vulnerability’s discovery date or a Snyk-specific identifier.
The power of ignore policies lies in their granularity. You can ignore vulnerabilities for an entire project, or more precisely, for a specific dependency path. If lodash@4.17.10 was a transitive dependency, say brought in by another library, you could specify that.
Consider this more complex scenario where lodash is a dependency of express:
{
"name": "my-server",
"version": "1.0.0",
"dependencies": {
"express": "4.16.1"
}
}
Running snyk test might reveal a vulnerability in lodash that express depends on. The .snyk file could then look like this:
version: 1.0.0
ignore:
- id: npm:lodash:20190313 # General ignore for lodash
reason: "Transitive dependency, not directly used in critical path."
expires: "2024-12-31" # Optional expiration date
owner: "your-team-lead@example.com" # Optional owner
- id: npm:some-other-vuln:CVE-2023-1234
path: "express > lodash" # Ignores only when lodash is a dependency of express
reason: "Specific to this integration."
Here, we’ve added reason, expires, owner, and path fields. The path is crucial for targeting transitive dependencies. express > lodash means this ignore rule only applies when lodash is found as a dependency through express. This prevents accidentally ignoring the same lodash vulnerability if it were directly imported by your application with a different path. The reason field is mandatory and encourages good practice by documenting why a vulnerability is being ignored. The expires field is also highly recommended, acting as a reminder to re-evaluate the risk.
When you add an ignore rule, Snyk stores it in the .snyk file (or a separate snyk-policy.yml file if you prefer). This file is typically committed to your version control system, ensuring that the ignore policies are consistent across all environments and for all team members. Snyk also supports managing these policies through its CLI and UI, which can then be exported to a file.
The underlying mechanism is that Snyk maintains a policy file alongside your project’s code. During a scan, Snyk first identifies all potential vulnerabilities. Then, it compares these findings against the rules defined in its policy file. Any vulnerability that matches an ignore rule is filtered out of the final report. This filtering happens after the vulnerability has been detected, meaning Snyk still knows about the vulnerability; it’s just instructed not to surface it in the scan results. This is why, if you remove the .snyk file or update it to remove an ignore rule, the vulnerability will reappear in the next scan.
A common pitfall is using overly broad ignore rules. For example, ignoring all vulnerabilities for a specific package might suppress critical issues that are exploitable. Always use the path or packageManager attributes to scope your ignore rules as narrowly as possible. Another mistake is forgetting to set an expiration date, leading to "stale" ignores that no longer reflect the current risk landscape.
The next step after mastering ignore policies is often understanding how to integrate Snyk’s remediation advice directly into your CI/CD pipeline, possibly using Snyk’s automatic pull request updates.