Mauvaises configurations, vulnérabilités connues non corrigées et sécurité des applications cloud natives

Il y a deux semaines, nous avons publié notre rapport annuel sur l’état de la sécurité des applications cloud natives. Si vous ne l’avez pas encore consulté, en voici un résumé. Nous avons interrogé près de 600 développeurs et professionnels de la sécurité pour comprendre comment le passage au cloud natif (la transformation numérique) a modifié leur posture de sécurité. Nous avons ensuite analysé les résultats, dégagé des informations précieuses et les avons présentées sur une page Web interactive.

Les résultats nous ont apporté de nombreux enseignements intéressants. En voici quelques-uns qui, selon moi, sont étroitement liés :

1. Presque toutes les personnes interrogées s’accordent à dire qu’à mesure que l’adoption du cloud natif progresse, la sécurité doit être intégrée par défaut.

2. Les personnes interrogées dont les pipelines sont fortement automatisés étaient deux fois plus susceptibles d’intégrer des tests de sécurité tout au long du cycle de développement.

3. Les développeurs se considèrent comme des acteurs à part entière de la sécurité.

Ces éléments dessinent une voie claire vers le DevSecOps, où la réussite de la sécurité dépend de l’implication des développeurs et de l’automatisation des processus. Malheureusement, un élément ajouté au point 1 montre que de nombreuses organisations n’en sont pas encore là : Bien que les personnes interrogées conviennent que la sécurité doit être intégrée par défaut, plus de la moitié ont été confrontées à une mauvaise configuration ou à des vulnérabilités connues non corrigées dans leurs applications cloud natives.

Pour aller plus loin, les deux principaux types d’incidents, et de loin, étaient les mauvaises configurations (45 %) et les vulnérabilités connues non corrigées (38 %). Au total, 56 % des personnes interrogées ont subi un incident lié à une mauvaise configuration ou à une vulnérabilité connue non corrigée dans leurs applications cloud natives. Ce chiffre est toutefois encore plus élevé, puisque 18 % des personnes interrogées n’ont pas répondu à cette question, jugée sensible. En tenant compte du taux de réponse de 82 % à cette question, 69 % avaient une mauvaise configuration ou une vulnérabilité connue non corrigée dans leurs applications cloud natives.

Au vu de ces résultats importants, il semble que les développeurs, même s’ils assument davantage de responsabilités en matière de sécurité et d’exploitation, ne parviennent pas à gérer correctement des responsabilités de plus en plus liées à l’infrastructure. Cela ne signifie pas qu’ils en sont incapables : leur charge de travail s’est simplement accrue et les compétences requises se sont élargies. Il est temps de réévaluer la situation des développeurs dans ce nouvel environnement cloud natif.

« Les erreurs de configuration et les vulnérabilités connues étant les principales préoccupations et causes d’incidents, nous devons repenser la façon dont les équipes de développement hiérarchisent les tâches de sécurité. Lorsqu’un développeur est responsable de la sécurisation de l’ensemble d’une application cloud native, il est souvent plus important qu’il s’attaque à ces problèmes d’hygiène de sécurité plutôt qu’aux vulnérabilités du code personnalisé de l’application, sur lesquelles se concentrent la plupart des programmes de sécurité. »

Je ne saurais mieux dire, Guy. Heureusement, ces deux problèmes peuvent être résolus en adoptant des outils de sécurité conçus pour les développeurs, capables de 1) détecter les vulnérabilités de sécurité dans l’ensemble du cycle de développement et de 2) fournir du contexte et aider à hiérarchiser les vulnérabilités.

Les vulnérabilités ne peuvent pas être traitées en silos et, surtout, elles ne peuvent pas être hiérarchisées uniquement selon leur silo. Des erreurs de configuration dans l’infrastructure peuvent exposer une application aux attaques, même si son code est bien sécurisé. Les développeurs ont besoin d’outils capables de détecter toutes les vulnérabilités et les mauvaises configurations dans le code, les dépendances, les conteneurs et l’infrastructure, puis de leur fournir une liste complète et hiérarchisée.

La hiérarchisation consiste à examiner la gravité de la vulnérabilité, le niveau de maturité des attaques et sa visibilité pour les attaquants. Si une vulnérabilité est potentiellement grave, mais que les attaquants ne peuvent l’exploiter qu’après avoir franchi plusieurs autres couches de sécurité, réduisez sa priorité. Si la mise à jour d’une seule image de base permet de corriger 100 vulnérabilités, augmentez sa priorité. Un développeur ne peut pas corriger toutes les vulnérabilités : il doit donc savoir sur lesquelles se concentrer.

Les outils de sécurité doivent fournir ce niveau de contexte, car nous ne pouvons pas nous attendre à ce que chaque développeur soit un expert en sécurité : ce serait tout simplement irréaliste. Les outils de sécurité conçus pour les développeurs doivent plutôt agir comme un expert de confiance, toujours présent dans leur boîte à outils. Il faut réduire autant que possible les obstacles à la sécurité afin de protéger les applications et les infrastructures cloud.

Quoi qu’il en soit, nous venons d’examiner en détail un seul des sujets abordés dans le rapport sur l’état de la sécurité des applications cloud natives. Que vous ayez déjà adopté le cloud natif ou que vous envisagiez cette transition, je vous recommande vivement de consulter le rapport. Vous pouvez également écouter Guy et moi en discuter dans un épisode récent du podcast The Secure Developer. Après avoir lu le rapport (ou écouté le podcast), si vous souhaitez contextualiser et hiérarchiser les risques liés à la sécurité de vos applications cloud natives, créez gratuitement un compte Snyk.