~10 minutes
Cet article fait partie de la série Sécurité Kubernetes. Si vous cherchez l’introduction et le sommaire complet, commencez par là.
Kubescape: plus qu’un scanner, une plateforme
Quand Kubescape est apparu en 2021, c’était un outil de ligne de commande qui permettait d’évaluer un cluster Kubernetes face aux recommandations NSA-CISA. Sympathique, utile, mais limité. Trois ans plus tard, le tableau est très différent.
Avec la version 3, sortie fin 2024 et activement maintenue en 2025 et 2026, Kubescape est devenu une véritable plateforme de sécurité Kubernetes. Le projet est porté par ARMO, intégré à la CNCF au niveau Sandbox depuis août 2022 et activement en chemin vers le statut Incubating depuis début 2025. La communauté grandit, les contributions externes augmentent, et le rythme de release s’est stabilisé.
Kubescape couvre en un seul outil ce qui nécessitait auparavant trois ou quatre solutions distinctes : l’audit de configuration, le scan de vulnérabilités sur images, l’analyse des permissions RBAC et le monitoring continu.
Kubescape fait en un seul outil ce que la plupart des équipes couvrent avec trois solutions distinctes : l’audit de configuration contre des frameworks reconnus (NSA, CIS, MITRE), le scan de vulnérabilités CVE sur les images de conteneurs sans dépendance externe obligatoire, et l’analyse RBAC avec détection des comptes de service surdimensionnés.
La série d’articles sur la sécurité Kubernetes a déjà couvert kube-bench pour les audits CIS, Trivy pour le scan d’images, Falco pour la détection runtime, et OPA Gatekeeper pour le Policy as Code.
Kubescape occupe une position différente dans cet écosystème : là où les autres excellent chacun dans leur domaine, Kubescape propose une vision transversale. C’est un avantage pour les petites équipes qui ne peuvent pas gérer cinq outils en parallèle. C’est un inconvénient pour les équipes matures qui veulent aller très loin sur chaque dimension, car aucun des piliers de Kubescape n’atteint la profondeur d’un outil dédié.
Les frameworks de sécurité supportés
L’un des atouts majeurs de Kubescape est la richesse des frameworks de conformité qu’il embarque. En mai 2026, la liste s’est encore étoffée avec l’ajout du support DISA STIG.
| Framework | Version supportée | Périmètre |
|---|---|---|
| NSA-CISA Kubernetes Hardening Guide | v2.0 | Control plane, workloads, réseau, authentification |
| MITRE ATT&CK for Containers | v14+ | Tactiques et techniques d’attaque sur containers |
| CIS Kubernetes Benchmark | 1.9.0 (Kubernetes 1.30+) | Hardening complet du cluster |
| DISA STIG Kubernetes | v2 | Conformité DoD américain (ajouté en 2025) |
| SOC 2 | Mapping partiel | Contrôles de sécurité cloud |
| PCI-DSS | Mapping partiel | Environnements de paiement |
Le support DISA STIG est une vraie nouveauté de 2025. C’est un signal fort : Kubescape n’est plus seulement un outil pour les startups cloud-native, il adresse désormais les environnements gouvernementaux et régulés.
La version 1.9.0 du benchmark CIS mérite une mention particulière. Elle couvre Kubernetes 1.30 et supérieur, avec des contrôles mis à jour pour les Pod Security Standards (qui ont remplacé PodSecurityPolicy), les nouvelles options de configuration du scheduler et les changements d’API intervenus depuis la 1.28. Les équipes qui tournaient encore sur CIS 1.7.x ont une bonne raison de mettre à jour leur outillage.
L’intégration du framework MITRE ATT&CK for Containers version 14 permet quant à elle de cartographier les failles détectées sur les techniques d’attaque connues. C’est particulièrement utile pour prioriser les remédiations : une vulnérabilité qui correspond à une technique d’escalade de privilèges (TA0004) ou d’exécution de code à distance (TA0002) passe naturellement avant une non-conformité de logging.
Intégrer Kubescape dès le début du cycle DevSecOPS
Le concept de DevSecOPS appliqué à la sécurité Kubernetes signifie détecter les problèmes de configuration et de vulnérabilités avant que le manifeste n’atterrisse en production ; idéalement avant même qu’il ne quitte le poste du développeur. Kubescape couvre les deux niveaux.
Dans les pipelines CI/CD
Kubescape s’intègre nativement dans les pipelines CI/CD les plus courants. L’action GitHub officielle permet d’exécuter un scan Kubescape sur les manifestes Kubernetes présents dans le dépôt à chaque pull request. L’outil retourne un code de sortie différent de zéro si un seuil de score de conformité n’est pas atteint, ce qui permet de bloquer la merge en cas d’écart trop important par rapport au framework cible.
Pour GitLab CI, l’approche est similaire via une image Docker officielle qui s’intègre dans un stage de validation. Le pipeline peut être configuré pour scanner les manifestes Helm, les fichiers YAML bruts ou même les charts directement depuis le registry.
Jenkins bénéficie d’un plugin dédié maintenu par la communauté, qui permet de publier les résultats dans le tableau de bord Jenkins et de configurer des seuils de qualité par framework. Les équipes qui utilisent encore Jenkins apprécient de ne pas avoir à gérer une intégration en shell script.
L’intégration CI/CD n’est utile que si les développeurs comprennent les alertes qu’elle produitv ou si vous disposez d’un endroit central avec toutes vos détections comme DefectDojo par exemple. Kubescape génère des rapports lisibles avec des liens vers la documentation du contrôle en échec.
Plugins IDE
Pour aller encore plus loin dans le shift left, Kubescape propose une extension VS Code officielle. Elle analyse les fichiers YAML Kubernetes au fur et à mesure de leur édition et affiche les violations directement dans l’interface, avec des suggestions de correction en ligne. Pour un développeur qui écrit un Deployment ou un StatefulSet, voir immédiatement qu’il manque un securityContext ou que le conteneur tourne en root sans justification change les habitudes progressivement.
Analyse RBAC : voir ce que les autres outils ne voient pas
L’analyse RBAC de Kubescape est l’une des fonctionnalités les plus distinctives de la plateforme. La configuration RBAC d’un cluster Kubernetes qui a quelques mois de vie devient rapidement un enchevêtrement de Roles, ClusterRoles, RoleBindings et ServiceAccounts dont personne n’a une vision complète. La série de cet article avait déjà abordé RBAC en détail, mais disposer d’un outil automatisé pour auditer l’existant est indispensable.
Kubescape génère une cartographie complète des permissions en partant des ServiceAccounts et en remontant toute la chaîne : quels RoleBindings les attachent, quels Roles ou ClusterRoles sont impliqués, et quelles ressources et verbes ces rôles accordent concrètement. L’export peut se faire en JSON pour un traitement programmatique ou en graphe visuel pour une présentation aux équipes de gouvernance.
La détection des privilèges excessifs couvre les patterns les plus dangereux : ServiceAccounts avec des droits cluster-admin sans raison apparente, bindings qui accordent des droits get, list, watch sur la totalité des secrets du cluster, ou encore des workloads dont le ServiceAccount par défaut a été enrichi de permissions supplémentaires sans traçabilité.
Un pattern souvent négligé : le ServiceAccount par défaut du namespace
defaultporte parfois des droits accordés lors d’un test jamais nettoyé. Kubescape le détecte systématiquement, là où un audit manuel aurait peu de chances de l’attraper.
Les alertes sur les ServiceAccounts trop permissifs incluent également une évaluation du risque de mouvement latéral. Si un ServiceAccount monté dans un Pod applicatif dispose de droits suffisants pour lire les secrets d’autres namespaces ou pour créer des Pods dans des namespaces sensibles, Kubescape le signale avec un niveau de criticité élevé et une explication de l’impact potentiel.
Kubescape Operator : le monitoring continu en cluster
Lancer Kubescape en one-shot depuis le CI ou depuis un poste local, c’est bien. Mais la configuration d’un cluster Kubernetes évolue en permanence : nouvelles ressources déployées, modifications de RBAC, nouvelles images tirées depuis les registries. Le monitoring continu est indispensable pour ne pas rater les dérives introduites entre deux audits ponctuels.
Le Kubescape Operator répond à ce besoin. Il se déploie comme un opérateur Kubernetes natif et orchestre des scans automatiques selon une fréquence configurable. L’opérateur gère trois composants principaux : un scanner de configuration qui évalue les ressources du cluster en continu, un scanner d’images qui analyse les CVE sur les workloads actifs, et un collecteur de données RBAC qui suit les évolutions de permissions.
L’intégration avec Prometheus est native. L’opérateur expose des métriques au format standard, ce qui permet de créer des dashboards Grafana pour suivre l’évolution du score de conformité dans le temps, le nombre de contrôles en échec par framework, ou le nombre de CVE critiques sur les images en production. Ces métriques s’intègrent naturellement dans les alertes existantes de l’équipe ops.
SBOM et supply chain : la nouveauté structurante de 2025
La supply chain logicielle est devenue un sujet central depuis les incidents SolarWinds, Log4Shell et, plus récemment, les compromissions de dépendances npm et PyPI qui se multiplient. Kubernetes n’échappe pas à ce risque : les images déployées dans les clusters sont construites à partir de couches et de dépendances dont la traçabilité est souvent insuffisante.
Kubescape v3 intègre nativement la génération de SBOM (Software Bill of Materials) pour les images scannées. Le SBOM liste l’ensemble des composants identifiés dans une image : packages système, bibliothèques applicatives, métadonnées de build. L’outil produit des SBOM aux formats CycloneDX et SPDX, les deux standards qui s’imposent aujourd’hui dans l’industrie.
L’intégration avec Cosign permet de vérifier les signatures des images avant leur analyse. Une image non signée ou dont la signature ne correspond pas à l’identité attendue est signalée comme risque supply chain avant même que le scan CVE commence. C’est une couche de défense supplémentaire qui complète le scan de vulnérabilités classique.
Le support SLSA (Supply-chain Levels for Software Artifacts) est intégré dans l’analyse : Kubescape peut évaluer le niveau SLSA des artefacts déployés et signaler les workloads construits avec un niveau d’attestation insuffisant pour l’environnement cible. Les équipes qui ont travaillé sur leur posture SLSA apprécient de voir cette évaluation intégrée dans le même rapport que les audits CIS et NSA.
La combinaison SBOM + Cosign + SLSA dans un seul outil évite aux équipes de gérer trois pipelines distincts de vérification supply chain.
Multi-cloud : benchmarks spécifiques par fournisseur
Un cluster Kubernetes EKS sur AWS, un cluster GKE sur Google Cloud et un cluster AKS sur Azure ne se configurent pas de la même façon. Les services managés exposent des contrôles différents, certaines recommandations CIS ne s’appliquent pas (le control plane est géré par le fournisseur), et chaque cloud ajoute ses propres mécanismes d’authentification, de networking et de stockage.
Kubescape gère cette hétérogénéité avec des benchmarks spécifiques par fournisseur, alignés sur les recommandations des clouds eux-mêmes et sur les versions CIS dédiées (EKS Benchmark, GKE Benchmark, AKS Benchmark).
| Plateforme | Benchmark embarqué | Spécificités couvertes |
|---|---|---|
| Amazon EKS | CIS EKS Benchmark v1.4 | IAM Roles for Service Accounts (IRSA), Security Groups for Pods, Karpenter node policies |
| Google GKE | CIS GKE Benchmark v1.4 | Workload Identity, Binary Authorization, GKE Autopilot constraints |
| Azure AKS | CIS AKS Benchmark v1.4 | Azure AD integration, Azure Policy add-on, managed identities, OIDC issuer |
| Kubernetes vanilla | CIS Kubernetes 1.9.0 | Contrôle total du control plane, toutes les options disponibles |
| k3s / edge | Benchmark communautaire | Ressources contraintes, suppression des composants non essentiels |
La couverture IRSA sur EKS est particulièrement utile. Le pattern de privilèges excessifs via des IAM Roles mal scoped pour des Service Accounts Kubernetes est un vecteur d’attaque fréquent dans les clusters AWS. L’article sur EKS et celui sur AKS de la série détaillent ces particularités ; Kubescape permet de les auditer automatiquement.
Avantages et limites : un bilan honnête
Avant d’investir du temps dans l’adoption d’un outil, il vaut mieux avoir une vision claire de ce qu’il fait bien et de ce qu’il fait moins bien. Kubescape ne fait pas exception.
Sur l’analyse RBAC et la couverture multi-framework, Kubescape n’a pas d’équivalent direct dans l’écosystème open-source. Embarquer NSA, CIS 1.9.0, MITRE ATT&CK v14 et DISA STIG dans un seul binaire statique installable en une commande, c’est un avantage concret pour les équipes qui démarrent un programme de conformité. L’installation est triviale ; la valeur est immédiate.
Sur le scan CVE, c’est honnêtement correct ; ni plus, ni moins. Trivy reste plus exhaustif sur les layers d’images non-standards et sur les langages moins courants. Si le scan de vulnérabilités est la priorité absolue, Trivy mérite sa propre place dans le pipeline, indépendamment de Kubescape.
La limite la plus nette est la détection runtime : elle est absente. Ce n’est pas un défaut de conception ; c’est un choix de périmètre que l’outil assume clairement. Falco reste indispensable pour couvrir ce vecteur et les deux outils se complètent sans se concurrencer. Sur la profondeur par pilier, Kubescape est un bon généraliste ; les équipes qui ont déjà investi dans Trivy, Falco et Gatekeeper n’y trouveront pas de révolution, mais y gagneront la vue consolidée et l’analyse RBAC automatisée.
Les limites principales méritent d’être nommées clairement. Sur le scan CVE, Trivy reste plus exhaustif sur les layers d’images non-standards et sur les langages moins courants. Sur la détection runtime, Falco n’a pas d’équivalent dans Kubescape ; les deux outils sont complémentaires et non substituables. Sur le Policy as Code avec enforcement en admission controller, OPA Gatekeeper ou Kyverno offrent une granularité bien supérieure.
Kubescape est l’outil parfait pour les équipes qui partent de zéro ou qui veulent une vue consolidée. Pour les équipes qui ont déjà un écosystème mature autour de Trivy + Falco + Gatekeeper, il apporte surtout la valeur de l’analyse RBAC et du monitoring multi-framework en un seul dashboard.
Intégration dans une chaîne DevSecOps existante
La place de Kubescape dans une chaîne DevSecOps dépend surtout de ce qui est déjà en place.
Si je devais choisir un seul moment pour introduire Kubescape dans une organisation, ce serait avant le premier vrai audit de conformité, pas après. Le score multi-framework donne une carte des priorités qu’on ne peut pas obtenir autrement, et il le fait en moins d’une heure sur n’importe quel cluster existant. Les équipes qui ont déjà un écosystème complet autour de Trivy, Falco et Gatekeeper n’y trouveront pas de substitut ; elles y gagneront la vue consolidée et l’analyse RBAC automatisée qui manquent souvent quand les outils sont pilotés en silos.
Un point d’attention pratique : Kubescape nécessite des droits de lecture relativement larges sur le cluster pour effectuer son analyse RBAC complète. Il est recommandé de créer un ServiceAccount dédié avec les droits minimaux nécessaires, de ne pas réutiliser un compte admin existant, et de tracer l’usage de cet accès. Ce détail est souvent négligé lors des déploiements rapides.
- ✓ Kubescape v3 est une plateforme tout-en-un : hardening, CVE, RBAC, SBOM et monitoring continu ; idéale pour les équipes qui partent de zéro ou qui veulent une vue consolidée.
- ✓ Les frameworks NSA-CISA v2, CIS 1.9.0 (Kubernetes 1.30+), MITRE ATT&CK v14 et DISA STIG v2 sont tous embarqués nativement ; pas besoin de configuration manuelle des règles.
- ✓ L'analyse RBAC est le point fort différenciant de Kubescape par rapport aux scanners d'images classiques ; elle détecte les ServiceAccounts surdimensionnés et les chemins d'escalade de privilèges.
- ✓ L'opérateur Kubernetes avec métriques Prometheus permet un monitoring continu sans nécessiter le dashboard cloud ARMO ; la souveraineté des données reste possible.
- ✓ L'intégration SBOM + Cosign + SLSA fait de Kubescape un acteur sérieux sur la supply chain, sans remplacer un pipeline SLSA dédié pour les environnements très exigeants.
- ✓ Kubescape ne fait pas de détection runtime : Falco reste indispensable pour couvrir ce vecteur. Les deux outils se complètent, ils ne se substituent pas.
- ✓ Les benchmarks EKS, GKE et AKS spécifiques permettent d'auditer les clusters managés avec des contrôles adaptés à chaque fournisseur cloud, pas seulement les déploiements vanilla.