Mejora la seguridad al saber cuándo ignorar vulnerabilidades de IaC

Cuando se trata de vulnerabilidades de seguridad, a menudo se adopta un enfoque de «hay que detectarlas todas» para generar alertas. Aunque en teoría parece una buena idea, en la práctica no lo es tanto: suele hacer perder tiempo y esfuerzo a los equipos de seguridad y desarrollo. El enfoque más eficaz consiste en analizar y distinguir los problemas relevantes de los irrelevantes para tu organización y, después, ignorar estos últimos. Así, tus equipos pueden enfocarse en lo crítico y mejorar la seguridad general de tus aplicaciones.

Además de ayudar a quienes escriben infraestructura como código (IaC) a encontrar problemas de seguridad en sus bases de código de Terraform, Kubernetes y CloudFormation, Snyk Infrastructure as Code (Snyk IaC) ahora te permite ignorar vulnerabilidades de IaC que no son relevantes para ti cuando ejecutas snyk iac test. En este blog, repasaré algunos casos en los que quizá quieras ignorar un problema después de analizar tus archivos de configuración de IaC y te mostraré cómo funciona.

Cómo configurar Snyk para ignorar vulnerabilidades de IaC

La seguridad debe formar parte del ciclo iterativo de desarrollo de software, no considerarse por separado ni «al final». La CLI de Snyk suele usarse como parte del ciclo de desarrollo y en los pipelines de CI para detectar problemas de seguridad de forma temprana y frecuente. Nuestra CLI es común a todos los productos, así que, si ya la usas para probar dependencias de código abierto o contenedores, quizá ya sepas cómo ignorar problemas detectados en esas pruebas mediante el archivo de políticas .snyk. Snyk IaC también usa ahora el archivo de políticas .snyk para que puedas ignorar problemas de IaC de forma fácil y automática.

Hay varias razones por las que quienes escriben IaC podrían querer ignorar problemas. Por ejemplo, quizá no se aplique a tu caso una regla de seguridad que impide que un bucket de S3 esté abierto a Internet público si usas ese bucket intencionalmente para alojar artefactos públicos. ¡Es difícil crear reglas de seguridad que sirvan para todos! Veamos este ejemplo.

Un ejemplo sencillo de cómo ignorar un problema

Aquí tenemos un archivo de configuración de Terraform que declara dos buckets de 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}

Si ejecutamos snyk iac test en un directorio que contiene este archivo, aparecen algunos problemas. Entre ellos hay dos casos del problema «lectura pública» en el que nos enfocamos. Este es un fragmento de la salida con algunos datos ocultos:

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 el problema con la CLI de Snyk ejecutando snyk ignore --id=SNYK-CC-TF-18 --reason=’Blog bucket should be open. Esto genera un archivo de políticas .snyk (si aún no existe) con el siguiente contenido:

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 el motivo y la fecha de vencimiento, o eliminarla por completo, según corresponda. Para obtener más información, consulta la documentación sobre la funcionalidad para ignorar problemas de Snyk y el archivo de políticas .snyk.

Si volvemos a ejecutar snyk iac test, veremos que los problemas de «lectura pública» ya no aparecen.

Definir el alcance de los problemas ignorados

Sin embargo, si revisamos el motivo que indicamos para ignorar este problema —que el bucket blog debe estar abierto—, vemos que aún no terminamos. Queremos limitar más el alcance de esta regla para ignorar el problema, de modo que siga apareciendo el problema del bucket de artefactos. Empecemos por cambiar la regla *, que significa «ignorar todos los casos de este problema», por una ruta de archivo relativa a la raíz del proyecto:

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

De esta manera, podemos limitar las reglas para ignorar problemas a archivos específicos. Sin embargo, en este ejemplo hay dos casos del problema «bucket con lectura pública» en el mismo archivo. Copiemos la ruta de configuración del problema del bucket blog en lugar del * 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

Si volvemos a ejecutar snyk iac test, veremos que ignoramos correctamente el caso de la vulnerabilidad «bucket con lectura pública» en nuestro bucket blog, mientras que el mismo problema sigue apareciendo en el bucket de artefactos, lo que indica que debemos corregirlo.

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

Cambiemos la ACL del bucket de artefactos:

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}

Al ejecutar snyk iac test, ya no aparecerá ningún caso del problema «bucket con lectura pública», que es lo que queremos en este ejemplo. Después, puedes confirmar el archivo de políticas .snyk en tu repositorio de código para mantener estas reglas bajo control de versiones.

Empieza a usar Snyk IaC

Puedes empezar a usar esta funcionalidad ahora mismo descargando la versión más reciente de Snyk CLI. También puedes consultar nuestra documentación para ver una explicación paso a paso de cómo Snyk IaC ignora problemas mediante el archivo .snyk.