Cette dernière décennie a ouvert la voie à la révolution DevOps. Les nouvelles versions des logiciels et des applications sont dorénavant des process, avec un nouveau code déployé en continu. Pendant ce temps, les équipes DevOps se sont affranchies de l’approche traditionnelle cloisonnée, et assument une plus grande partie du cycle de développement, y compris les tests de qualité, l’intégration et le déploiement. Cependant, malgré ce changement, il reste un élément majeur dans l’approche DevOps qui est la sécurité.

Historiquement, les développeurs étaient simplement chargés d’écrire du code pour exécuter une fonction spécifique, et la qualité du produit final ne faisait pas partie de leur préoccupation, car elle relevait de l’équipe d’assurance qualité. Le modèle DevOps est né de la prise de conscience que cette façon de travailler n’était tout simplement plus tenable. Grâce aux progrès du Cloud, de la virtualisation et des microservices, les applications n’ont plus besoin d’être constamment transférées à d’autres services et peuvent désormais être créées et déployées par la même équipe. Ainsi, la responsabilité du produit final incombe aux DevOps, notamment en termes d’expérience utilisateur, de rapidité et de résilience, plutôt que de se limiter à ses fonctionnalités.

Cependant, les attitudes à l’égard de la sécurité sont toujours bloquées dans l’ancien monde. Bien que le DevOps ait assumé des responsabilités qui incombaient auparavant à d’autres équipes afin de rendre plus efficace le cycle ininterrompu des versions de logiciels, la croyance générale veut que l’équipe de sécurité soit la seule responsable de la protection des produits de DevOps. Cela peut être dû à des raisons culturelles ou organisationnelles liées à la perception du pouvoir et de la centralité de l’équipe de sécurité dans de nombreuses entreprises. Il n’en reste pas moins que la révolution DevOps ne sera pas complète tant que la sécurité ne sera pas pleinement intégrée au processus de développement logiciel.

À bien des égards, c’est une évidence. Si le DevOps est désormais responsable de la qualité du produit et de l’optimisation des performances de l’application, il doit également s’assurer que le code ne contient pas de problèmes ou de portes dérobées susceptibles d’affecter la sécurité. Si l’on construit une voiture sans aucun défaut, à l’exception de sa tendance à prendre feu quand elle roule vite, on conclura que la qualité de sa conception est défectueuse. Un produit n’est pas adapté à son usage s’il ne remplit pas en toute sécurité la fonction attendue. Il en va de même pour un site web qui peut être facilement piraté par des auteurs malveillants parce qu’on n’a pas fait suffisamment d’efforts en matière de sécurité pour protéger son code avant sa publication. Si les coordonnées des cartes de crédit de vos clients sont volées, vous pouvez être sûr que vous avez un problème de qualité.

En raison de l’omniprésence de l’équipe de sécurité, l’équipe DevOps pouvait auparavant se contenter de rester en retrait et de laisser ces personnes « faire leur travail ». Mais la sécurité étant un élément majeur de la qualité des produits, ce n’est plus l’état d’esprit à adopter. Si le site Web ou l’application qui a été lancé(e) est piraté(e) ou infecté(e), le DevOps sera probablement tenu pour responsable plutôt que l’équipe de sécurité. Dire que les DevOps ne doivent pas s’inquiéter de la sécurité de leur code parce qu’une autre équipe s’occupera du problème est similaire au fait de ne pas tenir compte des dépenses d’un projet parce qu’il existe un département financier.

Plutôt que de considérer la sécurité du développement logiciel comme un fardeau supplémentaire, le DevOps devrait y voir une opportunité d’étendre son autorité et son efficacité au sein de la structure organisationnelle. Au lieu d’attendre que la sécurité impose des outils et des processus, les équipes DevOps peuvent trouver et sélectionner de manière proactive les solutions dont elles ont besoin pour écrire, configurer et déployer un code sécurisé dès le départ.

Après tout, les DevOps sont les mieux placés pour comprendre quels sont les outils les plus utiles à adopter dans les phases initiales de création de code, et lesquels renforceraient leur capacité à travailler de manière agile. Se voir imposer quelque chose « d’en haut » ne sera jamais la meilleure façon de travailler.

Par le passé, la manière dont la fonction de sécurité a été présentée aux développeurs et à l’ensemble de l’entreprise a posé problème. Il fut un temps où les risques et les menaces pesant sur l’entreprise et sa présence en ligne semblaient se multiplier de manière exponentielle, et où les entreprises étaient contraintes de réagir en déployant des produits correctifs toujours plus complexes. A tel point que la sécurité informatique est devenue une vraie discipline et une industrie à part entière. En fait, d’autres acteurs de l’informatique, comme les développeurs, ont souvent eu le sentiment que la sécurité était trop éloignée de leur compréhension et de leurs attributions.

Cependant, il faudrait aller de l’avant. Avec le mantra dominant selon lequel prévenir est toujours mieux que guérir, et que la sécurité doit adopter des pratiques plus « shift-left » pour être vraiment efficace, les DevOps pourraient être surpris de découvrir à quel point leur équipe de sécurité serait réceptive au partage des responsabilités et à un travail plus collaboratif. Si l’équipe chargée de la sécurité peut superviser les parties pertinentes du processus DevOps et y contribuer, elle ne devrait plus avoir à faire face à un code qui a été écrit sans tenir compte de la sécurité.

Le DevOps doit considérer la sécurité comme une facette essentielle de la qualité et des performances des logiciels. Il existe des signes évidents d’un mouvement dans cette direction, notamment avec l’émergence récente de la culture dite DevSecOp. Pourtant, il s’agit là d’une erreur d’appellation, car la « sécurité » ne devrait pas être un élément distinct mis en évidence dans le cadre du processus DevOps ; elle devrait plutôt faire partie intégrante de toutes les activités DevOps.

Tant que cela ne sera pas fait, la révolution DevOps sera incomplète.
___________________

Par Xavier Duros, CTO de Check Point Software France

 

NE MANQUEZ PAS LA MATINALE IT FOR BUSINESS
DU MERCREDI 19 MAI 2021 (en virtuel, dès 09H30)

 

LE DEVSECOPS, LA PROCHAINE ETAPE

Pour s’inscrire gratuitement : Les Matinales IT For Business – Le DevSecOps, prochaine étape