Au cours des dernières années, de nombreuses entreprises ont adopté un outillage DevSecOps afin de sécuriser leurs applications tout au long des cycles de développement. Ces outils incluent des SAST, DAST, SCA, ainsi que des scanners pour les conteneurs, l’Infrastructure-as-Code et les secrets. L’objectif n’est plus seulement de détecter les vulnérabilités, mais aussi d’assurer une intégration et une automatisation transparentes au sein des pipelines CI/CD.
C’est ici qu’intervient l’Application Security Posture Management (ASPM). En effet, gérer de nombreuses applications et leurs outils de sécurité associés tout en maintenant une visibilité complète devient de plus en plus complexe. Dans ce contexte, l’ASPM répond logiquement à cette hétérogénéité croissante dans les chaînes CI/CD, en unifiant la gestion de la sécurité des applications sur une seule plateforme. Cela permet alors aux équipes d’évaluer et de visualiser plus clairement la posture de sécurité de tous leurs périmètres applicatifs.
L’objectif de cet article est de passer brièvement en revue les capacités d’ASPM, et de déterminer s’il s’agit simplement d’une nouvelle approche pour la gestion des vulnérabilités, ou bien si cela représente un changement de paradigme vers un nouvel outil de sécurité unique. Nous examinerons également les facteurs clés que les entreprises prennent en compte pour choisir la solution ASPM la plus adaptée à leurs besoins.
Qu’est-ce que l’ASPM ?
ASPM est l’un des derniers « buzzwords » dans le domaine de l’AppSec. Ce terme, qui s’est surtout popularisé depuis que Gartner en a publié un document d’analyse en mai 2023, désigne une technologie permettant aux organisations d’unifier tous leurs outils de sécurité applicative sous une seule interface. Au cours de la dernière année, plusieurs start-ups et acteurs AppSec ont développé leur propre solution afin de s’emparer d’une partie de ce nouveau marché.
La définition fournie par Gartner est la suivante : « Les solutions d’Application Security Posture Management (ASPM) gèrent en continu les risques liés aux applications via la détection, la corrélation et la priorisation des problèmes de sécurité tout au long du cycle de vie logiciel, du développement au déploiement. Elles agissent comme une couche de gestion et d’orchestration pour les outils de sécurité, permettant le contrôle et l’application des politiques de sécurité« .
Fig 1 – Récapitulatif des caractéristiques d’ASPM
La valeur sous-jacente d’ASPM est d’assurer une sécurité évolutive qui peut s’adapter au « Code-to-Cloud ». L’ASPM améliore la visibilité à tous les stades, réduit considérablement les faux positifs et la fatigue des alertes, et fournit surtout une source unique de vérité pour partager la propriété des vulnérabilités. C’est donc un atout clé pour les organisations submergées par des milliers d’alertes et ayant du mal à allouer efficacement des ressources pour y remédier.
En quoi cette technologie est-elle unique par rapport aux solutions existantes ?
Les outils traditionnels de gestion des vulnérabilités se concentrent sur l’agrégation et la priorisation des problèmes de sécurité détectés par des scanners. Cependant, ces outils couvrent souvent des périmètres informatiques plus larges sur tout le système d’information, sans se focaliser sur la sécurité des applications.
L’Application Security Orchestration & Correlation (ASOC) avait initialement marqué un tournant dans ce domaine en se concentrant spécifiquement sur la gestion des problèmes de sécurité des applications. L’ASOC offrait aux équipes DevSecOps une interface pour orchestrer leurs outils et uniformiser les flux de remédiation.
L’ASPM, de son côté, peut être considéré comme une évolution d’ASOC, élargissant son champ d’action de la sécurité du code à une gestion complète du code-to-cloud. Cela inclut non seulement l’analyse du code des applications, mais aussi de l’infrastructure et des ressources utilisées dans les phases de développement et de déploiement. Par exemple, l’ASPM peut analyser des configurations, des images de conteneurs et des modules Infrastructure-as-Code (IaC) comme des scripts Terraform.
D’autres différences entre ASPM et ASOC incluent :
- Priorisation améliorée : L’ASPM donne une priorité aux risques critiques pour l’entreprise, au-delà des simples scores CVSS.
- Support à la conformité : L’ASPM permet de classer les vulnérabilités selon des cadres tels qu’OWASP, ISO et SOC2, aidant les organisations à atteindre leurs objectifs de conformité.
- Policy-as-Code : L’ASPM permet de définir des politiques, comme bloquer les déploiements si les scores de risque dépassent un seuil ou si des revues de code sont incomplètes.
Facteurs décisifs dans le choix d’un fournisseur
Avec une utilisation adéquate, l’ASPM peut optimiser les flux de travail des équipes et accélérer la résolution des problèmes de sécurité. Cependant, toutes les solutions ASPM ne conviennent pas à toutes les organisations.
Fig 2 – Panel non exhaustif de fournisseurs d’ASPM
Chaque contexte apporte des facteurs de décision uniques pour choisir le bon ASPM :
- Cette solution peut-elle intégrer les outils dont je dispose déjà ? Sera-t-elle proche d’une expérience « plug-and-play » ?
- Jusqu’à quel point puis-je intégrer cet ASPM dans ma CI/CD ? Jusqu’où peut-il automatiser les workflows de remédiation ?
- Qui sont les utilisateurs finaux ciblés ? (Équipes de sécurité, Security Champion, Devs & Ops)
- L’APSM utilise-t-il un algorithme personnalisé pour établir les priorités ou plutôt un CVSS, EPSS ?
- L’interface est-elle esthétique et facile à utiliser ? Puis-je la personnaliser ?
- Comment le fournisseur traite-t-il mes données ?
- La sécurité de la plateforme correspond-elle à mes besoins ? Supporte-t-elle du SSO, MFA, RBAC ?
- Quel est le niveau de support offert par l’éditeur ?
- Les formules de souscription proposées sont-elles adaptées aux besoins de mon organisation ?
- Qu’entend-on concrètement par l’utilisation annoncée de l’intelligence artificielle dans la solution ?
Quelques points à considérer
Maturité DevSecOps
L’ASPM est une solution utile mais quelque peu « de niche » pour la sécurité des applications. Bien qu’il puisse fonctionner comme un outil plug-and-play relativement efficace, l’ASPM nécessite encore un travail d’intégration et un ajustement par les équipes de sécurité pour en maximiser le potentiel. Les organisations dépourvues d’une base solide en matière de sécurité ou qui en sont encore aux premières étapes de la mise en place d’une pipeline DevSecOps pourraient tirer moins de bénéfices d’un ASPM. Pour ces entreprises, il serait plus pratique de se concentrer d’abord sur les outils et processus fondamentaux en amont.
Gestion des faux positifs et des faux négatifs
L’un des avantages promis par l’ASPM est la réduction des faux positifs, un bénéfice commun à la gestion des vulnérabilités. En pratique, bien que le nombre d’alertes soit réduit, il n’est jamais totalement éliminé. Les équipes de sécurité doivent encore trier manuellement et traiter les vulnérabilités que le système ne peut pas classer définitivement comme faux positifs.
Un autre problème est le risque de faux négatifs. Certains fournisseurs affirment que leurs outils « réduisent les vulnérabilités de 99 % ». Toutefois, à moins que les algorithmes d’évaluation des risques ne soient entièrement transparents, il existe un risque que des problèmes de sécurité réels soient ignorés. Lorsque des algorithmes classent certaines vulnérabilités comme insignifiantes sans justification adéquate, cela crée des zones d’ombre qui pourraient exposer l’organisation à des risques non traités.
Conformité aux besoins des équipes
Avant de s’engager dans une solution ASPM, il est essentiel de s’assurer qu’elle répond aux exigences spécifiques de l’organisation. Réaliser un Proof of concept (PoC) à petite échelle – en testant la plateforme avec différentes équipes opérant sous des dynamiques variées – peut fournir des informations précieuses sur ses aspects pratiques.
Enfin, la plupart des solutions ASPM sont proposées sous forme de plateformes SaaS, ce qui simplifie leur déploiement pour un PoC et permet d’évaluer l’outil sans investissement initial important.
Sécurité
Étant donné que l’ASPM a souvent accès à des données sensibles, telles que du code source et des configurations, les organisations doivent vérifier soigneusement que la solution respecte leurs normes et leurs standards de sécurité. Ne pas le faire risque de transformer son ASPM en un point de défaillance au sein de la pile de sécurité.
Une autre définition d’ASPM ?
Un gestionnaire de vulnérabilités, dans son essence, ne vise pas à scanner des ressources, mais simplement à agréger les résultats que d’autres outils lui fournissent. De même, la valeur fondamentale de l’ASPM, telle qu’elle a été définie par Gartner, est de gérer les risques dans les environnements Code-to-Cloud, sans se mêler de la partie scanners, qui est laissée aux outils AppSec et CSPM.
Cependant, deux ans après la publication de l’étude de Gartner, les ASPM ont pris une direction qui s’écarte quelque peu de leur vision initiale. Les fournisseurs d’ASPM ont commencé à intégrer des scanners natifs dans leurs solutions afin que leurs clients n’aient pas à en acquérir d’autres. Un excellent article de James Berthoty affirme à juste titre que, puisque la définition de l’ASPM de Gartner peut simplement être considérée comme une évolution de l’ASOC, il n’y a aucune raison de l’appeler autrement qu’ASOC.
La seule raison légitime d’évoluer d’ASOC à ASPM serait un nouveau type d’outil visant à répondre à un besoin du marché de l’AppSec qui n’a pas encore été satisfait : une plateforme tout-en-un pour la sécurité des applications. En connectant simplement votre code source et vos environnements, cette plateforme analyserait tout, agrégerait les résultats et produirait simplement les problèmes les plus critiques et la manière d’y remédier. Cela pourrait être particulièrement pertinent pour les organisations qui n’ont pas de stack de sécurité préalable et qui recherchent un gestionnaire AppSec complet, tandis que celles qui souhaitent conserver leur chaîne d’outils actuelle pourraient opter pour une version ASPM d’agrégation à la place.
Fig 3 – Comment définir l’ASPM idéal
En conclusion
Gartner avait initialement prévu que d’ici 2026, plus de 40% des organisations développant des applications propriétaires utiliseraient un ASPM pour gérer les risques liés à leurs applications. Bien que cette prédiction soit légèrement ambitieuse, le besoin en plateformes centralisées pour gérer la sécurité augmente lui aussi rapidement.
Pour réaliser son plein potentiel, l’ASPM doit s’inscrire dans une stratégie DevSecOps plus large. Les organisations doivent établir les bons processus, une gouvernance efficace et des bases solides en CI/CD.