DevSecOps : l'importance de la chaîne d'approvisionnement

Si le DevOps rationalise la mise à disposition de logiciels de façon à ce que les problématiques d'exploitation soient identifiées dès la phase de développement, le DevSecOps ajoute une approche "sécurité intégrée" dans la chaîne.

Pendant plusieurs années, le DevOps a été la méthodologie de référence pour le développement d'applications en entreprise. Cette démarche avait pour objectif de rapprocher les personnes en charge du développement logiciel (dev) à celles gérant l'administration des infrastructures informatiques (ops), afin d’aligner l’efficacité opérationnelle et l’excellence applicative tout au long du cycle de vie d’une application.

À cette époque, la principale problématique rencontrée était la non-concordance entre les applications fournies et les besoins opérationnels. L’objectif était donc de renforcer la collaboration entre les équipes de façon à atteindre les objectifs recherchés. Or, les débuts de cette méthode ont été difficiles tant les mentalités étaient ancrées dans des habitudes d’interactions faibles et de travail en silos. Cette méthodologie est néanmoins devenue performante, entre autres grâce à l’automatisation et la transformation des processus.

Une nouvelle donne dans la chaîne d’approvisionnement logicielle : la sécurité

Au fur et à mesure que le DevOps a gagné en maturité, la sécurité s’est révélée être le maillon faible de la chaîne d’approvisionnement logicielle. Si le DevOps rationalise la mise à disposition de logiciels de façon à ce que les problématiques d’exploitation soient identifiées dès la phase de développement, le DevSecOps ajoute une approche "sécurité intégrée" dans la chaîne.

Ceci est d’autant plus important que les développeurs s’appuient souvent sur des services tiers ou open source. Il est donc crucial de vérifier et de s’assurer que, quel que soit le code intégré à la chaîne, il est conforme aux exigences de sécurité. Dans ce contexte, les risques doivent être identifiés et gérés très en amont dans le processus afin d’y remédier le plus rapidement possible pour tuer dans l’œuf toute possibilité d’intrusion.

Estimer qu’il suffit d’installer les bons outils, de créer et d’automatiser des chaînes d’approvisionnement sécurisées, et d’embaucher un responsable des produits de sécurité serait simpliste.

Passer du DevOps au DevSecOps, un défi de taille

L’approche DevSecOps, est la phase où certaines politiques sont appliquées et où différents composants du logiciel sont remplacés. Par exemple, en cas de problème de sécurité, une chaîne d’approvisionnement logicielle sécurisée permettra de recréer les applications en y incluant des patchs pour chaque système d’exploitation et framework, sans avoir à déranger les développeurs. Enfin, il existe une dimension supplémentaire qui est celle de la livraison continue permettant d’automatiser la mise en production des applications. À ce stade de la chaîne d’approvisionnement logicielle, la gestion de la sécurité consiste à s’assurer que les inputs (le code, les configurations et les frameworks et services tiers) sont sûrs et respectent la politique de l’entreprise.

Mais avant toute chose, et comme pourrait en témoigner nombre de RSSI et autre expert en sécurité, il convient d’abord de bien comprendre les compromis entre fonctionnalités et politique de sécurité, la stratégie et les plans de gestion des risques, ainsi que les menaces. La sécurité ne se limite pas aux bugs et aux hackers. Dans un contexte de DevSecOps, ces efforts de compréhension doivent être concentrés sur les objectifs des logiciels créés et leur utilisation. Tout d’abord, il est indispensable d’évaluer le travail de chaque entité pour s’assurer que toutes les parties prenantes répondent aux nouvelles attentes de l’entreprise : celles du DevSecOps. 

Pour ce faire, il est donc essentiel de commencer en examinant l’ensemble du cycle menant à la mise en production des logiciels c’est-à-dire de l’idée au code, en passant par la sécurisation, le déploiement, la mise en production et l’utilisation de ladite fonctionnalité. Il faut noter la durée de chacune de ces activités, et le délai entre chacune d’entre elles. Ce délai représente le temps de latence qui correspond généralement au transfert de responsabilité d’une équipe à une autre. Le fait de cartographier le processus permet de l’optimiser tout en mettant en exergue les potentiels dysfonctionnements et domaines d’amélioration.

Par ailleurs, cette démarche assure également une meilleure collaboration entre les équipes et une coordination poussée de la gestion du cycle de vie d’une application donnée. Ce n’est qu’une fois cette étape franchie qu’il sera possible d’intégrer une nouvelle dimension désormais incontournable : la sécurité. En améliorant les outils et processus tout au long de la chaîne, il devient possible d’accélérer la mise en production, mais également et surtout d’intégrer une véritable stratégie de sécurité formalisée par une politique d’entreprise et mise en œuvre avec davantage de contrôles.