Présentation de DevSecOps
Écrit par
0 minutes de lecture
Qu’est-ce que DevSecOps ?
DevSecOps désigne l’intégration des pratiques de sécurité dans un modèle de livraison logicielle DevOps. Il repose sur une culture où le développement et les opérations disposent des processus et des outils nécessaires pour partager la responsabilité de la livraison de logiciels sécurisés.
À un niveau de maturité élevé, le modèle DevSecOps consiste à intégrer les objectifs de sécurité le plus tôt possible dans le cycle de développement logiciel. Si la sécurité est « l’affaire de tous », les équipes DevOps sont particulièrement bien placées, à la croisée du développement et des opérations, pour appliquer la sécurité avec une vision à la fois globale et approfondie.
Quelle est la différence entre DevOps et DevSecOps ?
La différence entre DevOps et DevSecOps tient, en résumé, à une culture de la responsabilité partagée. Le concept de DevOps est discuté et documenté depuis plus de dix ans, et il en existe de nombreuses définitions. Fondamentalement, DevOps est un modèle organisationnel qui harmonise les pratiques de développement et d’exploitation autour d’une responsabilité partagée.
Comparaison entre DevOps et DevSecOps
D’abord simple ensemble de pratiques courantes partagées par des équipes d’ingénierie logicielle très performantes, DevOps est devenu une vision moderne de la culture et des processus d’ingénierie. Les organisations qui partagent la responsabilité du développement et des opérations peuvent itérer plus rapidement et, par conséquent, obtenir de meilleurs résultats. DevSecOps prolonge cette philosophie en intégrant les objectifs de sécurité aux objectifs globaux. Il faut voir DevSecOps comme la suite naturelle de DevOps, et non comme une idée ou un concept distinct. Les équipes qui appliquent avec succès les pratiques DevOps devraient considérer DevSecOps comme une évolution, plutôt qu’une révolution.
Beaucoup s’accordent à dire que l’objectif était de créer un environnement dans lequel la valeur métier est générée grâce à un flux continu et durable, du code à la production. Ce nouveau modèle s’est accompagné d’outils et de méthodologies qui ont accéléré le rythme, créant un goulot d’étranglement : les pratiques de sécurité traditionnelles, avec leurs cycles de retour lents, freinaient les pratiques DevOps rapides. La sécurité n’était donc souvent assurée qu’après la mise en production ou par des équipes externes intégrées au processus, ce qui ralentissait les choses.
Pour mieux comprendre la différence entre DevOps et DevSecOps, DevSecOps étend la culture de responsabilité partagée de DevOps aux pratiques de sécurité. Les activités visant à détecter et, idéalement, à résoudre les problèmes de sécurité sont intégrées tôt dans le cycle de développement des applications, plutôt qu’après leur mise en production. Pour cela, les équipes de développement sont habilitées à effectuer elles-mêmes de nombreuses tâches de sécurité au cours du cycle de développement logiciel (SDLC).
Cette approche contribue à réduire le nombre de vulnérabilités en production et, par conséquent, les coûts associés à la correction des failles de sécurité. Elle favorise la montée en charge tout en instaurant une culture collaborative qui rapproche la sécurité des objectifs DevOps. DevSecOps vise à intégrer la sécurité à chaque étape du processus de livraison, dès la définition des exigences, et à établir un plan d’automatisation de la sécurité.
L’importance de DevSecOps
Pourquoi les pratiques DevSecOps sont-elles importantes ?
La transformation numérique est devenue une nécessité absolue pour presque toutes les entreprises. Elle s’articule autour de trois évolutions majeures : davantage de logiciels, les technologies cloud et les méthodologies DevOps.
Avec davantage de logiciels, une part plus importante des risques de l’organisation devient numérique. La dette technique s’accroît, tout comme les enjeux de sécurité des applications, ce qui complique de plus en plus la protection des actifs numériques.
Le cloud implique l’adoption de technologies plus récentes qui introduisent de nouveaux risques et évoluent plus rapidement. Plus accessibles au public, elles effacent ou redéfinissent le concept de périmètre sécurisé. Cela signifie également qu’une grande partie des risques liés aux infrastructures et aux technologies de l’information est transférée vers le cloud, tandis que d’autres sont désormais entièrement définis par logiciel. Certains risques diminuent, mais la gestion des autorisations et des accès devient d’autant plus importante.
Enfin, DevOps transforme la manière de développer et de livrer les logiciels, en accélérant le cycle qui va de l’écriture du code à la création de valeur pour les clients, puis à l’apprentissage tiré du marché et à l’adaptation. Des équipes de développement autonomes livrent des logiciels en continu et plus rapidement que jamais, et prennent leurs décisions technologiques et de mise en œuvre sans intermédiaires. Les longs cycles de retour qui ralentissent le développement ne sont plus acceptés, car les équipes privilégient toujours davantage l’autonomie : vous écrivez le code, vous l’exécutez.
À mesure que le reste de l’organisation évolue, les équipes de sécurité doivent répondre à des exigences croissantes et deviennent souvent un goulot d’étranglement. Conçus pour l’ère pré-cloud, où le rythme était plus lent, les outils et pratiques de sécurité des applications historiques placent les équipes de sécurité sur le chemin critique de la livraison d’applications de qualité. En sous-effectif à cause d’une grave pénurie de talents en sécurité, ces équipes deviennent un frein et n’arrivent plus à suivre. Résultat : les équipes de développement livrent des applications non sécurisées, les équipes de sécurité s’épuisent et la sécurité devient un obstacle, annulant les gains d’accélération recherchés par l’entreprise.
Pour relever ces défis, les pratiques ont commencé à évoluer, donnant naissance à DevSecOps. Une culture DevSecOps intègre la sécurité à la démarche DevOps et permet aux équipes de développement de sécuriser ce qu’elles créent à leur propre rythme, tout en renforçant la collaboration entre les spécialistes du développement et de la sécurité. Les équipes de sécurité peuvent ainsi jouer un rôle de soutien, en apportant leur expertise et leurs outils pour renforcer l’autonomie des développeurs, tout en assurant le niveau de supervision attendu par l’entreprise.
6 avantages du modèle DevSecOps
Livraison accélérée : L’intégration de la sécurité au pipeline accélère la livraison des logiciels. Les bogues sont détectés et corrigés avant le déploiement, ce qui permet aux développeurs de se concentrer sur la livraison de fonctionnalités.
Meilleure posture de sécurité : La sécurité est intégrée dès la phase de conception. Un modèle de responsabilité partagée garantit une intégration étroite de la sécurité, de la création au déploiement, jusqu’à la sécurisation des charges de travail en production.
Réduction des coûts : La détection des vulnérabilités et des bogues avant le déploiement réduit considérablement les risques et les coûts opérationnels.
La valeur de DevOps renforcée : L’intégration des pratiques de sécurité à DevOps améliore la posture de sécurité globale en instaurant une culture de responsabilité partagée. Le rapport Snyk/Puppet 2020 DevSecOps Insights a confirmé cette tendance au sein des organisations ayant atteint une grande maturité DevSecOps.
Une sécurité mieux intégrée, à un rythme plus soutenu : La suppression de la nécessité d’ajouter des contrôles de sécurité après le développement réduit le coût et le délai de livraison de logiciels sécurisés.
Une réussite globale accrue pour l’entreprise : La confiance renforcée dans la sécurité des logiciels développés et l’adoption de nouvelles technologies favorisent la croissance des revenus et l’élargissement de l’offre commerciale.
Adoption de DevSecOps : intégrer la sécurité au pipeline CI/CD
La plupart des organisations DevOps modernes s’appuient sur une combinaison de systèmes d’intégration continue et de déploiement ou livraison continue, sous la forme d’un pipeline CI/CD. Ce pipeline constitue une excellente base pour automatiser différents tests et contrôles de sécurité, sans mobiliser une personne pour effectuer ces tâches manuellement.
Adoption du DevSecOps : intégrer la sécurité au pipeline CI/CD
Pour intégrer les objectifs de sécurité dès le début du développement d’une application, commencez avant même d’écrire la première ligne de code. Dès la conception initiale du système, de l’application ou d’une user story, la sécurité peut être prise en compte et une modélisation efficace des menaces peut commencer. L’analyse statique, les linters et les moteurs de politiques peuvent être exécutés à chaque envoi de code par un développeur. Les problèmes les plus simples à corriger sont ainsi traités avant que les modifications ne poursuivent leur parcours dans le pipeline.
L’analyse de la composition logicielle permet de vérifier globalement que les dépendances open source sont compatibles en matière de licences et exemptes de vulnérabilités. Elle a aussi pour effet de renforcer le sentiment de responsabilité des développeurs vis-à-vis de la sécurité de leurs applications, grâce à un retour immédiat sur le niveau de sécurité du code qu’ils ont écrit.
Une fois le code envoyé et compilé, vous pouvez commencer à réaliser des tests d’intégration de sécurité. L’exécution du code dans un bac à sable isolé sous forme de conteneur permet d’automatiser des tests portant, par exemple, sur les appels réseau, la validation des entrées et l’autorisation. Ces tests fournissent rapidement un retour d’information, ce qui permet d’itérer et de trier rapidement les problèmes détectés sans perturber le flux de travail global. En cas d’appels réseau inexpliqués ou d’entrées non assainies, par exemple, les tests échouent et le pipeline fournit des informations exploitables sous forme de rapports et de notifications aux équipes concernées.
Une fois que l’artefact de déploiement a réussi la première série de tests d’intégration, il passe à l’étape suivante. Il est alors déployé dans un bac à sable plus vaste, une copie limitée de l’environnement de production prévu. À cette étape, d’autres tests d’intégration de sécurité peuvent être réalisés, avec toutefois un objectif différent.
Il est alors possible de vérifier, entre autres, la bonne configuration de la journalisation et des contrôles d’accès. L’application consigne-t-elle correctement les indicateurs pertinents de sécurité et de performance ? L’accès est-il limité au groupe de personnes autorisées, voire totalement bloqué ? En cas d’échec, des actions sont à nouveau communiquées aux équipes concernées.
Enfin, l’application est mise en production. Mais le travail DevSecOps ne fait que commencer. L’application automatisée des correctifs et la gestion des configurations garantissent que l’environnement de production exécute toujours les versions les plus récentes et les plus sécurisées des dépendances logicielles. Idéalement, une infrastructure immuable implique que l’environnement entier soit régulièrement démantelé puis recréé, et soumis en permanence à la batterie de tests couvrant l’ensemble du pipeline.
Un pipeline CI/CD DevSecOps permet d’intégrer les objectifs de sécurité à chaque étape, sans ajouter de lourdeurs administratives ni de contrôles bloquants, tout en préservant la rapidité de livraison de valeur métier.
Favoriser une culture DevSecOps
Comment une organisation peut-elle passer progressivement de « DevOps » à « DevSecOps » ? Il ne suffit pas de confier quelques indicateurs de sécurité à une équipe DevOps déjà débordée et d’en rester là. Il faut instaurer une culture collaborative et partagée, fondée sur des itérations rapides.
Si l’objectif est d’intégrer les objectifs de sécurité tôt dans le cycle, cette intégration doit être aussi simple que possible. Il ne revient pas aux développeurs de prendre en charge l’intégration des équipes et des objectifs de sécurité dans le flux de valeur. Ajouter des étapes ne ferait qu’allonger le délai de livraison des fonctionnalités aux clients. L’équipe de sécurité doit être agile et adopter une approche pragmatique afin de mettre en œuvre la sécurité avec un minimum de perturbations.
Lors de la planification, en particulier pour les infrastructures, les ingénieurs sécurité devraient participer aux discussions. Ils doivent pouvoir s’opposer aux choix inadaptés ou peu sûrs, tout en disposant de l’expertise nécessaire pour proposer d’autres solutions. Trop souvent, des équipes de sécurité surchargées se contentent de dire « non » et laissent aux équipes DevOps le soin de trouver des solutions de remplacement. Là encore, il est essentiel de doter les équipes de sécurité des ressources nécessaires.
Lorsque les équipes de sécurité et DevOps collaborent tôt et régulièrement, les objectifs de sécurité sont intégrés au cœur de l’infrastructure. Les fonctionnalités et les applications mises en production sont le fruit d’une collaboration complète et efficace entre les équipes de sécurité, de développement et d’exploitation. La sécurité n’a plus besoin de demander après coup aux équipes de développement d’ajouter des fonctionnalités ou des audits : ces éléments sont prévus dès le premier jour.
Si votre organisation a évolué pour adopter les pratiques DevSecOps, vous savez que vous pouvez non seulement itérer rapidement et ravir vos clients avec de nouvelles fonctionnalités et des fonctionnalités améliorées, mais aussi leur offrir une expérience accompagnée d’un niveau de sécurité à la hauteur.