Introduction au DevSecOps

1. Bob le développeur

Nous pouvons résumer les missions de Bob en quatre axes principaux :

Bien entendu, cette liste n’est pas exhaustive et ne présente que les missions principales de Bob.

Seulement Bob doit souvent attendre des jours, des semaines et parfois des mois avant que son nouveau code ne soit déployé en production et mis à disposition des clients. Ce délai est induit par les contraintes de mise en production et les démarches administratives nécessaires, l’entreprise perd alors en compétitivité face à des concurrents qui n’auraient pas ce type de problématiques (notamment les start-up).

De plus, l’environnement de production (celui auquel le client accède) est parfois un peu différent de l’environnement au sein duquel Bob a développé son produit et ses nouvelles fonctionnalités. Cela peut ainsi occasionner des incidents, bugs et problèmes de compatibilité qui n’avaient pas été suffisamment anticipés en amont.

2. Alice l’opérationnelle

Dans l’entreprise Delta, nous allons également retrouver un autre acteur important : Alice l’opérationnelle. Elle occupe le poste d’administrateur système et réseau, dont les missions peuvent également être résumées sous quatre axes principaux :

Cependant, tout comme Bob, Alice rencontre un certain nombre de difficultés. Jusqu’à aujourd’hui, Alice utilisait des outils pour l’aider dans la réalisation de ses tâches. Ces outils, qui fonctionnaient bien lorsqu’il n’y avait que quelques équipements à administrer, deviennent peu à peu obsolètes avec l’augmentation du nombre de serveurs et d’équipements réseau… De plus, Alice doit également assister les utilisateurs...

1. Le « c » de la culture

La culture correspond au premier pilier et se concentre sur les exécutants techniques, les décisionnaires, les managers, ou encore la sécurité. En somme, toutes les personnes qui vont avoir une interaction avec le(s) produit(s) et service(s).

L’accent est mis sur les changements, la manière dont les mutations de structure et de culture au sein des équipes sont amenées, et surtout sur la capacité à évoluer vers une culture de l’expérimentation.

Cela signifie qu’il n’y a pas de problème à échouer, à commettre des erreurs, ou à ne pas réussir à atteindre l’objectif fixé. L’important est alors d’essayer, de gagner en connaissances et en maturité, permettant ainsi de ne pas réitérer les erreurs déjà commises. 

Au-delà de cette culture de l’expérimentation, il est nécessaire d’adopter une approche de résilience opérationnelle. Il s’agit de la capacité d’une entreprise à anticiper, réagir et surtout s’adapter aux changements et aux éléments perturbateurs, tout en conservant ses fonctions critiques. C’est dans ce but que sont mis en œuvre des plans de continuité d’activités (PCA) et de Disaster Recovery (DR).

2. L’automatisation : une méthode indispensable

Le second pilier autour duquel se concentre le DevOps correspond à l’automatisation. Même si ce pilier revêt une très grande importance, il ne résume pas à lui tout seul le DevOps.

Il est question, cette fois, de déploiement continu (CD) et d’intégration continue (CI), permettant d’automatiser la mise en production des nouveaux codes développés grâce à plusieurs phases de tests, de build et de scans.

La partie Ops, relative à l’infrastructure, peut, elle aussi, être automatisée avec les notions d’IaC, intimement liées au Cloud et à l’utilisation des technologies d’orchestration de conteneurs (notamment Kubernetes).

Il s’agit d’un des concepts fondamentaux du DevOps et du DevSecOps, qui doit être au premier plan de toutes les réflexions autour des développements et de l’infrastructure.

Ainsi, les questions que tout intervenant doit se poser pourraient être les suivantes :

3. Le Lean ou le zéro déchet

Dans l’industrie, notamment en automobile, le Lean est fondamental. En informatique, l’accent est mis sur la capacité à produire de la valeur, tout en diminuant les zones et les moments dans lesquels nous risquons de produire...

1. Le business d’aujourd’hui

De nombreux intervenants nous font de plus en plus savoir que l’IT est devenu le vrai business des entreprises aujourd’hui. En effet, existe-t-il une entreprise de taille importante dont l’informatique ne consiste pas en un poste de coût majeur, et en un département qui produit également de la valeur ?

Les demandes se font toujours de plus en plus nombreuses pour avoir des applications et des services à consommer rapidement (un peu comme les applications sur smartphone), et cela malgré des risques en cybersécurité qui apparaissent chaque jour. Il est rare de rester plus d’un mois sans entendre qu’un très grand groupe a été la victime d’une attaque informatique.

Comment continuer à produire rapidement des services et produits de forte qualité, tout en maintenant des conditions de sécurité élevées pour l’infrastructure et le code ? Le DevSecOps apparaît comme une réponse possible à cette équation.

2. Le fonctionnement dans « l’ancien monde » en silos

Pour délivrer des logiciels et effectuer du développement, les entreprises ont beaucoup fonctionné en silos (et nombre d’entre elles le font toujours aujourd’hui). C’est-à-dire qu’elles étaient (et sont parfois toujours) composées en équipes séparées, chargées de s’occuper d’une partie du système d’information : une équipe de développeurs, une équipe pour les systèmes Linux, une équipe pour la virtualisation, une équipe pour le réseau, une équipe pour les datacenters, une équipe pour la sécurité, etc.

Malheureusement, cette méthode de fonctionnement pose quelques problèmes. En effet, il devient impossible pour une équipe d’effectuer correctement son travail sans devoir interagir avec d’autres équipes. Mais, du fait de responsabilités qui ne sont pas clairement établies, il est souvent difficile de trouver la cause initiale de certains problèmes ou incidents qui peuvent apparaître sur les produits. Est-ce le code qui est en cause ? Le réseau ? Le système sur lequel le code est hébergé ? Les autorisations dans les flux de données ?

3. Les premiers changements apportés par le DevOps

Grâce à l’avènement du Cloud et du DevOps, les choses ont commencé à changer. En effet, les équipes de delivery regroupent désormais les développeurs, mais aussi les ingénieurs système et Cloud. Les échanges se font ainsi dorénavant à l’intérieur d’une seule et même équipe.

Les équipes Cloud peuvent alors fournir aux développeurs les bases d’automatisation, et de pipelines d’intégration et de déploiement continus leur permettant de travailler en autonomie, sans avoir...

1. Segmentation des environnements et des applications

Dans des environnements Cloud, nous pourrions être tentés, par facilité, de mettre tous nos environnements et toutes nos applications dans un seul et même VPC (Virtual Private Cloud).

Cependant, pour répondre aux bonnes pratiques de sécurité, il convient de mettre chaque environnement d’une application dans des VPC différents : un VPC de développement qui permet de se connecter aux autres VPC qui contiennent les environnements de préproduction et de production.

Il faut ensuite effectuer la même démarche pour toutes les applications, afin de respecter la segmentation des environnements.

2. Gestion des accès et des identités (IAM) sur le Cloud

La gestion des accès et des identités par les services IAM (Identity and Access Management) des fournisseurs de services Cloud est un enjeu extrêmement important.

En effet, elle permet aux équipes de développement d’effectuer des requêtes pour obtenir des accès spécifiques, avec la possibilité d’obtenir des comptes applicatifs et des rôles par l’IAM.

Un des gros avantages de ces attributions contrôlées (qui peuvent se faire via une interface web, avec création automatique) consiste à pouvoir ajouter ces comptes au fur et à mesure à un Cloud Profiler. Des scans sont ensuite effectués sur les comptes applicatifs pour...

1. Une nouvelle façon de travailler

Le DevSecOps modifie la façon de travailler des équipes, mais aussi de la partie business. En effet, par sa culture qui lui est propre, il implémente de nouveaux processus et de nouvelles technologies pour mener à bien les différentes tâches et problématiques auxquelles il a pour vocation de répondre.

Cette culture tourne autour de quelques principes importants, qui sont intimement liés au DevOps. En effet, la coopération entre les équipes, mais également entre le business et la technique, est indispensable à l’adoption de cette nouvelle organisation. Les éléments technologiques peuvent apporter des outils intéressants, permettant notamment l’automatisation de certaines tâches de sécurité, comme la capacité à effectuer du « Shift Left ». Enfin, tous ces éléments peuvent être mesurés afin de démontrer l’efficacité de ces nouvelles pratiques.

2. La règle du IN : Input, Involve et Invest (contribution, implication et investissement)

Plus les stakeholders (parties prenantes) sont impliqués tôt dans les processus, mieux les projets se déroulent. Cela permet d’identifier et d’anticiper les prérequis, les défis ou les risques inhérents.

En effet, lorsque ces contributions sont obtenues dès les premières étapes de la réalisation d’un projet, il devient possible d’obtenir des shorten feedback loops, c’est-à-dire des avis et des retours, très rapidement. Les équipes DevOps peuvent ainsi facilement s’adapter et ajuster leurs pratiques. En somme, il est possible d’éviter que l’équipe de développement ne parte dans une mauvaise direction et effectue du travail qui ne correspond pas à ce qui est souhaité.

Impliquer et sensibiliser les parties prenantes dès le début, dans les audits et la conformité, permet également de mieux cerner les impacts que peuvent avoir les politiques de sécurité sur l’architecture et l’implémentation des solutions.

C’est pour ces raisons qu’il est souvent nécessaire d’investir du temps dans l’architecture en amont, et dans les ressources qui vont devoir être mobilisées (y compris pour de la formation par exemple) afin de mener à bien l’ensemble des projets.

3. Le « Shift Left »

Il s’agit d’une approche qui a pour but de développer du code de qualité en effectuant des tests le plus en amont possible du cycle de développement.

Cependant, il n’est pas question uniquement de codes, mais aussi d’architecture globale, que ce soit l’architecture...

1. Introduction à l’IA générative

Durant les deux dernières années, vous n’avez pas pu passer à côté de l’émergence de cette nouvelle technologie : l’IA générative popularisée notamment par ChatGPT.

L’IA générative correspond à une branche de l’intelligence artificielle qui se concentre sur la capacité à générer et créer de nouveaux contenus à partir de contenus existants sur lesquels elle a été entraînée. Il devient alors possible de créer un article de blog, générer du code, concevoir des images, créer de la musique, etc.

L’IA générative utilise des modèles de Deep Learning comme les réseaux de neurones antagonistes génératifs (ou Generative Adversarial Networks en anglais) et les modèles de langage avancés (Large Language Models ou LLM) comme GPT-4o. Ces modèles ont été entraînés sur un ensemble important de documents et de données afin d’apprendre comment structurer leurs propres réponses.

Il devient alors possible d’utiliser les outils d’IA générative afin d’analyser du code, d’écrire de la documentation, ou de vérifier si des failles de sécurité et des vulnérabilités sont présentes, ou encore d’écrire de nouvelles fonctionnalités à notre application actuelle. En résumé, il s’agit d’un réel bouleversement de la manière dont les équipes IT travaillent et collaborent.

2. Rôle de l’IA générative dans le DevSecOps

En reprenant les cinq piliers du CALMS, il devient possible de voir que l’IA générative a un impact sur chaque élément.

En effet, elle encourage une culture de la collaboration et de l’innovation grâce à des outils comme GitHub Copilot qui suggère du code en temps réel ou encore ChatGPT et Gemini qui proposent de créer et revoir votre code pour le sécuriser davantage par exemple.

L’automatisation correspond sans doute à l’axe le plus impacté par l’IA générative, car dorénavant, il est possible pour les équipes DevSecOps de générer des scripts de déploiement et de configuration de l’infrastructure grâce à des outils comme OpenAI Codex. Du code pourrait aussi être analysé par l’IA avant d’être déployé en production pour s’assurer qu’il ne présente pas de vulnérabilités importantes.

En automatisant les tâches répétitives et chronophages, l’IA générative aide à éliminer le waste (gaspillage), concept clé du Lean, permettant ainsi aux développeurs de se concentrer sur des tâches qui ont beaucoup plus de valeur ajoutée.

L’IA peut analyser des quantités exponentielles de données pour fournir des informations en temps réel et générer des rapports et des analyses détaillées. Cela...