Pourquoi les CTOs doivent s'intéresser au DevSecOps

Bien que le besoin du DevOps ait été démontré, l'environnement de développement logiciel suscite de nouvelles exigences de sécurité. Pour que les entreprises restent à la fois compétitives et résilientes, les équipes de sécurité doivent désormais être beaucoup plus intégrées aux équipes de développement.

Le monde du numérique devient chaque jour plus concurrentiel, et développer de solides pratiques DevOps est désormais vital pour créer et opérer des services leaders sur le marché. Cependant, le domaine de la sécurité, en particulier, a connu de profonds changements au cours de ces dernières années. Tout d'abord, le monde numérique est devenu beaucoup plus risqué. Nous assistons actuellement à une avalanche de cyberattaques et, que vous soyez un particulier ou une entreprise, ce risque est bien réel. Chaque entreprise doit anticiper ces dangers car toute faiblesse dans son architecture ou ses processus sera exploitée. Outre cette augmentation inquiétante du nombre de menaces, l'introduction, à juste titre, d'une réglementation accrue en matière de confidentialité des données change la donne. Désormais, les entreprises qui ne parviennent pas à gérer la donnée de manière adéquate ou à en garantir l’intégrité s'exposent à de sérieux risques économiques.

Débuter avec de petits changements

Tout d'abord, il est important de réaliser que les pratiques DevSecOps relèvent d’un parcours continu qui commence par de petites étapes. Les dirigeants d'entreprise peuvent commencer à prendre la voie DevSecOps en conviant des experts en sécurité dans leur cercle. Ensemble, les équipes peuvent alors passer en revue un récent retard sur un projet ou un incident dans lequel la sécurité a joué un rôle. Au cours de ces conversations, il est important de prendre le temps de comprendre les objectifs du groupe de sécurité et d’intégrer les objectifs DevOps aux leurs. Il en résulte des opportunités gagnant-gagnant : des domaines ciblés dans lesquels les responsables de la sécurité peuvent contribuer au développement des logiciels, tout en réalisant leurs propres objectifs.

Viser les projets faciles à fort impact

L’enquête DevSecOps de Datadog comporte des informations et des opportunités clés pour permettre aux dirigeants de faire progresser les projets de leur entreprise.

Par exemple, un élément majeur de la méthodologie DevSecOps est le "shift left", une approche qui consiste à introduire des contrôles, des pratiques et une expertise en matière de sécurité beaucoup plus tôt dans le cycle de développement et de livraison des logiciels. D'après les résultats de l'enquête, les pratiques de "shift-left" sont étonnamment peu répandues. Parmi près de 400 réponses obtenues dans l’échantillon de Datadog, nous avons découvert que :

Seulement 33% des entreprises procèdent à une évaluation des risques ou effectuent une modélisation des menaces pour chaque nouveau service dans le cadre de la phase de conception.
Seulement 50% effectuent une analyse statique du code (par exemple, du test statique de la sécurité des applications, ou SAST) pendant la phase de développement afin d'empêcher les “commits” de code vulnérables.
À peine 35% effectuent du scan dynamique de code (par exemple, du test dynamique de la sécurité des applications, ou DAST) sur un code en intégration continue afin d'arrêter le packaging d’un code vulnérable.

L'intégration de ces contrôles au plus tôt dans les pipelines de livraison d’application doit être considérée comme une priorité pour chaque membre de la chaîne de valeur. On compte d’ailleurs un grand nombre de prestataires dont les services facilitent la mise en œuvre de tels changements.

L’entraînement et la pratique sont l'autre grand domaine au sein duquel on constate des lacunes dans les pratiques actuelles. Selon l'enquête de Datadog :

Seulement 17% des entreprises effectuent des tests de chaos ou des "game days" sur les infrastructures et applications en production.
28% effectuent des tests "red teams" / simulation d'adversaires pour améliorer les capacités de détection et d'opérations de sécurité.
Seules 43% ont mis en place une stratégie de reprise après sinistre testée à intervalles réguliers.

Se lancer dans de telles pratiques n’est pas onéreux, surtout si les dirigeants prennent en compte le retour sur investissement. Effectuer des exercices de simulation et décrire étape par étape la façon dont l’entreprise réagirait en cas d'incident de type ransomware (ou autre événement lié à la cybersécurité) sont autant de pratiques qui donneront à l’entreprise l'occasion d'observer et d'éliminer les hypothèses erronées ou les lacunes dans la conception ou les processus. Il est primordial de garder à l’esprit que dans le climat actuel, la question n'est pas tant de savoir si, mais plutôt quand un cyber-incident se produira. S'entraîner à réagir à ces événements permet d'aiguiser les compétences des équipes et de faciliter la continuité des activités avec des temps d'arrêt réduits.

Se concentrer sur les personnes, pas sur les outils

On peut pardonner aux dirigeants de croire que le terme DevSecOps fait référence à un outil ou un ensemble d'outils. En effet, nombreuses sont les offres de services qui leur promettent de faire des économies et de leur donner l’assurance nécessaire pour faire face à un contexte de plus en plus dangereux et à une économie de plus en plus réglementée. Avec tout ce qu’on entend, il est facile de ne pas se rendre compte que la notion de DevSecOps relève avant tout d’un état d'esprit, d’une façon de travailler ensemble qui aide l’entreprise à différents niveaux : consolidation de la livraison des logiciels, amélioration du service client, plus grande agilité, meilleure conduite du changement.

Encourager un état d'esprit qui fait de la sécurité un enjeu de premier plan prend du temps, et mesurer les progrès effectués est un facteur de motivation précieux. Une méthode très efficace consiste à créer un tableau de bord qui répertorie les compétences et les pratiques liées aux objectifs DevSecOps. L’entreprise peut ensuite dresser sur ce tableau de bord la liste des équipes en charge de chaque compétence ou pratique, comme par exemple, qui effectue des scans de vulnérabilité et qui ne le fait pas. Voir leurs noms et leurs niveaux de performance affichés sur un tableau de bord motive les équipes et leur donne envie de s'améliorer.

Une autre manière de privilégier les personnes plutôt que les outils est simplement d’interroger les équipes lors du passage en revue des services et/ou des échéances de projet. Il s’agit de leur poser des questions sur les résultats de leurs scans et de les encourager à partager leurs réussites et leurs difficultés avec les autres équipes. Cette approche axée sur les personnes permet d'encourager la montée en compétences, de renforcer le sentiment de responsabilité et de mettre en œuvre des changements de processus. Par exemple, le fait de se renseigner sur les scans de vulnérabilités et de les normaliser par la suite permet de modifier les règles de déploiement et d'automatiser les mises en production en fonction des résultats de ces scans.

DevSecOps est une bonne pratique d’entreprise. Au fur et à mesure que les processus de l’entreprise évoluent et que la sécurité commence à faire partie intégrante de ses équipes et de ses solutions, de nouvelles opportunités s'ouvrent à elle. Sa nouvelle force et son agilité donneront à l’entreprise un avantage concurrentiel, tout en assurant sa sécurité et celle de ses clients.