Reforce a segurança sabendo quando ignorar vulnerabilidades de IaC

Quando se trata de vulnerabilidades de segurança, é comum adotar a abordagem de “pegar todos”. Embora pareça uma boa ideia na teoria, na prática ela nem sempre funciona e muitas vezes consome tempo e esforço de equipes de segurança e desenvolvimento. A abordagem eficaz é analisar e distinguir os problemas relevantes dos irrelevantes para a sua organização e, então, ignorar os que não são relevantes. Assim, suas equipes podem se concentrar no que é crítico e melhorar a segurança geral dos seus aplicativos.

Além de ajudar quem escreve infraestrutura como código (IaC) a encontrar problemas de segurança em bases de código Terraform, Kubernetes e CloudFormation, o Snyk Infrastructure as Code (Snyk IaC) agora permite ignorar vulnerabilidades de IaC que não são relevantes para você ao executar snyk iac test. Neste artigo, vou apresentar algumas situações em que você pode querer ignorar um problema após analisar seus arquivos de configuração de IaC e mostrar como fazer isso.

Como configurar o Snyk para ignorar vulnerabilidades de IaC

A segurança deve fazer parte do ciclo iterativo de desenvolvimento de software, e não ser tratada separadamente ou “no final”. A CLI do Snyk é usada com frequência no ciclo de desenvolvimento e em pipelines de CI para verificar problemas de segurança desde o início e continuamente. Nossa CLI é compartilhada por todos os produtos. Então, se você já usou a CLI do Snyk para testar dependências de código aberto ou contêineres, talvez conheça a opção de ignorar problemas encontrados nesses testes usando o arquivo de políticas .snyk. O Snyk IaC também usa o arquivo de políticas .snyk, permitindo ignorar problemas de IaC com facilidade e de forma automática.

Há vários motivos para quem escreve IaC querer ignorar problemas. Por exemplo, uma regra de segurança que impede que um bucket do S3 fique aberto à internet pública pode não se aplicar ao seu caso se você usa esse bucket intencionalmente para hospedar artefatos públicos. É difícil criar regras de segurança que sirvam para todos! Vamos ver esse exemplo.

Um exemplo simples de como ignorar um problema

Aqui temos um arquivo de configuração do Terraform que declara dois buckets do S3:

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}

Ao executar snyk iac test em um diretório que contém esse arquivo, encontramos alguns problemas. Entre eles estão duas ocorrências do problema “legível publicamente” que estamos analisando. Veja uma parte da saída, com alguns dados ocultados:

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

Podemos ignorar o problema usando a CLI do Snyk com o comando snyk ignore --id=SNYK-CC-TF-18 --reason=’Blog bucket should be open. Isso gera um arquivo de políticas .snyk (se ele ainda não existir) com o seguinte conteúdo:

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: {}

Podemos editar o motivo e a data de expiração ou remover a data de expiração, se for o caso. Para saber mais, consulte a documentação sobre a funcionalidade de ignorar problemas do Snyk e o arquivo de políticas .snyk.

Ao executar snyk iac test novamente, vemos que os problemas de “legível publicamente” não aparecem mais.

Defina o escopo dos problemas ignorados

No entanto, ao analisar o motivo que informamos para ignorar esse problema — o bucket blog deve ficar aberto —, vemos que ainda falta um ajuste. Queremos restringir o escopo dessa regra para que o problema do bucket de artefatos continue sendo exibido. Para começar, vamos substituir a regra *, que significa “ignorar todas as ocorrências deste problema”, pelo caminho de um arquivo, relativo à raiz do projeto:

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

Assim, podemos restringir as regras de ignorar problemas a arquivos específicos. No entanto, neste exemplo, há duas ocorrências do problema “bucket legível publicamente” no mesmo arquivo. Vamos colar o caminho de configuração do problema no bucket blog no lugar do * restante:

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

Ao executar snyk iac test novamente, vemos que a ocorrência da vulnerabilidade “bucket legível publicamente” no nosso bucket blog foi ignorada, enquanto a mesma ocorrência no bucket de artefatos continua aparecendo — um sinal de que precisamos corrigi-la!

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

Vamos alterar a ACL do bucket de artefatos:

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}

Agora, ao executar snyk iac test, não haverá ocorrências do problema “bucket legível publicamente” — que é o resultado desejado neste exemplo. Depois, você pode enviar o arquivo de políticas .snyk para o repositório do seu código e manter essas regras sob controle de versão.

Comece a usar o Snyk IaC

Você já pode começar a usar essa funcionalidade: baixe a versão mais recente da CLI do Snyk. Ou consulte nossa documentação para ver o passo a passo de como o Snyk IaC ignora problemas usando o arquivo .snyk.