Renforcez la sécurité en sachant quand ignorer les vulnérabilités IaC

Face aux vulnérabilités de sécurité, on adopte souvent une approche du type « il faut toutes les détecter ». Si cette approche semble bonne en théorie, elle l’est moins en pratique : elle fait souvent perdre du temps et de l’énergie aux équipes de sécurité et de développement. Pour être efficace, il faut analyser les problèmes et distinguer ceux qui sont pertinents pour votre organisation de ceux qui ne le sont pas, puis ignorer ces derniers. Vos équipes peuvent ainsi se concentrer sur les problèmes critiques et améliorer la sécurité globale de vos applications.

En plus d’aider les auteurs d’infrastructure as code (IaC) à repérer les problèmes de sécurité dans leurs bases de code Terraform, Kubernetes et CloudFormation, Snyk Infrastructure as Code (Snyk IaC) vous permet désormais d’ignorer les vulnérabilités IaC qui ne vous concernent pas lorsque vous exécutez snyk iac test. Dans cet article, je vais vous présenter quelques cas où vous pourriez vouloir ignorer un problème après l’analyse de vos fichiers de configuration IaC et vous montrer comment procéder.

Comment configurer Snyk pour ignorer les vulnérabilités IaC

La sécurité doit faire partie du cycle de développement logiciel itératif, et non être traitée séparément ou « à la fin ». La CLI Snyk est souvent utilisée au fil du développement, ainsi que dans les pipelines CI, pour détecter les problèmes de sécurité le plus tôt et le plus souvent possible. Notre CLI est commune à tous nos produits. Si vous savez déjà l’utiliser pour tester des dépendances open source ou des conteneurs, vous connaissez peut-être la possibilité d’ignorer des problèmes détectés lors de ces tests à l’aide du fichier de règles .snyk. Snyk IaC utilise désormais lui aussi le fichier de règles .snyk, afin de vous permettre d’ignorer facilement et automatiquement les problèmes IaC.

Les auteurs IaC peuvent vouloir ignorer des problèmes pour différentes raisons. Par exemple, une règle de sécurité interdisant l’accès public à un compartiment S3 peut ne pas s’appliquer à votre cas si vous utilisez volontairement ce compartiment pour héberger des artefacts publics. Il est difficile de définir des règles de sécurité universelles ! Voyons cet exemple.

Exemple simple d’ignorance d’un problème

Voici un fichier de configuration Terraform qui déclare deux compartiments 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}

L’exécution de snyk iac test dans un répertoire contenant ce fichier fait apparaître plusieurs problèmes. Parmi eux, deux occurrences du problème « accessible en lecture au public » qui nous intéresse ici. Voici un extrait de la sortie, partiellement masqué :

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

Nous pouvons ignorer le problème avec la CLI Snyk en exécutant snyk ignore --id=SNYK-CC-TF-18 --reason=’Blog bucket should be open. Cette commande génère un fichier de règles .snyk (s’il n’existe pas déjà) contenant :

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

Vous pouvez modifier le motif et la date d’expiration, ou supprimer entièrement cette dernière, selon vos besoins. Pour en savoir plus, consultez la documentation sur la fonctionnalité d’ignorance de Snyk et le fichier de règles .snyk.

En exécutant de nouveau snyk iac test, nous constatons que les problèmes « accessible en lecture au public » ne sont plus présents.

Définir la portée des problèmes ignorés

Cependant, si nous examinons le motif que nous avons indiqué pour ignorer ce problème — le compartiment blog doit être accessible —, nous constatons que nous n’avons pas tout à fait terminé. Nous voulons limiter davantage la portée de cette règle d’ignorance afin que le problème du compartiment des artefacts continue d’apparaître. Commençons par remplacer la règle *, qui signifie « ignorer toutes les occurrences de ce problème », par un chemin de fichier relatif à la racine du projet :

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

Nous pouvons ainsi limiter les règles d’ignorance à des fichiers individuels. Mais dans cet exemple précis, les deux occurrences du problème « compartiment accessible en lecture au public » se trouvent dans le même fichier. Collons le chemin de configuration du problème du compartiment blog à la place du * restant :

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

En exécutant de nouveau snyk iac test, nous constatons que nous ignorons bien la vulnérabilité « compartiment accessible en lecture au public » pour notre compartiment blog, tout en laissant apparaître la même occurrence sur le compartiment des artefacts — ce qui indique que nous devons la corriger !

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

Modifions l’ACL du compartiment des artefacts :

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}

L’exécution de snyk iac test ne signalera alors plus aucune occurrence du problème « compartiment accessible en lecture au public », comme souhaité dans cet exemple. Vous pouvez ensuite ajouter le fichier de règles .snyk à votre dépôt de code afin de versionner ces règles.

Premiers pas avec Snyk IaC

Vous pouvez dès maintenant utiliser cette fonctionnalité en téléchargeant la dernière version de la CLI Snyk. Vous pouvez aussi consulter notre documentation pour suivre les étapes permettant à Snyk IaC d’ignorer des problèmes à l’aide du fichier .snyk.