CNAPP (Cloud-Native Application Protection)

Définition

Une CNAPP (Cloud-Native Application Protection Platform) est une plateforme de sécurité unifiée qui consolide en un seul produit les fonctions historiquement séparées du CSPM (posture de configuration cloud), du CWPP (protection des workloads : VM, conteneurs, fonctions serverless) et du CIEM (gestion des droits et identités cloud). Son objectif : couvrir le risque d'une application cloud-native de bout en bout, du dépôt de code jusqu'à l'exécution en production, plutôt que de juxtaposer des outils qui ne partagent ni contexte ni référentiel d'actifs.

Le terme a été popularisé par Gartner en 2021 pour répondre à un constat simple : une vulnérabilité isolée dans une image conteneur n'a pas la même gravité selon qu'elle est exposée sur Internet, exécutée avec un rôle IAM administrateur, ou confinée dans un cluster de test. Seule une plateforme qui corrèle ces trois dimensions peut hiérarchiser correctement.

Les trois piliers techniques

• CSPM — analyse en continu les configurations des comptes AWS, Azure et GCP via leurs API natives. Détecte les buckets S3 publics, les groupes de sécurité ouverts en 0.0.0.0/0, le chiffrement absent, les logs désactivés. Mesure l'écart par rapport à des référentiels tels que CIS Benchmarks, ANSSI, PCI DSS ou ISO 27001.
• CWPP — protège la charge de travail elle-même : scan des images de conteneurs, détection des vulnérabilités (CVE) dans les dépendances applicatives et les paquets système, contrôle d'intégrité, et surveillance runtime des comportements anormaux (processus inattendu, escalade de privilèges, connexion sortante vers une infrastructure malveillante).
• CIEM — cartographie les identités humaines et machines, ainsi que les permissions effectives. Il révèle l'écart entre droits accordés et droits réellement utilisés, principal vecteur de mouvement latéral dans le cloud.

Beaucoup de solutions ajoutent aujourd'hui le KSPM (posture Kubernetes), le scan d'IaC (Terraform, CloudFormation, Helm), la détection de secrets en clair dans le code, et la génération de SBOM.

Fonctionnement : agentless, agent et shift-left

Une CNAPP moderne combine deux modes de collecte. Le mode agentless s'appuie sur un rôle en lecture seule et sur le snapshot scanning : la plateforme photographie les volumes disque des instances pour les analyser hors bande, sans rien installer ni impacter les performances. Le déploiement se fait en quelques heures sur un parc entier, mais la vision reste périodique.

Le mode agent — souvent basé sur eBPF pour observer les appels système sans module noyau — apporte la visibilité temps réel indispensable à la détection d'intrusion et au blocage runtime. Les deux approches sont complémentaires : agentless pour la couverture large, agent sur les workloads critiques.

La logique shift-left consiste à déplacer ces contrôles au plus tôt : un hook pré-commit bloque un secret, un job de CI/CD refuse un plan terraform créant une ressource non chiffrée, un admission controller Kubernetes empêche le déploiement d'une image contenant une CVE critique. Corriger un manifeste dans une pull request coûte quelques minutes ; corriger la même erreur en production suppose un changement, une fenêtre de maintenance et un risque de régression.

Le graphe de risque, apport différenciant

La valeur réelle d'une CNAPP ne réside pas dans l'accumulation d'alertes mais dans leur corrélation. La plateforme construit un graphe reliant actifs, expositions, vulnérabilités et identités, puis identifie les chemins d'attaque exploitables. Exemple typique : une machine exposée publiquement, portant une bibliothèque vulnérable à une RCE, associée à un rôle disposant de s3:GetObject sur un bucket de données clients. Prises isolément, ces trois observations génèrent trois alertes de sévérité moyenne noyées parmi des milliers d'autres ; combinées, elles décrivent une compromission de données à traiter dans l'heure.

Liens avec les autres concepts

La CNAPP prolonge la démarche DevSecOps en outillant les développeurs plutôt qu'en arbitrant après coup. Elle alimente le SIEM et le SOC en signaux contextualisés, et sert d'assise technique au Zero Trust côté charges de travail en appliquant le moindre privilège aux identités machines. Elle recoupe partiellement le CASB (qui couvre l'usage des applications SaaS) et le XDR (centré sur la détection multi-domaines), sans les remplacer. Sur le plan réglementaire, ses rapports de conformité continue facilitent la démonstration d'exigences NIS 2, DORA ou ISO 27001 relatives à la maîtrise des configurations et à la gestion des vulnérabilités.

Bonnes pratiques de déploiement

• Commencer par un inventaire exhaustif en mode agentless : on ne protège pas ce que l'on ignore, et le shadow cloud est fréquent.
• Définir une politique de sévérité fondée sur l'exploitabilité réelle (exposition, privilèges, criticité de la donnée), non sur le seul score CVSS.
• Introduire le blocage en CI/CD progressivement : avertissement d'abord, échec de build ensuite, pour éviter le rejet des équipes de développement.
• Traiter les causes racines dans les modules IaC réutilisables plutôt que les symptômes en production, sous peine de voir la dérive réapparaître au déploiement suivant.
• Attribuer chaque alerte à une équipe propriétaire via les tags cloud, condition indispensable d'une remédiation effective.
• Vérifier la couverture multi-cloud et la profondeur réelle du support Kubernetes avant de contractualiser, les écarts entre éditeurs restant importants.