DevSecOps : comment intégrer la sécurité durant tout le cycle de développement


Temps de lecture : 4 minutes
Share Button
DevSecOps - ORSYS

Dans le prolongement de la démarche DevOps, DevSecOps consiste à intégrer le principe de sécurité durant tout le processus de livraison continue. Cela suppose de former les équipes opérationnelles aux risques et de recourir à des outils d’automatisation des tests.

Apparue il y a maintenant dix ans, l’approche DevOps est désormais bien ancrée dans les mœurs. Elle consiste à rapprocher, au sein d’une DSI, les équipes de développement – les « dev » – et de production – les « ops » – afin de raccourcir les délais de livraison. Gagner en agilité pour accélérer la mise en production ne doit toutefois pas se faire au détriment de la qualité ou de la sécurité. Plus récent, le mot-valise « DevSecOps » (développement, sécurité, opérations) consiste à intégrer ce principe de sécurité tout au long du processus de livraison continue.

Sécurité, tous responsables ?

Préoccupées par les aspects fonctionnels d’une application puis de son exploitation, les équipes informatiques relèguent souvent la prise en compte de sa sécurité en bout de chaîne, une fois que le produit est livré. Pourtant, des failles peuvent être introduites dès les premières lignes de code. Inhérente à DevOps, l’automatisation qui permet d’augmenter les cadences de livraison peut également être source de nouvelles vulnérabilités.

DevSecOps fait de la sécurité une responsabilité partagée. Elle ne relève pas du seul RSSI, et est intégrée du début à la fin du cycle de production. Cette démarche de « secure by design » existe déjà depuis plus longtemps dans les industries sensibles telles que l’aéronautique. Elle fait aussi écho au principe du « privacy by design » introduit par le RGPD. Il consiste à prendre en compte le respect de la vie privée dès le début d’un projet faisant appel à des données personnelles.

Sensibilisation aux bonnes pratiques

Ce changement culturel passe tout d’abord par la formation des développeurs, des administrateurs et autres architectes aux enjeux de cybersécurité. Sans aller jusqu’à la certification, la norme ISO 27001 dédiée au management de la sécurité introduit des bonnes pratiques. Elle permet de procéder à une analyse des risques puis de prendre les mesures de sécurité adaptées.

L’annexe A de ce standard contient ainsi 114 points de contrôle. Ils sont répartis en 14 sections comme le contrôle des accès, la cryptographie ou la gestion des incidents. Conforme à ISO 27001, l’ANSSI propose sa propre méthodologie de gestion du risque. Elle est baptisée EBIOS pour Expression des besoins et identification des objectifs de sécurité.

Complémentaire à ISO 27001, ISO 27005 traite plus spécifiquement de la sécurité des systèmes d’information. Cette norme s’inscrit dans une logique d’amélioration continue en quatre phases : plan (identification des risques), do (exécution des mesures), check (contrôle du résultat) et act (révision de la politique de sécurité en fonction des résultats).

Automatisation des tests

Une stratégie DevSecOps passe aussi par le recours d’outils capables d’assurer l’intégration continue de la sécurité dans un environnement commun de développement. Il s’agit d’industrialiser les contrôles de sécurité afin d’éviter que chaque développeur le fasse manuellement dans son coin.

Il existe deux grandes familles de solution de testing :

1. les outils de test statique de sécurité des applications (SAST, Static Application Security Testing). Ils analysent le code pour y détecter des erreurs de programmation pouvant laisser passer des bombes logiques ou des injections SQL.

2. les outils d’aide de test dynamique de sécurité des applications (DAST, Dynamic Application Security Testing). Ils analysent l’application en cours d’exécution en interagissant avec elle comme le ferait un hacker. Ce qui permet de tester sa résilience en conditions réelles, en prenant en compte le code mais aussi l’infrastructure sous-jacente.

Une fois l’application en production, la vigilance doit rester de mise. En effet, une menace inconnue ou « zero day » peut toujours survenir. La DSI doit alors se doter de solutions lui permettant de détecter tout comportement anomal du code.

41 % des DSI ont un projet DevSecOps

Comme on peut le voir, initier une démarche DevSecOps exige un investissement initial élevé, entre la formation et l’outillage. Mais il doit être mis en regard avec les risques d’une cyberattaque ou tout simplement le coût d’une réécriture du code applicatif. « Plus un bug est détecté tardivement dans le cycle de vie d’une application, plus le coût de résolution est élevé. », estime Guillaume Alex, « DevSecOps evangelist » chez Micro Focus. « En effet, un bug de sécurité́ repéré en production coûte cent fois plus cher à résoudre que lorsqu’il a été détecté dans la phase de spécification. »

Selon une récente étude réalisée par Micro Focus auprès de 2 000 décideurs informatiques en France, 41 % des entreprises ont un projet DevSecOps à moyen ou long terme. Les contraintes légales liées à la protection des données personnelles (RGPD) et la croissance exponentielle des incidents de cybersécurité incitent les DSI à aller dans cette voie. Selon la même étude, 69 % des répondants admettent avoir déjà subi des incidents de sécurité.

Les 2/3 des sondés n’intègrent pas encore la sécurité dès le début de la phase de développement. Principalement par manque de compétences (66 %) et de budget (45 %). De surcroît, 67 % des équipes de sécurité n’interviennent que ponctuellement dans le cycle applicatif.

La question n’est donc plus tellement de savoir si une entreprise doit se pencher sur le sujet sécurité dans son ensemble mais plutôt quand elle va enfin s’y mettre !


Pour se former :

DevOps, méthode et organisation

Hacking et sécurité

Implémenter et gérer un projet ISO 27001:2013

ISO 27005:2018 Risk Manager, préparation à la certification [analyse de risques]

Share Button

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *