Conteneurs, cloud et outillage
Résumé : cette leçon fait le tour des familles d'outils — SAST, DAST, SCA, scan d'images, analyse d'infrastructure as code, CSPM — en expliquant ce que chacune détecte et ce qu'elle ne peut pas détecter. Puis elle traite le durcissement des conteneurs et le modèle de responsabilité partagée du cloud, deux sujets où les erreurs sont fréquentes et coûteuses.
1. Les familles d'outils
S'il faut n'en activer qu'un, activez le SCA. C'est celui qui couvre le vecteur d'attaque le plus fréquent, qui produit le moins de faux positifs, et qui se met en place en quinze minutes. Le SAST, plus bruyant, viendra ensuite.
Le point 6 mérite d'être compris, car il complète le point 5 de façon indispensable. L'analyse d'infrastructure as code vérifie votre code. Le CSPM vérifie la réalité. Or les deux divergent toujours : quelqu'un a modifié un paramètre manuellement pendant un incident, et ne l'a jamais remis en état. C'est ce qu'on appelle la dérive, et seul le CSPM la détecte.
2. SAST contre DAST — la comparaison
| Critère | SAST | DAST |
|---|---|---|
| Quand | Dès l'écriture du code | Application déployée requise |
| Vision | Boîte blanche (voit le code) | Boîte noire (voit l'extérieur) |
| Trouve | Motifs de code dangereux | Vulnérabilités réellement atteignables |
| Faux positifs | Nombreux | Peu |
| Faux négatifs | Peu sur ce qu'il connaît | Nombreux (ne couvre que ce qu'il atteint) |
| Indique la ligne fautive | Oui | Non |
| Couvre la configuration | Non | Oui |
| Vitesse | Secondes à minutes | Minutes à heures |
La complémentarité est réelle et pas seulement théorique. Le SAST vous dit « ligne 84, cette requête est construite par concaténation » — précis et immédiatement actionnable. Le DAST vous dit « j'ai réussi à extraire des données via le champ de recherche » — moins précis mais prouvé exploitable.
Il existe aussi l'IAST, une approche hybride qui instrumente l'application pendant les tests fonctionnels pour observer son comportement interne. Moins répandue, mais elle réduit fortement les faux positifs du SAST.
3. Sécuriser les images de conteneurs
Le point 2 est le plus important, et le plus souvent négligé. Par défaut, un conteneur s'exécute en tant que root. Si un attaquant compromet votre application puis parvient à s'échapper du conteneur — ce qui reste rare mais s'est produit — il obtient des droits élevés sur la machine hôte. Ajouter un utilisateur dédié prend deux lignes dans un Dockerfile.
Le point 1 est le plus efficace en volume. Passer d'une image de base complète à une variante légère peut faire passer le nombre de vulnérabilités signalées de plusieurs centaines à quelques unités. Vous n'avez rien corrigé — vous avez simplement supprimé du code inutile. C'est le principe de minimisation de la surface d'attaque appliqué aux conteneurs.
Le point 7 explique une confusion fréquente : une image que vous n'avez pas modifiée depuis six mois est plus vulnérable aujourd'hui qu'à sa création, parce que de nouvelles failles ont été publiées entre-temps sur ses paquets. Le scan doit être récurrent, pas seulement à la construction.
4. Le modèle de responsabilité partagée
C'est le malentendu le plus coûteux du cloud. Les fournisseurs majeurs disposent de moyens de sécurité que presque aucune entreprise ne peut égaler. Mais cela ne protège absolument pas contre un espace de stockage que vous avez rendu public, ou un rôle d'administration attribué trop largement.
La bonne nouvelle : cette catégorie d'erreurs est entièrement détectable automatiquement. C'est exactement ce que font l'analyse d'infrastructure as code et le CSPM. Le sujet est également traité dans notre cours cloud.
5. Où placer les contrôles dans le pipeline
Le principe qui guide ce placement : plus le contrôle est tôt, plus il est économique et mieux il est accepté. Un développeur corrige volontiers un problème signalé dans son éditeur ; il accueille beaucoup moins bien le même problème remonté trois semaines plus tard par une équipe externe.
6. Calibrer le blocage sans paralyser
La distinction la plus utile en pratique : bloquer sur les dépendances de production mais pas sur celles de développement. Une faille dans un outil de test n'atteint jamais vos utilisateurs, et bloquer dessus est le meilleur moyen de faire désactiver votre contrôle par exaspération.
Un conseil de déploiement progressif : activez d'abord tous vos contrôles en mode signalement seul pendant deux à quatre semaines. Vous mesurez ainsi le bruit réel, vous nettoyez le passé, et vous ne rendez bloquant que ce qui est tenable.
7. Le tableau de synthèse de l'outillage
| Ce que vous voulez éviter | L'outil qui le détecte | Où le placer |
|---|---|---|
| Injection SQL dans votre code | SAST | Éditeur, proposition de modification |
| Dépendance vulnérable | SCA | Proposition de modification, quotidien |
| Secret dans le code | Détection de secrets | Crochet local, puis CI |
| Image de base pleine de failles | Scan d'image | Construction, puis récurrent |
| Stockage cloud public | Analyse d'infrastructure as code | Proposition de modification |
| Dérive de configuration en production | CSPM | En continu |
| Vulnérabilité réellement exploitable | DAST | Recette, périodiquement |
| Comportement anormal en production | Détection à l'exécution | En continu |
| Image substituée avant déploiement | Signature + vérification | Admission |
Ce tableau constitue un plan de mise en place utilisable tel quel. N'essayez pas de tout activer en une fois : suivez l'ordre de rentabilité — détection de secrets, puis SCA, puis analyse d'infrastructure as code, puis le reste.
Retenir en 30 secondes
- SAST = analyse du code source, précis mais bruyant. DAST = attaque l'application en marche, moins précis mais prouvé exploitable. SCA = dépendances, le meilleur rapport valeur sur effort.
- Si vous n'activez qu'un outil, activez le SCA. Quinze minutes, couvre le vecteur d'attaque le plus fréquent.
- L'analyse d'infrastructure as code vérifie le code, le CSPM vérifie la réalité. Les deux divergent toujours : c'est la dérive.
- Conteneurs : image de base minimale, jamais root, construction multi-étapes, aucun secret dans les couches, versions épinglées, système de fichiers en lecture seule, scan récurrent.
- Passer à une image de base légère peut faire chuter le nombre de vulnérabilités de plusieurs centaines à quelques unités.
- Une image inchangée devient vulnérable avec le temps — les failles sont publiées après sa construction.
- Responsabilité partagée : le fournisseur sécurise le cloud, vous sécurisez ce que vous mettez dedans. La quasi-totalité des incidents cloud vient d'une mauvaise configuration client.
- Plus le contrôle est tôt, plus il est économique et accepté.
- Bloquez sur : secret détecté, vulnérabilité critique exploitable en production, exposition publique de données. Signalez le reste.
- Démarrez en mode signalement seul pendant deux à quatre semaines avant de rendre bloquant.
Suivant : Incidents réels + FAQ 14 questions →