Gérer ses vulnérabilités sur AWS sans se noyer

Scanner son cloud, c'est facile. AWS vous donne les outils en quelques clics. Le vrai piège, c'est ce qui arrive juste après : un tableau de bord qui affiche 4 000 vulnérabilités, aucune hiérarchie claire, et une équipe qui, au bout de deux semaines, apprend à ne plus regarder. Une liste que personne ne traite est pire qu'une absence de scan : elle donne l'illusion du contrôle.

L'enjeu de la gestion de vulnérabilités sur AWS n'est donc pas de trouver des failles. C'est de trouver les bonnes, dans l'ordre, et de les corriger avant qu'elles ne comptent. Voici la méthode que j'applique, étape par étape.

Le contexte : pourquoi le cloud change la donne

Dans un parc classique, vous aviez quelques dizaines de serveurs que vous connaissiez par leur prénom. Sur AWS, votre périmètre respire : des instances EC2 (Elastic Compute Cloud) montent et descendent à la demande, des conteneurs naissent et meurent en quelques secondes, des fonctions Lambda s'exécutent sans serveur visible. La question « qu'est-ce que je dois scanner ? » n'a plus de réponse fixe.

Conséquence directe : un scan ponctuel, lancé une fois par trimestre, ne veut plus rien dire. Quand vous lisez son rapport, la moitié des machines analysées n'existent déjà plus, et de nouvelles sont apparues sans être vues. La couverture doit devenir continue, ou elle est mensongère.

C'est le premier principe que pose la fiche de référence AWS sur la gestion de vulnérabilités : privilégier une évaluation continue, sans agent, native au cloud, plutôt qu'un audit photo à un instant T. On ne déploie pas un agent sur chaque ressource éphémère ; on branche le scan sur les services qui voient passer tout ce qui se crée.

La mécanique : où regarder, dans l'ordre

Sur AWS, trois couches concentrent l'essentiel du risque, et il faut les couvrir distinctement.

La première couche, ce sont les images de conteneurs. C'est là que la dette de vulnérabilités s'accumule le plus vite, parce qu'une image embarque des dizaines de dépendances figées au moment du build. Le bon réflexe est de scanner à la poussée dans le registre ECR, pour qu'une image vulnérable soit détectée au moment où elle entre, pas trois mois plus tard en production.

La deuxième, ce sont les charges de calcul : les instances EC2 et les fonctions Lambda. AWS Inspector sait les évaluer en continu, sans agent à maintenir, en s'appuyant sur l'inventaire que le cloud connaît déjà de lui-même.

La troisième, transversale, c'est la corrélation. Une vulnérabilité seule ne dit pas grand-chose. La même faille sur une machine isolée sans accès réseau et sur une machine exposée à Internet avec un rôle surpuissant, ce ne sont pas le même problème. C'est exactement le point que souligne la fiche AWS : il faut corréler la vulnérabilité avec son contexte — exposition réseau, privilèges associés, sensibilité de la donnée — pour passer d'une liste à une hiérarchie.

Le code : activer la couverture continue

Concrètement, voilà de quoi mettre en place la base. On active le scan d'images à la poussée sur ECR, puis Inspector sur le compte. Les commandes sont volontairement minimales ; l'idée est de montrer le geste, pas de remplacer votre IaC (Infrastructure as Code).

aws ecr put-image-scanning-configuration \
    --repository-name mon-app \
    --image-scanning-configuration scanOnPush=true        # scan à chaque push d'image
 
aws inspector2 enable --resource-types EC2 ECR LAMBDA     # évaluation continue, sans agent
 
aws inspector2 list-findings \
    --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}'   # critiques only

La troisième commande est la plus importante, et c'est celle qu'on oublie. Ne tirez jamais « toutes » les vulnérabilités dans votre processus de traitement. Filtrez à la source sur ce qui est à la fois critique et réellement exploitable dans votre contexte. Le reste va dans un catalogue de suivi, pas dans la file d'attente de l'équipe.

Pour la corrélation avec les privilèges, le principe défensif reste le moindre privilège sur les rôles attachés aux ressources. Un rôle d'instance qui ne peut faire qu'une chose limite drastiquement ce qu'une vulnérabilité exploitée permet ensuite :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::mon-bucket-precis/*"
  }]
}

Une faille sur une machine portant ce rôle donne accès à un seul préfixe d'un seul bucket. La même faille sur une machine au rôle large donne accès à tout. La vulnérabilité est identique ; l'impact n'a rien à voir. C'est ça, prioriser par le contexte.

Le fix : du scan à la décision

La correction technique d'une faille (mettre à jour un paquet, reconstruire une image) est rarement le point dur. Le point dur, c'est la décision : laquelle, quand, par qui.

Première règle : industrialiser le catalogue. Tenir une liste à jour des vulnérabilités connues sur votre parc, avec leur statut, pour ne jamais retraiter deux fois la même et pour mesurer si la dette monte ou descend. Sans cette mémoire, chaque scan repart de zéro et l'équipe a l'impression de vider l'océan à la petite cuillère.

Deuxième règle : couper le robinet en amont. Le scan à la poussée sur ECR sert à ça : une image trop vulnérable ne devrait pas pouvoir être promue en production. C'est plus efficace que de courir après les failles une fois déployées. On corrige au build, là où c'est dix fois moins cher qu'en prod. C'est exactement la mécanique qu'on industrialise dans le Bootcamp DevSecOps — intégrer la sécurité dans la chaîne CI/CD, pas la coller à la fin.

Troisième règle : garder un œil humain. L'automatisation trie et priorise, mais la fiche AWS le rappelle justement — il faut conduire des évaluations périodiques et des tests d'intrusion. Un scanner trouve les vulnérabilités connues ; il ne trouve pas la logique métier cassée, l'enchaînement de petites faiblesses, l'accès oublié. C'est là que l'audit manuel reprend la main.

Les limites : ce qu'un scanner ne verra jamais

Soyons honnêtes sur la portée de tout ça. Un programme de gestion de vulnérabilités, même bien réglé, couvre une catégorie de risque : les failles connues, cataloguées, dans des composants identifiables. C'est nécessaire, ce n'est pas suffisant.

Il ne verra pas une IDOR (Insecure Direct Object Reference) dans votre API, parce que c'est votre logique d'autorisation, pas un CVE. Il ne verra pas un secret en clair dans un bundle JavaScript servi au navigateur. Il ne verra pas un enchaînement où trois réglages anodins, mis bout à bout, ouvrent un chemin vers vos données. Confondre « zéro vulnérabilité critique au scanner » avec « sécurisé » est une erreur de débutant qui coûte cher à des équipes expérimentées.

Le scanner est un filet à grosses mailles : il attrape l'évident à grande échelle, et il vous fait gagner du temps. Ce temps, réinvestissez-le là où la machine est aveugle — la revue d'architecture, le test d'intrusion ciblé, la logique métier. C'est précisément l'angle du Bootcamp Cloud Security : aller chercher ce que le scanner laisse passer.

Mettre le programme en place sans tout casser

Sur le papier, tout cela paraît simple. En pratique, la plupart des équipes échouent non pas sur la technique, mais sur la conduite du changement. Voici l'ordre que je conseille pour démarrer sans braquer les développeurs ni noyer l'équipe sécurité.

Commencez en mode observation, pas en mode blocage. Activez le scan à la poussée sur ECR et Inspector, mais sans rien casser dans la chaîne de livraison au début. Pendant deux ou trois semaines, vous ne faites que mesurer : combien de findings critiques par jour, sur quels services, avec quelle exposition. Vous découvrez votre dette réelle au lieu de la deviner.

Définissez ensuite un seuil de blocage explicite, et un seul. La tentation est de tout bloquer dès le premier scan ; le résultat garanti, c'est une équipe de dev en colère qui trouve comment contourner le contrôle en 48 heures. Bloquez d'abord sur un critère étroit et défendable — par exemple : une image avec une vulnérabilité critique exploitable et accessible publiquement ne part pas en production. Ce seuil-là, personne ne peut sérieusement le contester. Vous le durcirez progressivement, une fois la confiance installée.

Attribuez chaque finding à un propriétaire, pas à une boîte mail. Une vulnérabilité qui n'a pas de nom de responsable en face ne sera jamais corrigée ; elle deviendra un élément de plus dans un tableau que tout le monde regarde et que personne ne traite. Le cloud aide ici : les ressources portent des tags, et un bon tag d'équipe sur chaque ressource fait d'un finding anonyme un ticket adressé à la bonne personne.

Enfin, mesurez une seule chose au début : le délai moyen entre la détection d'une vulnérabilité critique et sa correction. Pas le nombre de vulnérabilités, qui ne fait que refléter la taille de votre parc. Ce délai, lui, raconte si votre programme fonctionne vraiment. S'il baisse, vous progressez. S'il stagne malgré les efforts, c'est que le problème n'est pas l'outil, mais le processus humain autour.

Ce qu'il faut retenir

Gérer ses vulnérabilités sur AWS, ce n'est pas scanner plus. C'est scanner en continu, prioriser par le contexte, et couper le mal à la source dans la chaîne de build. Activez l'évaluation continue, filtrez le bruit pour ne traiter que le critique exploitable, attachez des rôles au plus juste pour que chaque faille pèse le moins lourd possible, et gardez un audit humain pour tout ce que le scanner ne peut pas voir.

La maturité, sur ce sujet, ne se mesure pas au nombre de vulnérabilités trouvées. Elle se mesure à la vitesse à laquelle les bonnes sont corrigées — et au calme avec lequel votre équipe regarde le tableau de bord au lieu de le fuir.