Qu'est-ce que le DevSecOps et quel est son rôle dans la livraison continue ?
DevSecOps souligne l'importance d'intégrer la sécurité dans le cycle de vie du développement. L'intégration de la sécurité dans la culture, les processus et les outils de votre équipe permet d'éviter les silos et de s'assurer que la rapidité d'exécution ne se fait pas au détriment, ou à la merci, des vulnérabilités de sécurité.
Comprendre le DevOps
Avant de nous plonger dans l'aspect sécurité, prenons un bref moment pour parler du DevOps.
Étroitement lié au développement de logiciels agiles, le DevOps vise à créer une culture de collaboration entre le développement de logiciels et les opérations, chacun partageant l'objectif commun de fournir efficacement aux utilisateurs des logiciels utiles et fonctionnels. Pour mettre cela en pratique, le DevOps préconise des processus robustes et automatisés qui raccourcissent les délais de livraison et favorisent un retour d'information rapide, créant ainsi un cycle d'amélioration continue.
Même si, jusqu'à présent, tout fonctionne correctement, lorsque vous accélérez le processus de livraison des logiciels, comme lorsque vous courez pour ne pas louper votre train, il est essentiel de vérifier que vous n'avez rien laissé d'important derrière vous. Malheureusement, cela a souvent été le cas avec la sécurité, et c'est ce que le DevSecOps cherche à résoudre.
Sécurité DevOps
L'impact potentiel des vulnérabilités de sécurité dans vos logiciels ne peut être surestimé.
Il ne s'agit pas seulement de dommages financiers et de réputation. Les failles de sécurité des logiciels ont entraîné la fuite d'un grand nombre de données sensibles, allant de documents internes à des produits confidentiels et aux informations personnelles des clients, y compris les mots de passe. Selon la juridiction, la fuite de données d'utilisateur peut entraîner des sanctions financières sévères, ainsi qu'une responsabilité légale.
Malgré tout, la sécurité est souvent considérée par les équipes de développement comme une charge plutôt qu'un atout. Les audits et les rapports de sécurité ralentissent les progrès et vous empêchent de proposer à vos utilisateurs vos dernières fonctionnalités. Mais cette mentalité est à double tranchant : si nous choisissons d'ignorer l'importance de la sécurité dans le cycle de vie du développement logiciel, nous courons le risque de déclencher le prochain Wannacry ou Heartbleed.
Si ces failles ont fait la une des journaux, leurs origines étaient bien plus simples. Les vulnérabilités existent parce que les humains écrivent du code, et qu'ils font des erreurs. Parfois, ces erreurs ont déjà été commises par d'autres et sont plus faciles à reconnaître (si vous savez où chercher) et parfois elles sont nouvelles, résultant peut-être d'une combinaison de facteurs inédite.
Pour ajouter à la complexité, presque tous les logiciels incorporent des dépendances, open-source ou propriétaires, et il n'existe aucune garantie que ce code tiers ne présente aucune faille.
Comment la sécurité doit-elle donc être assurée au sein du cycle de vie du développement logiciel ? L'approche DevSecOps consiste à appliquer aux pratiques de sécurité les mêmes principes de collaboration, de partage des responsabilités et d'automatisation de tout ce qui peut l'être, qui ont permis d'obtenir des publications plus rapides et plus stables.
Déplacer la sécurité vers la gauche
Le processus de développement en cascade suit une approche linéaire, commençant par la collecte des exigences, suivie des phases de conception, de construction, d'intégration et de test, et enfin, généralement des mois ou des années après le début, de la publication.
La phase de test impliquait généralement de longs processus manuels d'assurance qualité, d'audit de sécurité et de tests d'acceptation. Dans ce processus, le produit était transmis d'une fonction à l'autre, chaque équipe rédigeant un long rapport.
L'une de ces étapes appartenait à l'équipe de sécurité de l'information, ou infosec, qui devait réaliser un rapport de sécurité et produire une liste détaillée de conclusions et de recommandations. Celles-ci nécessitaient souvent des modifications de la base de code, après quoi le logiciel passait à nouveau par les différentes étapes pour confirmer que tout avait été implémenté comme prévu (ou non). Avec un processus aussi long, il n'est pas étonnant que les publications étaient un motif de grande célébration !
Le développement de logiciels agiles, le mouvement DevOps et la croissance du Cloud computing ont bouleversé tout cela. La concurrence est rude et la vitesse est essentielle. Si vous ne répondez pas aux besoins de vos utilisateurs et ne corrigez pas les bugs rapidement, ils trouveront vite un autre prestataire qui le fera. Apporter de la valeur régulièrement et être capable de déployer des correctifs rapides est devenu la norme pour de nombreuses organisations, avec un pipeline de CI/CD comme pierre angulaire de leurs opérations.
Bien que le terme DevSecOps puisse laisser entendre le contraire, DevOps n'a jamais voulu exclure la sécurité.
Malheureusement, la réalité est que les frontières entre les équipes de développement et les équipes opérationnelles ont été abolies et que les équipes de sécurité de l'information sont généralement restées cloisonnées. Pour tenter de résoudre ce problème, le DevSecOps (ainsi que plusieurs autres versions, telles que SecDevOps, DevOpsSec et Rugged DevOps) a été créé.
Le DevSecOps souligne l'importance d'intégrer la sécurité dès le départ, d'étendre la culture de compréhension et de responsabilité partagées aux préoccupations de sécurité et d'intégrer des contrôles de sécurité dans le régime de tests automatisés d'un pipeline de CI/CD. Comme pour les opérations, l'idée est qu'en déplaçant la sécurité vers la gauche, il est plus facile d'intégrer les exigences de sécurité et les bonnes pratiques que si elles sont introduites après la construction du produit.
Mettre le Sec dans DevSecOps : la sécurité comme code
Pour les non-initiés, il peut être tentant de penser que le déplacement de la sécurité vers la gauche nécessite simplement de rendre votre logiciel disponible pour des tests par l'équipe de sécurité en tant qu'étape de votre pipeline de CI/CD.
Bien qu'il y ait une place pour les tests de sécurité manuels, comme nous le verrons plus loin, limiter votre engagement vis-à-vis des exigences de sécurité à une étape en fin de chaîne n'est guère différent que de transmettre le logiciel à un autre service et d'attendre que le rapport revienne.
Le résultat probable est soit que les recommandations sont ignorées parce que leur implémentation serait trop longue, soit que l'ensemble du processus est bloqué et que la publication est retardée indéfiniment pendant que les problèmes sont traités et les risques évalués. Quoi qu'il en soit, cela engendre une mentalité « nous/eux » entre la sécurité et le reste de l'organisation qui n'aide aucune des deux parties à obtenir ce qu'elle veut, à savoir la publication de logiciels utiles et sûrs.
Que signifie concrètement la méthodologie du déplacement à gauche ? Bien qu'il n'existe pas de solution unique, les outils et techniques ci-dessous peuvent aider à intégrer la sécurité dans l'ensemble du cycle de vie du développement logiciel.
Nommer des ambassadeurs de la sécurité
Si une culture de responsabilité partagée est importante, il ne suffit pas de dire à vos équipes de développement qu'elles sont toutes responsables de la sécurité des logiciels. Se tenir au courant des derniers vecteurs d'attaque et des derniers développements en matière de logiciels malveillants est un travail à plein temps, et vous ne pouvez pas vous attendre à ce que tout le monde maintienne le même niveau d'expertise. Intégrer un ambassadeur de la sécurité dans une équipe pluridisciplinaire afin d'encadrer les autres et de partager les bonnes pratiques peut aider à mieux comprendre et à promouvoir une culture de collaboration avec les professionnels de la sécurité.
Faire de la sécurité une contrainte de conception
Afin que les développeurs partagent la responsabilité de la sécurité des logiciels qu'ils construisent, la sécurité doit être prise en compte avant l'écriture de tout code. Elle doit être intégrée aux récits utilisateurs, soulevée lors des réunions d'examen du backlog et discutée lors de la planification de chaque sprint. Lorsque vous réfléchissez à la manière d'aborder une nouvelle fonctionnalité, prenez le temps de discuter des risques qu'elle pourrait présenter et de la manière de les atténuer.
L'adoption d'une stratégie de modélisation des menaces, telle que STRIDE, ou l'utilisation d'un outil tel que la fiche OWASP, peut vous aider à garder le cap pendant que vous apprenez ces nouvelles compétences. Bien que la prise en compte de la sécurité au stade de la conception ne permette pas de tout couvrir, c'est un bon début et cela contribue à promouvoir une culture DevSecOps.
Ajouter des tests de sécurité automatisés au pipeline
L'automatisation est un principe central de DevOps. Non seulement elle accélère les tâches et garantit leur exécution cohérente, mais elle libère aussi des ressources humaines pour des travaux plus créatifs. Si vous souhaitez livrer des logiciels aux utilisateurs régulièrement et fréquemment, il est essentiel d'ajouter des tests de sécurité automatisés à votre pipeline.
Lors de la rédaction des tests unitaires, d'intégration et de bout en bout automatisés, les caractéristiques de sécurité doivent être considérées comme aussi pertinentes que toute autre fonctionnalité. Si votre équipe a intégré des exigences de sécurité dans des récits utilisateurs et discuté de modèles de menaces dans le cadre du processus de conception, l'ajout de tests couvrant les fonctions de sécurité est une extension naturelle de ce travail.
Obtenir l'aide d'un expert
En plus des tests que vous écrivez vous-même, il existe divers outils de test de sécurité qui peuvent aider à renforcer la fiabilité de la qualité de votre code. Alors que les outils traditionnels de scan de sécurité n'étaient pas adaptés à un pipeline automatisé CI/CD, il existe désormais des outils de test de sécurité de CI/CD qui ont été conçus pour l'automatisation et qui s'intègrent au pipeline avec des résultats accessibles via le tableau de bord ou introduits directement dans les outils de suivi de bugs. Comme pour tous les tests automatisés, il est utile de structurer vos tests afin de fournir un retour d'information le plus rapidement possible.
Les outils de tests de sécurité des applications statiques (SAST) effectuent une analyse statique du code pour vérifier si votre code source présente des failles de sécurité connues, telles que des dépassements de tampon et des possibilités d'injection SQL. Comme l'analyse statique est exécutée sur le code source, elle peut être lancée au début du pipeline CI/CD, dès que les modifications ont été effectuées.
Les outils SAST sont spécifiques à chaque langage, et certains s'intègrent à l'IDE pour fournir un retour d'information continu à mesure de la saisie ou la possibilité d'effectuer des tests à la demande. En orientant les développeurs vers la ligne de code spécifique qui contient la vulnérabilité, les outils SAST offrent des conseils ciblés qui permettent de résoudre le problème plus rapidement. Cependant, les faux positifs peuvent poser un problème. Il est donc essentiel de pouvoir désactiver ou rejeter certaines alertes si vous voulez éviter que tous les résultats SAST ne deviennent des distractions.
Le corollaire du SAST est le test dynamique de sécurité des applications (DAST). Il s'agit d'une approche de test par boîte noire sur l'application en cours d'exécution, vérifiant les vulnérabilités connues telles que les scripts inter-sites, les commandes et l'injection SQL, et la configuration non sécurisée du serveur. Comme les outils DAST exigent que l'application soit construite et déployée dans un environnement de test, ils sont généralement utilisés plus tard dans le pipeline CI/CD.
Vérifier vos dépendances
L'analyse de la composition ou des composants du logiciel (SCA) est un autre type de test de sécurité automatisé qui peut être exécuté au début du processus. Comme nous l'avons dit précédemment, pratiquement chaque base de code intègre des bibliothèques et d'autres composants open source, qui peuvent introduire des vulnérabilités.
Les outils SCA doivent non seulement explorer les dépendances que vous avez introduites, mais aussi leurs dépendances de manière récursive tout au long de la chaîne d'approvisionnement. Il s'agit d'un exemple parfait d'un travail plus adapté aux ordinateurs, surtout si l'on considère la fréquence à laquelle de nouvelles dépendances sont ajoutées à un projet.
En plus d'être exécutés automatiquement dans le cadre du pipeline CI/CD, certains outils du SCA sont disponibles sous forme de plugins IDE pour fournir un retour d'information à la volée. Comme pour les tests de sécurité statiques et dynamiques, les tests SCA sont limités par les vulnérabilités dont les outils sont conscients. Assurez-vous donc que les outils que vous choisissez sont régulièrement mis à jour avec de nouvelles failles et qu'ils couvrent les domaines les plus pertinents pour votre produit et votre entreprise. Cependant, l'humain est souvent nécessaire pour identifier des failles nouvelles et inattendues.
Faire appel à l'équipe rouge
Le concept d'équipe rouge trouve son origine dans les jeux de guerre, où les membres de votre propre camp sont invités à jouer le rôle de l'ennemi dans une attaque simulée afin d'identifier les faiblesses de vos propres défenses et stratégies. La même approche a été utilisée avec beaucoup d'efficacité dans le développement de logiciels, parfois sous la forme de tests de pénétration ou de piratage éthique.
Pour qu'une équipe rouge puisse travailler efficacement, ses membres ne doivent pas être impliqués dans le développement du système testé. Tout comme les tests exploratoires, cette méthode exige des testeurs qu'ils sortent des sentiers battus et qu'ils utilisent le logiciel d'une manière différente de celle prévue.
Une équipe rouge peut travailler soit sur un environnement intermédiaire (idéalement aussi proche que possible de la production), soit sur un système de production en ligne. Si vous optez pour cette dernière option, vous aurez besoin d'un degré élevé de confiance dans les modes de défaillance de votre produit ou d'utilisateurs (et de responsables) très tolérants.
Traiter toutes les vulnérabilités comme des bugs
Une approche DevSecOps implique que chacun assume la responsabilité de la sécurité de votre logiciel. Il est donc temps d'arrêter de considérer les questions de sécurité comme étant distinctes des bugs « ordinaires ». Toute défaillance ou vulnérabilité découverte dans votre système fait partie du même backlog que tous les autres incidents et doit être traitée en priorité en même temps que ceux-ci.
La responsabilité de les corriger revient à toute l'équipe, et pas uniquement au responsable de la sécurité. Cette approche permet de développer les connaissances et l'expertise au sein de l'équipe, et vous pouvez utiliser ces compétences pour le prochain projet sur lequel vous travaillez.
Continuer à surveiller la production
Malgré tous vos efforts dans les étapes précédentes du cycle de vie du développement logiciel, il existe toujours un risque qu'un hacker trouve une faille dans votre système réel. Il vaut toujours la peine d'investir dans des pare-feu et des outils de surveillance pour protéger à la fois votre entreprise et vos utilisateurs. Les outils d'autoprotection des applications d'exécution (RASP) sont le dernier ajout à ces défenses, détectant et bloquant automatiquement les comportements suspects.
Conclusion
Déplacer la sécurité vers la gauche signifie en faire une considération pour l'ensemble de l'équipe à chaque étape du cycle de vie du développement logiciel. Lorsque vous appliquez les pratiques DevOps, ce cycle de vie se répète fréquemment, ce qui vous permet, à vous et à votre équipe, d'avoir des retours réguliers sur le comportement de votre logiciel et sur son utilisation dans le monde réel. L'intégration de la sécurité dans votre pipeline de CI/CD signifie que vous obtenez un retour d'information régulier sur la sécurité de votre application et que vous pouvez l'améliorer de la même manière que le reste de vos fonctionnalités.
La surveillance et la protection contre les vulnérabilités connues permettront au moins de s'assurer que votre logiciel reste en phase avec les attaquants, plutôt que de vous laisser sans défense face à des attaques connues. En traitant chaque nouvelle vulnérabilité comme un bug à classer, à corriger et à tester à l'avenir, vous rendrez votre logiciel plus robuste au fil du temps.
En fin de compte, les DevOps, et donc les DevSecOps, sont autant une question de culture qu'une question d'outils et de processus qui permettent une livraison rapide et fréquente des logiciels. Après tout, ce sont les personnes qui rendent cela possible. Si vous voulez intégrer la sécurité dans le cycle de vie du développement logiciel, il est essentiel de créer une culture de responsabilité partagée plutôt que de reproches ciblés. Tout le monde devrait pouvoir signaler un problème de sécurité et être entendu, que ce soit pendant la planification du sprint, la révision du code, les tests manuels ou sur le système réel, et chacun a un rôle à jouer pour reconnaître l'importance de la sécurité et l'implémenter.