L’approche « Shift left » existe depuis plus de 20 ans et consiste en une pratique essentielle pour détecter les problèmes de code plus tôt dans le cycle de développement et réduire ainsi les coûts. Ce concept est issu du modèle en cascade où le département sécurité était surnommé le “Release Prevention Department”. Les développeurs travaillaient alors beaucoup pour développer un nouveau produit mais étaient bloqués juste avant sa sortie ou, pire encore, des clients découvraient d’importantes failles lors de la mise en production.
Avis d’expert de Tim Johnson, Director, Product Marketing chez CloudBees – Ce n’est que plus tard que le « Shift Left » est entré dans le monde de la sécurité, devenant même un mantra DevOps lors du rassemblement Rugged DevOps qui s’est tenu à San Francisco en 2017. Cela a rapidement été suivi par l’émergence de DevSecOps, où non seulement les tests étaient effectués plus tôt, mais où les équipes de sécurité étaient « intégrées » au processus pour apporter leur expertise et accélérer la livraison de logiciels de qualité.
Alors, l’approche « Shift Left » a-t-elle tenu ses promesses ? Placer la sécurité et la conformité plus tôt dans le processus a-t-il permet de générer des événements automatisés et en libre-service ? Les équipes de sécurité, les développeurs et les contrôleurs collaborent-ils mieux désormais ? Malheureusement, pas vraiment.
De nouvelles données préoccupantes sur le “Shift Left”
Un récent sondage effectué auprès des responsables sécurité indique en effet que cette approche n’a pas tenu toutes ses promesses. Si 33 % des sondés affirment la pratiquer et 44 % répondent le faire « probablement », près de 60 % déclarent tout de même que cela représente une charge pour les développeurs. Mais le « Shift Left » n’est qu’une pièce du puzzle puisque la même étude a révélé qu’environ la moitié des dirigeants pensent que les processus de conformité et de sécurité (56 %) et les connaissances liées à ces domaines (47 %) empêchent leur équipe de développement de consacrer plus de temps aux activités prioritaires. Ils pensent même que les exigences en matière de sécurité (75 %) et de conformité (76 %) freinent l’innovation.
La pratique du « Shift Left » a un impact significatif sur la livraison des logiciels et sur l’expérience globale des développeurs. Dans l’ensemble, les dirigeants déclarent que leurs équipes consacrent plus de la moitié de leur temps à la gestion des risques et à la maintenance technique, et moins de 30 % à l’innovation. Imposer aux développeurs des charges supplémentaires en matière de sécurité et de conformité ne fera que réduire leur disponibilité pour effectuer des tâches à plus forte valeur ajoutée.
Comment en est-on arrivé là ?
Lorsque le concept est apparu, le code était monolithique. Les environnements étaient documentés et familiers et seuls quelques outils de test étaient à disposition des développeurs. Les exigences réglementaires et de gouvernance évoluaient lentement, et les environnements encore moins. Le code était même presque entièrement développé en interne. Tout évoluait alors à un rythme tranquille et il était relativement simple pour un développeur de comprendre les résultats d’un test, d’apporter les modifications nécessaires au code et d’avancer par la suite.
De nos jours, les entreprises n’écrivent qu’environ 30 % du nouveau code. L’open source constitue la majeure partie des applications, et les environnements, les exigences et les normes évoluent à un rythme effréné. Si l’on ajoute la pléthore d’outils de test que les développeurs doivent désormais utiliser ainsi que le besoin de déchiffrer le flux de résultats provenant de tous ces outils – aussi appelé les « alert storms », il devient extrêmement difficile pour un développeur ou même une équipe de gérer convenablement ces tâches. Comment peuvent-ils comprendre comment réagir, identifier les vrais problèmes par rapport aux fausses alertes, et prioriser leur travail ? C’est ici que commence le paradoxe que nous appelons la taxe de conformité.
Le « Shift Left » est contreproductif pour DevOps
Au lieu de simplifier les choses, de rationaliser les flux et de faciliter les opérations, les équipes consacrent plus de temps aux tâches sans valeur ajoutée qu’à l’innovation. Aucun développeur n’aime traduire une politique de gouvernance en code, déchiffrer des milliers d’alertes de sécurité critiques, ou voir les messages Slack de l’équipe d’audit.
De nombreux dirigeants et CISO considèrent que le « Shift Left » représente donc un fardeau pour la gestion des risques. Il est en effet trop difficile de trouver des données et celles dont ils disposent sont obsolètes. Ils ne peuvent pas voir l’ensemble du processus ni connaître avec certitude leur position en matière de risques. La taxe de conformité est également vue comme un obstacle majeur à la réalisation du ROI sur les efforts de transformation numérique.
Une pratique adéquate du « Shift Left »
Détecter les problèmes à un stade précoce et les résoudre avant qu’ils ne ralentissent le cycle ou n’entrent en production reste l’objectif majeur du « Shift Left ». Cependant, pour atteindre cet objectif, il convient d’adopter un nouvel état d’esprit, une nouvelle approche et une automatisation innovante. Alors, comment faire pour que le « Shift Left » soit efficace ? Trois éléments semblent essentiels :
- Les équipes chargées de la sécurité et de la conformité doivent déclarer ce que « sûr et sécurisé » signifie pour l’entreprise, puis faire correspondre leur politique à l’automatisation.
- Un système qui fonctionne en continu sur l’ensemble de l’entreprise et du cycle de livraison des logiciels (SDLC), y compris la production, et qui compare le parc numérique à ces politiques et aux exigences réglementaires.
- Enfin, un système qui fournit le contexte de toute menace ou de tout problème détecté par rapport à l’étape du SDLC, le profil de risque de l’application et à l’impact sur les services critiques de l’entreprise.
Une autre approche est de se concentrer sur les résultats. Il existe plusieurs manières de savoir si le « Shift Left » est appliqué correctement. Premièrement, si les développeurs sont libérés des « alert storms », ils peuvent se concentrer sur l’innovation.
Ensuite, les équipes chargées de la sécurité et de la conformité améliorent la compréhension du risque et accélèrent le développement, passant du statut de “département lent” à celui de “département actif”. Enfin, les dirigeants peuvent évaluer l’exposition aux risques et le statut de conformité de leur entreprise, et faire valoir ce statut en toute confiance.