7 obstacles surprenants sur la voie de la maturité DevSecOps

Dans le cadre de l’élaboration et du lancement récents de notre cadre de maturité DevSecOps, Snyk a mené une vaste étude sectorielle sur l’état actuel de la sécurité des développeurs dans les entreprises axées sur le logiciel. Plus de 300 organisations nous ont communiqué des données pour nous aider à comprendre comment elles évaluent leur propre maturité en matière de DevOps, de sécurité des applications, de gestion des vulnérabilités, de priorisation, d’adoption par les développeurs et de gouvernance des programmes.

Dans l’ensemble, nos conclusions montrent que la plupart des entreprises comprennent la valeur des pratiques DevSecOps matures et s’emploient activement à instaurer une culture de sécurité moderne et un programme AppSec axé sur l’amélioration continue. Toutefois, toutes ne s’y prennent pas de la même façon. En fait, malgré l’objectif commun d’accroître la maturité, les organisations décrivent de façons très diverses des aspects clés de leurs pratiques de sécurité, ce qui révèle des écarts importants qui persistent dans la poursuite d’un objectif commun : la maturité DevSecOps. Examinons certaines de ces conclusions qui mettent en lumière des pistes d’amélioration.

La réduction des risques et la fatigue face à la sécurité font partie des indicateurs que les équipes de sécurité mesurent le moins souvent, alors qu’ils figurent parmi les cinq principaux indicateurs qu’elles souhaitent mesurer.

Parmi toutes les métriques de sécurité suivies par les équipes étudiées, les deux moins souvent mesurées étaient « la réduction des risques attribuable aux actions des développeurs » et « la réduction de la fatigue face à la sécurité (temps consacré au triage manuel, aux builds interrompus et aux reprises de travaux de sécurité) ». Pourtant, ces deux KPI figuraient aussi presque en tête de liste lorsque nous avons demandé aux mêmes répondants quelles métriques ils souhaiteraient idéalement suivre si toutes les données pertinentes étaient disponibles. 

Il existe manifestement toujours un décalage important entre les données que les outils de sécurité peuvent facilement fournir — comme le nombre de vulnérabilités détectées et corrigées, les scores CVSS, le délai de correction, etc. — et les questions que les professionnels de la sécurité souhaitent poser, par exemple : « Dans quelle mesure une action donnée permet-elle de réduire les risques ? » Ces questions déterminent l’efficacité et le ROI de leur programme. Cela souligne l’importance d’agréger et de corréler les données sur les vulnérabilités issues de plusieurs sources afin de décloisonner les informations et d’appréhender les risques dans leur ensemble, en tenant compte du contexte des applications, de l’activité et des vulnérabilités. Les outils de gestion de la posture de sécurité des applications (ASPM), comme Snyk AppRisk, peuvent servir de plateforme interne et de source unique de vérité pour obtenir des informations sur les risques en fonction du contexte. 

Par ailleurs, parmi tous les profils inclus dans l’étude, les développeurs de logiciels étaient les plus intéressés par la mesure de la fatigue face à la sécurité, autrement dit, des tâches fastidieuses. Cette vaste catégorie vise à mesurer le coût du déplacement de la sécurité vers la gauche en termes de perte de productivité des développeurs, qui doivent consacrer du temps à des tâches de sécurité difficiles à automatiser. Comme la plupart des outils d’analyse des vulnérabilités sont conçus pour les équipes de sécurité, ils négligent souvent leur impact sur les développeurs. Il devient alors impossible de comprendre l’ampleur des inefficacités dans les processus de détection et de correction intégrés au SDLC. Cette incapacité à mesurer les tâches fastidieuses liées à la sécurité explique en partie les fortes frictions entre les équipes de développement et de sécurité, que nous continuons d’observer même dans les organisations très matures en matière de DevSecOps.

La capacité à mesurer précisément la posture de sécurité en fonction des risques est l’objectif DevSecOps numéro 1 des équipes de sécurité et d’ingénierie.

En sécurité des applications, on croit depuis longtemps à tort que les développeurs ne se soucient pas des risques logiciels. Or, la réalité le montre une nouvelle fois : la priorité DevSecOps numéro un des développeurs consiste à comprendre précisément leur posture de sécurité en fonction des risques, tout comme leurs collègues de l’AppSec. (Les équipes d’ingénierie de plateforme l’ont classée au deuxième rang.) En d’autres termes, les développeurs veulent contribuer à réduire les risques pour leur organisation, mais estiment ne pas disposer des données nécessaires pour prendre de meilleures décisions de priorisation.

Cet écart s’explique par la complexité du calcul des risques liés aux applications, qui nécessite un contexte supplémentaire (impact sur l’activité, accessibilité, maturité de l’exploit et présence de mesures compensatoires, etc.) au-delà du simple décompte des problèmes et de leur niveau de gravité. Les logiciels modernes sont très complexes et les budgets de correction toujours limités. Le temps consacré aux corrections doit donc être réparti non pas uniquement en fonction des vulnérabilités les plus graves (qui sont parfois réellement exploitables, parfois non et qui, même lorsqu’elles le sont, peuvent ou non avoir un impact important sur l’activité en cas d’exploitation), mais à l’aide d’un système de notation personnalisé fondé sur les risques et sur plusieurs sources de contexte tout au long du SDLC.

L’absence d’une approche commune de priorisation fondée sur les risques est une cause majeure de frictions entre les équipes d’ingénierie et de sécurité. Elle peut faire échouer les initiatives DevSecOps en raison d’un manque de confiance persistant. Les développeurs ont souvent l’impression qu’on les oblige à consacrer du temps à corriger les « mauvais » problèmes, c’est-à-dire ceux qui présentent en réalité moins de risques. Les professionnels de la sécurité craignent souvent que trop de risques réels ne se retrouvent en production, faute d’un mécanisme partagé et fiable d’évaluation des risques, accessible dans les flux de travail des deux profils. Il est donc clair que la mesure précise des risques constitue leur priorité commune, mais la plupart des outils de sécurité évoluent encore pour répondre à ce besoin.

Seules 50 % des organisations déclarent investir dans des formations à la sécurité juste à temps pour les développeurs et mettre en place des programmes de Security Champions au sein des équipes de développement.

La formation à la sécurité, en particulier pour les développeurs de logiciels, est un élément essentiel d’une pratique DevSecOps mature. Pour être efficace, elle doit être pertinente, concrète, continue et étroitement intégrée aux processus et aux méthodes de travail des équipes. Pourtant, la plupart des formations traditionnelles en sécurité ne répondent pas à ces critères, ce qui creuse continuellement l’écart dans la compréhension des risques de sécurité des applications et des pratiques de programmation sécurisée qui s’y rapportent.

Cet écart s’explique par la méthode d’apprentissage privilégiée par les ingénieurs, fondée sur la résolution de problèmes concrets. La grande complexité des techniques modernes de développement logiciel rend difficile l’enseignement de tout ce qu’un ingénieur doit savoir selon des méthodes traditionnelles descendantes. Les développeurs apprennent plutôt en pratiquant : ils rencontrent un problème et doivent trouver une solution avant de passer à la suite. Ce type d’apprentissage « juste à temps » s’ancre beaucoup mieux dans la durée. Pourtant, la plupart des programmes de formation à la sécurité adoptent l’approche inverse, qui est inefficace. Il a été démontré que l’investissement dans une formation à la sécurité juste à temps — grâce à laquelle un développeur peut suivre une microleçon pour comprendre les risques liés à une vulnérabilité spécifique et apprendre à la corriger, par exemple en résolvant un problème repéré dans son propre code — améliore les résultats en matière de sécurité. Snyk Learn en est un exemple. Pourtant, seule environ la moitié des organisations étudiées y ont recours.

Par ailleurs, des études ont régulièrement démontré l’efficacité des programmes de Security Champions, qui visent à intégrer directement les connaissances en sécurité au sein des équipes d’ingénierie logicielle. Pour cela, un développeur de chaque équipe reçoit une formation approfondie et ciblée, ainsi que des ressources pour servir d’intermédiaire entre ses collègues développeurs et l’organisation AppSec. Comme les ingénieurs préfèrent apprendre auprès d’autres ingénieurs et que leurs pairs peuvent mieux intégrer les exigences de sécurité aux méthodes de travail de leur équipe, il a été démontré que les Security Champions réduisent les frictions avec l’AppSec et améliorent les résultats. Les organisations qui n’ont pas encore mis en place de programme de Security Champions — soit la moitié d’entre elles — risquent de continuer à rencontrer des difficultés dans leurs initiatives de sécurité pour les développeurs, faute de cette pierre angulaire essentielle à leur culture.

Moins de la moitié des organisations (46 %) déclarent pouvoir identifier avec précision leurs applications stratégiques.

Les risques sont généralement calculés en multipliant la probabilité par l’impact. Les outils d’analyse des vulnérabilités peuvent mesurer plus ou moins précisément la probabilité d’exploitation (en particulier s’ils prennent en compte des éléments supplémentaires, comme l’accessibilité et la maturité de l’exploit). En revanche, l’impact ne peut, par définition, être évalué que par l’entreprise. Un outil d’analyse de sécurité ne peut pas faire la distinction entre un problème de gravité élevée dans une application stratégique et la même vulnérabilité dans un service inutilisé qui alimente un ancien site promotionnel. Pourtant, les risques associés à ces deux problèmes sont radicalement différents.

Pour atteindre la maturité DevSecOps, les organisations doivent comprendre l’impact de leurs actifs logiciels sur leur activité et intégrer ces évaluations au calcul des risques afin de prioriser les problèmes. Les outils de gestion des configurations tels que les bases de données de gestion des configurations (CMDB) servent souvent à tenir à jour un inventaire des dépôts de code, des images de conteneurs, des déploiements et d’autres artefacts. Ils peuvent également faire autorité pour l’évaluation de la criticité métier. Les plateformes d’orchestration de la sécurité, notamment les solutions ASPM comme Snyk AppRisk, peuvent ensuite intégrer ces données à leurs algorithmes de priorisation fondée sur les risques.

La majorité des organisations interrogées qui peinent à identifier leurs logiciels stratégiques font face à un double problème : elles risquent de laisser trop de risques atteindre la production dans ces applications essentielles, dont l’exploitation aurait un impact considérable sur l’activité. Elles subissent également des processus de correction globalement inefficaces, car elles ne peuvent pas facilement déprioriser les corrections concernant les applications dont l’impact est très faible. La maturité DevSecOps exige des outils et des processus qui accordent une place centrale à l’impact sur l’activité dans tout calcul des risques.

Seules 31 % des organisations déclarent appliquer automatiquement les exigences de sécurité à plusieurs étapes du SDLC, avant la mise en production.

Notre étude révèle que la plupart des organisations ont entièrement documenté les profils de risque de leurs logiciels et peuvent les appliquer automatiquement. Toutefois, pour la cohorte la plus importante (40 %), cette application des règles n’a lieu que dans l’environnement de production ou d’exécution. Un nombre comparativement plus faible d’organisations prennent l’initiative d’appliquer leurs politiques à plusieurs étapes du SDLC, dans des environnements de préproduction isolés. Point crucial : même dans les cultures DevSecOps matures, la plupart des avantages d’une correction rapide et précoce des problèmes de sécurité sont ainsi perdus.

On sait depuis longtemps en sécurité que le coût de correction des problèmes augmente à mesure que le logiciel progresse de gauche à droite dans le cycle de développement. Si seules certaines politiques de sécurité sont appliquées en préproduction (dans les pipelines CI/CD, lors des vérifications des demandes de fusion ou dans les environnements de préproduction, par exemple), la plupart des problèmes donneront lieu au processus de correction le plus coûteux qui soit.

Il faut trouver un équilibre entre le coût de correction et la précision de la détection. Détecter les problèmes plus tôt dans le SDLC accélère et optimise leur correction, car les boucles de rétroaction vers les flux de travail des développeurs sont plus courtes. Cependant, plus un logiciel se rapproche de la production — lorsqu’il est compilé, empaqueté et déployé dans des environnements de test de plus en plus proches de la production — plus il est facile d’évaluer les risques et plus les analyses de sécurité sont précises. Il n’existe pas de moment « idéal » pour effectuer les tests de sécurité dans un SDLC orienté DevSecOps. Le meilleur équilibre entre précision et efficacité repose plutôt sur plusieurs points de contrôle de sécurité légers, qui appliquent des politiques à chaque étape en fonction des modifications apportées au logiciel. Les organisations qui n’appliquent leurs règles de sécurité qu’à une seule étape doivent sacrifier soit la précision, soit l’efficacité des corrections, ce qui freine leur progression vers la maturité DevSecOps. 

Seules 25 % des organisations déclarent que les alertes de sécurité sont envoyées uniquement aux parties prenantes concernées et comprennent tout le contexte nécessaire pour agir.

La fatigue liée aux alertes est une cause majeure de friction en matière de sécurité. Trop d’alertes ou de notifications, en particulier celles qui semblent peu pertinentes ou demandent un effort supplémentaire pour être interprétées, sont facilement ignorées. À terme, cela peut entraîner une perte de confiance envers l’outil de sécurité qui génère ce bruit, même si les alertes deviennent ensuite plus ciblées. C’est pourquoi il est essentiel d’éviter la fatigue liée aux alertes pour faire progresser les pratiques DevSecOps.

Les trois quarts des organisations reçoivent des notifications auxquelles il est impossible de donner suite efficacement. Souvent, elles manquent de contexte, ne sont pas envoyées aux bonnes personnes ou ne proposent pas de mesures claires et fiables pour résoudre le problème. Ce chaos d’alertes peut être dû à la concurrence de plusieurs outils de sécurité cloisonnés, qui sollicitent les mêmes parties prenantes et réduisent leur capacité à traiter les notifications qui nécessitent réellement une action.

La réponse et la correction constituent l’un des six piliers du cadre de maturité DevSecOps de Snyk. Toutefois, toute stratégie de réponse reproductible doit d’abord s’appuyer sur un flux d’alertes capable de déclencher rapidement et de manière fiable une action décisive de la part des personnes concernées. Les organisations incapables de résoudre le problème de la fatigue liée aux alertes découvriront rapidement qu’elles ne peuvent pas mettre en place des boucles de correction fiables, qui s’améliorent au fil du temps.

Seuls 37 % décrivent leur programme DevSecOps comme « transparent et en libre-service du point de vue des ingénieurs, ce qui facilite la sécurisation et complique l’introduction de risques logiciels ». 

L’un des principaux décalages sur la voie de la maturité DevSecOps concerne peut-être la compréhension de l’expérience des développeurs. Au départ, la promesse du DevOps (avant l’ajout de « Sec ») consistait à faciliter la vie des développeurs en leur fournissant les outils nécessaires pour accomplir des tâches qui exigeaient jusque-là l’aide des équipes informatiques centrales. Empaqueter des logiciels, déployer des applications ou configurer une infrastructure : les développeurs pouvaient désormais tout gérer eux-mêmes, simplement en écrivant du code. Cette évolution vers le libre-service grâce à des processus automatisés et reproductibles est devenue un pilier du développement logiciel moderne et a considérablement réduit les délais de mise sur le marché.

Cependant, les progrès en matière de sécurité n’ont pas suivi le même rythme. Le concept de « DevSecOps » existe depuis plus de dix ans, mais il repose souvent sur des outils et des processus AppSec hérités, incompatibles avec les pratiques actuelles des développeurs. Ce décalage nuit à leur expérience. Si les ingénieurs peuvent facilement gérer leurs conteneurs, leurs tests automatisés et leurs services cloud, ils doivent souvent attendre que les analyses de sécurité s’exécutent en dehors de leur flux de travail, ce qui rend les corrections plus coûteuses et crée des tensions constantes avec les équipes AppSec.

Ce manque de transparence et de libre-service complique la gestion efficace des risques logiciels par les développeurs. Au lieu de prévenir les problèmes en amont, ils doivent souvent deviner quelle est l’option sécurisée, puis corriger les problèmes lorsqu’il est le plus coûteux de le faire. Autrement dit, il est facile d’introduire des risques et difficile de sécuriser les logiciels. Pour rompre ce cycle, le véritable DevSecOps doit adopter des principes de « sécurité dès la conception » et proposer aux développeurs des parcours balisés qui leur permettent de gérer les risques en libre-service et d’avoir confiance dans la sécurité de l’option par défaut.

Le DevSecOps a considérablement évolué depuis ses débuts. Nos recherches montrent que la plupart des organisations sont bien engagées sur la voie de la maturité, mais qu’il reste d’importants progrès à réaliser pour concrétiser la promesse d’une pratique de sécurité fiable, automatisée et centrée sur les développeurs.

Vous souhaitez faire progresser votre programme DevSecOps ? Téléchargez l’e-book dès aujourd’hui.