Tout d'abord, considérons DevOps. DevOps a commencé comme un principe de fonctionnement qui a ensuite été coopté dans les produits, les équipes et d'autres éléments spécifiques. À l'origine, DevOps était une chose que l'on fait, pas une chose que l'on est. Il a été fondé sur le principe selon lequel l'exploitation efficace d'un logiciel nécessite une communication ouverte et partagée entre ceux qui construisent le logiciel (développement) et ceux qui l'exploitent (opérations).
Il est conçu pour briser les silos de "Dev" et "Ops" et créer un vocabulaire commun, un ensemble de pratiques et un modèle de responsabilité partagée pour aider ces deux équipes à ne faire qu'une seule et même équipe. Il s'agit notamment d'aider les développeurs à penser comme les responsables des opérations et les responsables des opérations à penser un peu plus comme les développeurs. La pollinisation croisée permet d'améliorer l'instrumentation, la journalisation et les méthodologies de déploiement du côté des développeurs. Du côté des opérations, elle apporte l'infrastructure en tant que code, la configuration en tant que code et d'autres pratiques d'automatisation.
Le résultat net est un logiciel plus facile à déployer et à exploiter, qui permet de réduire les coûts d'exploitation et d'accélérer les cycles de mise en production.
La sécurité entre en jeu lorsque nous réalisons que construire des logiciels plus rapidement et les exploiter à moindre coût peut créer de nouveaux risques. Nous devons trouver un moyen de nous assurer que notre équipe de sécurité est incluse dans le processus unifié. Et s'assurer que les équipes de développement et d'exploitation pensent à la sécurité dans le cadre de leur travail.
Et nous devons le faire sans ralentir l'activité.
DevSecOps nous aide en reprenant les mêmes concepts fondamentaux de DevOps et en y incluant la sécurité. La sécurité devient une partie intégrante des pratiques des développeurs et des opérations. Pour ce faire, elle intègre plusieurs pratiques et technologies spécifiques dans le cycle de vie des logiciels.
Développement de logiciels
Les équipes de développement de logiciels écrivent des logiciels sécurisés depuis des décennies. La formation OWASP et d'autres techniques ont aidé les architectes et les développeurs à éviter des erreurs majeures en matière de sécurité. DevSecOps s'appuie sur ces pratiques grâce au partage des responsabilités et à l'automatisation.
La responsabilité est un principe clé de DevOps et du changement de culture nécessaire pour adopter pleinement DevOps. L'idée est que toute l'équipe est responsable de l'exploitation de la technologie dans l'environnement de production et de la fourniture de valeur à l'entreprise. L'équipe des opérations n'est pas la seule responsable, tout le monde l'est aussi.
De même, DevSecOps tient l'ensemble de l'équipe responsable de l'exploitation du produit en toute sécurité en production. Ce n'est pas seulement l'équipe de cybersécurité qui ajoute la sécurité à la dernière minute, mais tout le monde réfléchit à la manière d'intégrer la sécurité. En créant cette responsabilité partagée, la sécurité n'est plus l'équipe qui dit "non", mais celle qui répond "comment".
L'automatisation est l'un des moyens les plus simples de rendre les logiciels plus sûrs sans alourdir excessivement le processus. Comme pour l'automatisation des processus de construction et de déploiement, nous pouvons utiliser des outils et des technologies pour automatiser les exigences courantes en matière de sécurité.
Les deux plus courants sont les tests dynamiques de sécurité des applications (DAST) et les tests statiques de sécurité des applications (SAST). Il s'agit de produits qui sont incorporés dans votre cycle de vie de construction et de déploiement existant. Les tests SAST sont exécutés pendant le processus de construction et recherchent les vulnérabilités courantes dans le code. Les tests DAST sont exécutés après le déploiement sur une application vivante (typiquement en pré-production) et recherchent les vulnérabilités les plus courantes.
Nous n'entrerons pas dans les détails des produits ou techniques DAST ou SAST. Comme il s'agit de technologies automatisées, elles sont elles aussi contrôlées par le code. En tant que membre de l'équipe DevSecOps, vous définissez comment tester et quoi tester, y compris les règles à appliquer, dans vos fichiers de configuration "Security as Code". Cela rejoint les pratiques d'Infrastructure as Code et de Configuration as Code du côté de l'infrastructure et des opérations.
L'automatisation permet de s'assurer que nous pouvons mettre en œuvre des pratiques de codage sécurisées sans ralentir de manière significative le cycle de développement. Le partage des responsabilités permet de s'assurer que l'ensemble de l'équipe adhère aux meilleures pratiques et réagit aux résultats des tests automatisés.
DevSecOps est un changement de culture
Le DevSecOps ne s'obtient pas en achetant un produit ou en engageant un spécialiste. Ce sont des éléments d'un DevSecOps réussi, mais ils ne suffisent pas à créer une culture DevSecOps réussie. Au contraire, tous les niveaux d'adhésion doivent faire partie du plan, depuis les équipes techniques jusqu'à la direction de l'entreprise.
Les équipes techniques doivent comprendre leur rôle unique dans la création de logiciels sécurisés. Les propriétaires de produits et les autres auteurs de récits d'utilisateurs doivent réfléchir à la manière dont la sécurité s'intègre dans les fonctionnalités du produit. L'équipe chargée de l'expérience utilisateur doit comprendre l'impact de la sécurité sur la facilité d'utilisation. Les architectes doivent choisir des technologies et des architectes sûrs. Les développeurs doivent écrire des logiciels en suivant des modèles sécurisés. Les testeurs tiennent compte à la fois des exigences fonctionnelles et des exigences de sécurité lorsqu'ils élaborent des plans de test et des tests automatisés. Les équipes d'exploitation ont la charge de fournir un environnement d'hébergement sécurisé.
La sécurité est présente dans l'ensemble de l'équipe chargée du produit. Mais si elle ne fait pas partie de la culture des dirigeants, elle échouera inévitablement. À l'approche d'une échéance critique, les dirigeants chercheront-ils à faire des économies pour respecter cette date ? La sécurité sera-t-elle prise en considération ? Si c'est le cas, s'agit-il d'une décision fondée sur le risque ou d'une simple réduction parce que la culture n'a pas été pleinement adoptée ?
Lancer DevSecOps
Comme pour tout changement de culture d'entreprise, l'adoption de DevSecOps nécessite un champion. Ce champion peut être issu de la sécurité, du produit ou de la direction. Une fois que le champion a accepté son rôle, il doit commencer sa campagne de changement de culture.
La première étape consiste à comprendre où en est l'organisation. Quelles sont les pratiques DevSecOps déjà en place ? Organisez-vous déjà des formations OWASP pour les développeurs ? Des solutions DAST ou SAST sont-elles en cours d'exécution ? Peut-être êtes-vous déjà soumis à un audit SOC 2 ou êtes-vous certifié ISO 27001. Toutes les pratiques sécurisées existantes constituent la base sur laquelle DevSecOps peut être construit. S'il n'y en a pas encore, il y a plus de travail, mais l'adoption de DevSecOps peut vous aider à donner la priorité à des gains rapides en introduisant la sécurité dans votre organisation.
En partant de la base, l'effort consiste alors à rassembler toutes les parties prenantes et à les aider à comprendre ce que l'on attend d'elles et, de la même manière, les avantages qu'elles en retireront. Chaque groupe bénéficiera de DevSecOps, et il devra voir que la récompense en vaut la peine. Donnez à chaque groupe un siège à la table et permettez-leur de partager leurs préoccupations. DevSecOps sera-t-il plus coûteux ? Cela va-t-il nous ralentir ? Prenons-nous en compte nos obligations contractuelles et légales ? Cela rendra-t-il notre travail plus difficile ?
Préparez-vous à connaître les réponses à de telles questions ou à savoir comment vous vous y prendriez pour les trouver. Il est très probable que les préoccupations de chaque groupe devront être prises en compte au fil du temps. DevSecOps ne peut pas se faire du jour au lendemain, c'est pourquoi le choix des préoccupations à traiter en premier et de celles qui viendront plus tard dans votre feuille de route d'adoption est la clé d'un effort réussi et gérable.
DevSecOps est essentiel à la création et à l'exploitation de logiciels sécurisés. En comprenant ce qu'il est et ce qu'il apporte à une organisation, vous pouvez commencer à élaborer un plan pour l'adopter au sein de votre organisation. Réaliser qu'il s'agit d'un changement de culture et savoir qui est prêt et qui est réfractaire contribuera à sa réussite. Les récompenses en valent la peine !
Si vous avez besoin d'aide pour adopter DevSecOps ou pour décider si vous devriez le faire, l'équipe de conseil d'Improving peut vous aider ! Contactez nous pour discuter rapidement de votre situation actuelle et de vos objectifs !
Erik s'est exprimé sur ce sujet lors d'un webinaire d'Improving. Pour voir l'enregistrement de la discussion, CLIQUEZ ICI !
