Use Snyk security policies to prioritize fixes more efficiently

Snyk security policies just got a whole lot more powerful with a new action and two new conditions, helping your development and security teams assess risk and focus resources more efficiently.

For developers, the less “noise” the better. Tasked with fixing issues that are simply not important or relevant is a waste of valuable development time and will likely result in creating frustration and mistrust. It will definitely not help developers take more responsibility and ownership for security within an organization.

Security policies can help as they effectively prioritize what issues need to be addressed over others and which issues can be totally ignored until the most critical issues have been tackled. Applied at different stages of the SDLC, policies can also be used to ensure vulnerable or non-compliant components do not slip through the cracks. Policies are part and parcel of the organization’s governance framework and operate in accordance with internally accepted security and compliance standards.

The enhanced rules engine introduced to Snyk’s security policies includes a new Ignore action as well as new conditions (CVE and Snyk ID), providing you with additional governance flexibility and granularity, and helping you to drive more effective prioritization strategies across your organization. 

Ignore vulnerabilities in bulk

A Snyk security policy contains a rule, or a set of rules, that define exactly how security vulnerabilities should be handled. Rules trigger actions based on a condition or a set of conditions. Up until now, these rules supported one action — tweaking the severity for vulnerabilities. Based on a vulnerability’s CWE and/or whether or not it had an exploit, users could change its severity level.

You now have the additional option of completely ignoring specific vulnerabilities. You can do this based on the conditions supported up until now, but also based on the two new conditions we’ve just introduced — CVE and Snyk ID. This is a useful tool to help you clear up your vulnerability backlog in a number of ways.

For example, you can configure a security policy to ignore vulnerabilities without a known exploit:

Using the new CVE condition combined with project attributes, you can also ignore a specific vulnerability you know is not relevant to particular types of application:

And the same applies to ignoring a whole category of vulnerabilities using the CWE condition:

Granular policy management

Projects differ from one another, and will likely warrant different security and compliance boundaries. A project that is mission-critical to the business, for example, requires closer and more stringent control than a project that is internally facing and sandboxed in a test development environment.

Snyk provides the granularity required to decide exactly how to apply policies within the organization. Policies can be applied to a project or group of projects using project tags and attributes — two types of metadata that can be added, either manually or automatically via the Snyk API, to projects, enabling the grouping of projects together based on shared characteristics. Alternatively, policies can be applied to specific organizations within a Snyk group (check out our docs for more information on Snyk’s group, organization, and project hierarchies).

Let’s take a look at an example, this time using Snyk’s license policies.

The legal team of organization X has determined the need for enforcing extremely stringent compliance boundaries on any business-critical frontend services in production. On the other hand, they are less concerned about internal projects that are in development being compliant.

So as a first step, organization X ensures the Critical, Production, and Frontend attributes are added to the relevant projects in Snyk.

Then, as a second step, a new license policy is created. Using the newly added attributes, the policy is assigned to the relevant projects. Within the policy itself, a high severity can be applied to any copyleft license identified in projects, such as the GPL-3.0 and AGPL-3.0 licenses. 

Applied across the SDLC

Once created, Snyk’s security and license policies are applied to all the relevant projects and are enforced across the different stages of the SDLC. This starts as far left as the developer’s local development environment, in the IDE or CLI, continues through Git-based workflows, CI/CD, and onwards into production. These multiple security and compliance gates ensure issues are flagged as early as possible in the development process when it is less costly and time-consuming to fix.

For GitHub projects monitored by Snyk, for example, any new pull request triggered by a contributing developer will be checked against any security and license policy assigned to the project. This way, vulnerable or non-compliant code cannot be committed into the repository, all in accordance with the organization’s internal standards.

In the example below, I am trying to add the fullpage.js package to add fullscreen scrolling to my JavaScript application. While passing the security check (the latest version of the package has no known vulnerability), it has failed the license check because of the GPLv3 license included which violates our license policy.

Clicking on the Details link provides us with more detailed information and context on the failed test:

In the same way, policies take effect in CI/CD, ensuring builds are complying with security and compliance boundaries. In the example below, a GitHub Actions build workflow failed because of a high severity vulnerability identified in Snyk’s testing.

Security and speed are not mutually exclusive

In application security, policies play the critical role of ensuring a balance is struck between fast development on the one hand and staying secure on the other. The exact balance varies from organization to organization, but if deployed correctly, policies ensure development and security teams are operating within the organization’s accepted security and compliance boundaries while also maximizing their productivity. 

But to do this, policies need to…

• be flexible enough to enable granular rules and application of these rules within the organization

• complement development processes and workflows, rather than introduce friction

• enable the effective prioritization of issues to ensure maximum efficiency and security

• offer the individuals or teams that manage them clear visibility into what rules are being applied where

• have sufficient governance in place, so that they can be centrally managed, ensuring compliance.

These are all core capabilities of Snyk’s policies.To find out more about Snyk’s policies and how to use them, take a look at our technical documentation.