I would like to view this page in
Le DevSecOps intègre les pratiques de sécurité à chaque phase de développement, pour vous assurer de traiter les vulnérabilités au plus tôt sans ralentir votre pipeline de CI/CD.
Cette approche souligne l'importance d'incorporer les tests et les pratiques de sécurité dans le processus de développement logiciel. L'intégration précoce de la sécurité permet de garantir qu'une livraison rapide ne se fasse pas au détriment de la sécurité.
Le DevSecOps est une approche du développement de logiciels basée sur la méthodologie DevOps. Tout comme « DevOps » fusionne « développement » et « opérations », le terme « DevSecOps » combine « développement », « sécurité » et « opérations ». L'ajout de la « sécurité » souligne l'importance d'intégrer les considérations de sécurité à chaque étape du cycle de vie du développement logiciel.
L'objectif du DevSecOps est de permettre aux équipes de livrer des logiciels plus rapidement et efficacement, tout en garantissant que la base de code reste exempte de vulnérabilités. Cette stratégie protège votre organisation et vos utilisateurs contre les cyberattaques.
La méthodologie DevOps est conçue pour accélérer la livraison des logiciels tout en améliorant la qualité et en réduisant le nombre de bugs. Puisant ses racines dans le mouvement Agile, l'approche DevOps a été développée pour résoudre les problèmes posés par l'approche en cascade traditionnelle pour le développement et la livraison des logiciels.
Plutôt qu'un processus linéaire de conception, de développement, d'intégration, de test et de publication qui peut durer plusieurs années, le DevOps encourage les équipes à passer à travers ces cycles rapidement et fréquemment. Pour y parvenir, le DevOps préconise des processus de CI/CD robustes et automatisés qui raccourcissent les délais de livraison et fournissent un retour d'information rapide, créant ainsi un cycle vertueux d'amélioration continue.
En quoi le DevSecOps est-il différent du DevOps ? En fait, il n'a jamais été prévu que le DevOps exclue la sécurité. Toutefois, alors que le mouvement DevOps a contribué à briser les barrières entre les équipes de développement et celles des opérations, les équipes de sécurité informatique sont généralement restées cloisonnées. Le terme DevSecOps (qui connaît plusieurs autres versions, telles que SecDevOps, DevOpsSec et DevOps robuste) a été imaginé dans le but de résoudre ce problème.
L'utilisation du terme « DevSecOps » rappelle aux équipes de prendre en compte la sécurité dans le processus de développement et de déploiement des logiciels. Cette prise en charge inclut :
De la même manière que les tests Shift-Left facilitent la recherche et la correction des bugs, les pratiques de sécurité sont plus faciles à intégrer et plus efficaces lorsqu'elles sont traitées plus tôt dans le processus de développement.
L'impact potentiel des vulnérabilités de sécurité dans vos logiciels ne peut être surestimé.
En plus des dommages financiers et de réputation, les violations de la sécurité des logiciels ont entraîné la divulgation de vastes quantités de données sensibles, notamment des documents internes et les informations personnelles de clients. Selon la juridiction applicable, la fuite de données des utilisateurs peut entraîner de graves sanctions financières ainsi qu'une responsabilité légale.
Malgré tout, l'approche traditionnelle en matière de sécurité logicielle peut être perçue comme un fardeau plutôt qu'un atout. Les audits et les rapports de sécurité ralentissent la progression et vous empêchent de livrer vos dernières fonctionnalités aux mains de vos utilisateurs. Toutefois, choisir d'ignorer l'importance de la sécurité dans le cycle de vie du développement logiciel (SDLC) risque de voir la prochaine cyberattaque faire les gros titres.
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). Parfois, cependant, elles sont nouvelles, résultant peut-être d'une combinaison de facteurs qui n'ont pas été assemblés de cette manière auparavant.
Pour compliquer davantage les choses, presque tous les logiciels intègrent des dépendances (qu'elles soient open source ou propriétaires), et rien ne garantit que le code tiers soit exempt de vulnérabilités. Pour cette raison, sécuriser votre chaîne d'approvisionnement logicielle est tout aussi important que d'évaluer la sécurité de votre propre code source.
Comment la sécurité doit-elle donc être assurée au sein du cycle de vie du développement logiciel ? L'approche DevSecOps applique les mêmes principes que ceux qui ont permis des publications plus rapides et plus stables : déplacer la sécurité vers la gauche afin qu'elle soit traitée plus tôt et plus souvent.
À première vue, pour intégrer la sécurité en amont de votre cycle de développement, vous pouvez penser qu'il suffit d'ajouter une étape à votre processus de CI/CD permettant à votre équipe de sécurité de tester et d'examiner votre logiciel.
Bien que des tests de sécurité manuels puissent s'avérer utiles dans certaines occasions (nous en reparlerons), limiter votre implication en termes d'exigences de sécurité à une étape à la fin du processus de CI/CD vous fera passer à côté des avantages d'un retour d'information rapide et régulier, et ce pour plusieurs raisons :
Alors, comment une approche Shift-Left de la sécurité se traduit-elle dans la pratique ? 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.
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é.
Idéalement, la sécurité doit être prise en compte avant que le premier mot de code soit écrit. 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.
L'automatisation est un principe central de DevOps. Cela accélère les tâches et garantit qu'elles sont effectuées de manière cohérente, et permet aux gens de se consacrer à un travail plus créatif. 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.
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. Bien que les outils d'analyse de sécurité traditionnels ne soient guère adaptés à un pipeline de CI/CD automatisé, des outils de tests de sécurité conçus pour l'automatisation sont désormais disponibles. Ceux-ci s'intègrent dans votre pipeline de CI/CD et peuvent indiquer les résultats dans le tableau de bord ou les envoyer directement dans des 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.
Les tests de sécurité dynamiques des applications (DAST) sont le corollaire des SAST. 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.
Le potentiel des cyberattaques est vaste. Les acteurs malveillants peuvent souvent trouver une défaillance de sécurité dans un logiciel largement utilisé. Ces attaques (et d'autres du même genre) ont servi de rappel essentiel de l'importance de sécuriser votre chaîne d'approvisionnement logicielle.
Qu'entendons-nous par la « chaîne d'approvisionnement des logiciels » ? Dit simplement, c'est tout ce qui est impliqué dans le développement et la livraison de votre logiciel. Tout le développement de logiciels nécessite d'autres logiciels, des composants et des bibliothèques réutilisables aux IDE, en passant par les frameworks et les outils de build. La sécurité de la chaîne d'approvisionnement des logiciels consiste à évaluer la sécurité des logiciels sur lesquels vous vous appuyez et à sécuriser vos processus de développement.
Vous pouvez évaluer ces derniers à l'aide d'outils d'analyse des composants ou de la composition des logiciels (SCA). 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 ont connaissance, alors assurez-vous que les outils que vous choisissez sont régulièrement mis à jour avec de nouveaux exploits et des zones de couverture pertinentes pour votre produit et votre organisation.
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. Cette approche a été utilisée avec brio dans le développement de logiciels, parfois sous forme de tests de pénétration ou de piratage éthique, pour trouver des exploits nouveaux et inattendus.
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 c'est ce que vous choisissez, vous aurez besoin d'avoir confiance dans les modes de défaillance de votre logiciel, ou d'avoir des utilisateurs très tolérants (tout comme vos dirigeants).
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.
Toute l'équipe, et pas seulement l'ambassadeur de la sécurité, doit être responsable de la remédiation aux vulnérabilités. Cela aidera tout le monde à développer ses connaissances et son expertise en matière de sécurité afin de pouvoir utiliser ces compétences sur la base de code actuelle ainsi que sur les futurs projets.
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.
Voici quelques étapes supplémentaires à suivre pour renforcer la sécurité de vos pipelines de build.
L'orchestration des versions désigne la capacité de coordonner des tâches automatisées effectuées par plusieurs systèmes afin de fournir des mises à jour logicielles aux utilisateurs.
La fonctionnalité de commit pré-testé de TeamCity vous permet de vérifier vos modifications à distance AVANT de les valider dans le VCS.