Improve security by knowing when to ignore IaC vulnerabilities

In the context of security vulnerabilities, there’s often a “gotta catch them all” approach to alerting. While this approach seems good in theory, it's less good in practice, often costing security and developer teams time and wasted effort. The effective approach is analyzing and differentiating between relevant and irrelevant issues for your organization and then ignoring the irrelevant issues. This allows your teams to focus on the critical and improve the overall security of your applications.

In addition to helping infrastructure as code (IaC) authors find security issues in their Terraform, Kubernetes, and CloudFormation codebases, Snyk Infrastructure as Code (Snyk IaC) now allows you to ignore IaC vulnerabilities that aren't relevant to you when you run snyk iac test. In this blog, I’ll break down a few instances where you may want to ignore an issue after scanning your IaC configuration files and show you how it works.

How to configure Snyk to ignore IaC vulnerabilities

Security should be part of the iterative software development lifecycle, not something to be considered separately or “at the end”. The Snyk CLI is often used as part of the development loop as well as in CI pipelines, to check for security issues early and often. Our CLI is shared across all products, so if you’re familiar with using the Snyk CLI for testing open source dependencies or containers, you may already know about ignoring issues from those tests by using the .snyk policy file. Snyk IaC now also uses the .snyk policy file to enable you to easily and automatically ignore IaC issues.

There are various reasons IaC authors might want to ignore issues. For example, a security rule set for an S3 bucket being open to the public internet might not be applicable to you if you are intentionally using that bucket to host public artifacts. It’s hard to create one-size-fits-all security rules! Let’s walk through this example.

A simple ignore example

Here we have a Terraform configuration file that declares a pair of S3 buckets:

1resource "aws_s3_bucket" "blog" {
2  bucket = "blog"
3  acl = "public-read"
4}
5
6resource "aws_s3_bucket" "artifacts" {
7  bucket = "artifacts"
8  acl = "public-read"
9}

Running snyk iac test in a directory that contains this file yields some issues. Among them are 2 instances of the “publicly readable” issue we are focusing on. Some partially redacted output:

1$ snyk iac test
2
3Testing terraform/s3/s3_cis.tf...
4
5Infrastructure as code issues:
6  ...
7
8  ✗ S3 Bucket is publicly readable [Medium Severity] [SNYK-CC-TF-18] in S3
9    introduced by input > resource > aws_s3_bucket[blog] > acl
10
11  ✗ S3 Bucket is publicly readable [Medium Severity] [SNYK-CC-TF-18] in S3
12    introduced by input > resource > aws_s3_bucket[artifacts] > acl
13
14...
15
16Tested terraform/s3/s3_cis.tf for known issues, found 10 issues

We can ignore the issue using the Snyk CLI by running snyk ignore --id=SNYK-CC-TF-18 --reason=’Blog bucket should be open. This generates a .snyk policy file (if it doesn’t already exist) with the following contents:

1    # Snyk (https://snyk.io) policy file, patches or ignores known       vulnerabilities.
2version: v1.22.0
3    # ignores vulnerabilities until expiry date; change duration by modifying expiry date
4ignore:
5  SNYK-CC-TF-18:
6    - '*':
7        reason: Blog bucket should be open
8        expires: 2021-09-17T10:57:56.635Z
9        created: 2021-08-18T10:57:56.637Z
10patch: {}

We can edit the reason and expiry, or remove the expiry altogether, as appropriate. To learn more, check out our Snyk ignore functionality and .snyk policy file documentation.

Re-running snyk iac test, we can see that the “publicly readable” issues are now not present.

Setting a scope for ignored issues

However, looking at our own stated reason for ignoring this issue, that the blog bucket should be open, we see that we have not quite finished. We want to scope this ignore rule more narrowly, so that the issue with the artifacts bucket is still surfaced. Let’s start by changing the * rule, which means “ignore all instances of this issue”, to a file path, relative to the root of the project:

1ignore:
2  SNYK-CC-TF-18:
3    - 'terraform/s3/s3_cis.tf > *':
4        reason: Blog bucket should be open
5        expires: 2021-09-17T10:57:56.635Z
6        created: 2021-08-18T10:57:56.637Z

In this way, we can scope ignore rules to individual files. However, in this particular example, we have these 2 instances of the “publicly readable bucket” issue in the same file. Let’s paste the configuration path of the blog bucket’s issue into the place of the remaining *:

1ignore:
2  SNYK-CC-TF-18:
3    - 'terraform/s3/s3_cis.tf > input > resource > aws_s3_bucket[blog] > acl':
4        reason: Blog bucket should be open
5        expires: 2021-09-17T10:57:56.635Z
6        created: 2021-08-18T10:57:56.637Z

Re-running snyk iac test, we can see that we are successfully ignoring the instance of the “publicly readable bucket” vulnerability for our blog bucket, while leaving the instance of the same issue on the artifacts bucket — indicating that we should fix it!

1$ snyk iac test
2
3Testing terraform/s3/s3_cis.tf...
4
5Infrastructure as code issues:
6  ...
7
8  ✗ S3 Bucket is publicly readable [Medium Severity] [SNYK-CC-TF-18] in S3
9    introduced by input > resource > aws_s3_bucket[artifacts] > acl
10
11...
12
13Tested terraform/s3/s3_cis.tf for known issues, found 9 issues

Let’s change the artifacts bucket’s ACL:

1resource "aws_s3_bucket" "blog" {
2  bucket = "blog"
3  acl = "public-read"
4}
5
6resource "aws_s3_bucket" "artifacts" {
7  bucket = "artifacts"
8  acl = "private"
9}

Running snyk iac test will now show no instances of the “publicly readable bucket” issue — which is what we want in this example. You can then commit the .snyk policy file to your code repository in order to version control these rules.

Get started with Snyk IaC

You can start using this functionality right now by downloading the latest Snyk CLI. Or review our documentation for a step-by-step breakdown of how Snyk IaC ignores using the .snyk file.