Rendez les tests de régression manuels plus rapides, plus intelligents et plus ciblés. Voyez-le en action >>
SecDevOps vs DevSecOps : la voie vers la transformation
Comment pouvons-nous changer notre façon d’aborder la sécurité des logiciels et limiter les vulnérabilités ? Faire de la sécurité une partie intégrante de notre développement logiciel dès le début de nos projets est une bonne façon de commencer. Découvrez comment SecDevOps et DevSecOps interagissent pour prendre en charge la sécurité des logiciels.
Comment pouvons-nous changer notre façon d’aborder la sécurité des logiciels et limiter les vulnérabilités ? Faire de la sécurité une partie intégrante de notre développement logiciel dès le début de nos projets est une bonne façon de commencer. Découvrez comment SecDevOps et DevSecOps interagissent pour prendre en charge la sécurité des logiciels.
SecDevOps contre DevSecOps. Cela peut ressembler à de la sémantique, mais l’ordre des mots a tout le poids. Comment pouvons-nous modifier culturellement notre façon d’aborder la sécurité ? Nous commençons par le traiter avec la gravité qu’il mérite et commençons à l’intégrer dès le début.
Il ne fait aucun doute que DevOps et la sécurité sont au cœur des préoccupations des organisations logicielles et informatiques d'entreprise, et le résultat de l'intégration de la sécurité dans DevOps a été l'introduction des termes SecDevOps et DevSecOps. Le résultat de l'intégration de la sécurité dans DevOps a été appelé SecDevOps et DevSecOps.
Bien qu'utilisés de manière interchangeable, SecDevOps et DevSecOps comparent deux concepts radicalement différents. Pourquoi ? Parce que l'ordre des mots est important. Dans la plupart des cas, la sécurité est ajoutée à la fin du processus de déploiement.
Dans cet article, j'expliquerai pourquoi la distinction entre DevSecOps vs SecDevOps est crucial pour la sécurité de vos applications. J'aborderai également la manière dont la fourniture de logiciels sécurisés est plus facile à réaliser lorsque la sécurité fait partie intégrante du développement, dès le début du processus de développement logiciel plutôt que comme une porte à la fin du pipeline de livraison.
Malgré l'accent accru mis sur la sécurité, il est difficile pour les équipes logicielles d'intégrer la sécurité dans un processus et un pipeline. La pression pour achever les projets à temps et dans les limites des budgets l'emporte souvent sur d'autres considérations. Par conséquent, l'intégration de la sécurité a tendance à être considérée comme la dernière étape de blocage pour une version candidate, comme illustré ci-dessous:
Les connaissances en sécurité étant généralement rares et limitées à quelques personnes au sein d'une organisation, ces personnes sont souvent regroupées au sein d'une équipe de sécurité centralisée. Cette équipe est chargée de tester le produit à l'aide de sa « boîte magique » afin d'identifier les vulnérabilités de la version candidate avant son déploiement. Lorsque, inévitablement, l'équipe découvre une vulnérabilité, elle transmet la « mauvaise nouvelle » à l'équipe de développement. Cependant, faute de formation en sécurité ni de connaissances sur l'utilisation des outils utilisés par l'équipe de sécurité, cette dernière est souvent perçue comme une « mauvaise équipe », retardant ainsi la publication à cause de « certaines vulnérabilités de sécurité ». Quelle est donc la réaction typique de l'équipe ?
L’approche traditionnelle conduit à des retards de publication et/ou à des vulnérabilités de sécurité en production.
Soyons réalistes, il est difficile d'intégrer des correctifs de sécurité, des contrôles et des normes de codage importants dans un projet déjà finalisé par l'équipe de développement. Que se passe-t-il alors ? Le produit sort avec des vulnérabilités de sécurité connues et inconnues, avec la promesse éventuelle de les corriger ou de les modifier dans la prochaine version. C'est ce qui se produit lorsque l'on place la sécurité après le développement : « Dev », « Sec », puis « Ops ». Bien que ce ne soit pas l'objectif, c'est la réalité dans de nombreuses organisations. Envisagez une meilleure approche, décrite ci-dessous.
Les contrôles de sécurité, les directives, les normes de codage et les bonnes pratiques doivent être pleinement intégrés au processus de développement logiciel. Pour ce faire, la sécurité est intégrée dès le début : « Sec », puis « Dev », puis « Ops ». L'équipe de sécurité (ou peut-être un architecte ou un développeur senior spécialisé en sécurité) définit en amont les politiques nécessaires pour l'équipe.
Ces politiques peuvent consister en des normes de codage sécurisées, des règles pour éviter les API non sécurisées et un cryptage médiocre, des instructions d'utilisation analyse statique et dynamiqueet les directives de test. L’objectif est d’amener les développeurs à travailler sur des logiciels plus sécurisés dans le cadre de leur routine quotidienne et l’automatisation contribue à faire de cet objectif une réalité.
Avec l'automatisation, vous pouvez abandonner votre approche de la sécurité pour une stratégie SecDevOps qui ressemble à ceci :
La sécurité étant désormais intégrée au début du développement, l'équipe deviendra naturellement plus compétente en matière de sécurité et moins de vulnérabilités de sécurité seront trouvées à la fin du pipeline.
Les vulnérabilités qui y parviennent peuvent ensuite être étudiées et les résultats de l'analyse des causes profondes utilisés pour améliorer les politiques et les directives de sécurité - améliorant essentiellement le résultat à mesure que chaque cycle progresse.
Apporter des améliorations itératives à la politique entraîne des escalades de fin de cycle moins perturbatrices, et ressemble à ceci :
Lorsque vous comparez SecDevOps à DevSecOps, l'approche incrémentielle et intégrée de la première fonctionne bien mieux que d'essayer de lancer un audit de sécurité à la fin du projet.
Il n'y a aucun moyen de contourner le fait que la sécurité ajoute une exigence supplémentaire pour les développeurs, mais la façon dont vous gérez l'impact de ce travail est ce qui fait la différence entre un ponctuel, sécurisé produit, et un tardif, incertain une. Une exigence critique est d'intégrer la sécurité dans le processus de développement existant, ce que vous pouvez faire en intégrant la suite d'outils de test compatibles CWE de Parasoft pour faire de la sécurité une partie de la qualité et du flux de travail global des opérations.
Le flux de travail commence par la politique de codage sécurisé. L'architecte ou le responsable crée une configuration (éventuellement basée sur des directives de codage telles que CERT, CWE, OWASP, UL-2900 ou PCI DSS) que le reste de l'équipe pourra exploiter directement dans son IDE. Cela donne au développeur la possibilité de vérifier le code localement sur sa machine avant de s'engager dans le contrôle des sources – en détectant et en corrigeant les violations de sécurité où et quand cela est moins cher et plus facile de le faire.
La même configuration est ensuite exploitée par une analyse exécutée dans le cadre du processus de construction. Cette analyse complète va au-delà de la portée du code modifié localement par le développeur et fournit un filet de sécurité pour bloquer le pipeline de livraison afin de garantir qu'un code non sécurisé ne soit pas promu à des étapes ultérieures.
Enfin, les résultats de l'analyse sont renvoyés à l'IDE du développeur via le tableau de bord centralisé de reporting et d'analyse, où les progrès peuvent être suivis, les corrections de cap apportées et les rapports d'audit générés en temps réel.
Le flux de travail SecDevOps complet ressemble à ceci:
Les gestionnaires et les responsables de la sécurité peuvent désormais évaluer les projets en fonction de normes de sécurité telles que CWE, dans le tableau de bord central comme indiqué ci-dessous :
Ces tableaux de bord permettent une surveillance complète et peuvent afficher des informations sur les tendances pour aider à répondre à des questions telles que : « Le projet s'améliore-t-il ou se dégrade-t-il ? » ou « Quels domaines du code causent le plus de problèmes ? »
Être capable de répondre à ces questions et à d'autres, et d'agir, transforme l'équipe de développement de DevSecOps à SecDevOps.
Malgré l'utilisation interchangeable de DevSecOps et SecDevOps, l'ordre des mots est tout aussi important que les implications des outils, techniques et processus que le mot implique. La sécurité est souvent laissée comme un module complémentaire ou un processus de contrôle avant la sortie d'un produit, mais il est difficile de résoudre les problèmes de sécurité lorsqu'un produit est à mi-chemin de la sortie.
Déplacer la sécurité vers la gauche, comme dans le SecDevOps, est la clé du succès. La sécurité doit faire partie du flux de travail quotidien de chaque développeur et être intégrée au pipeline logiciel. Les contrôles et politiques de sécurité automatisés de Parasoft intègrent la sécurité dans le pipeline tout en réduisant l'impact et les risques de SecDevOps ou de DevSecOps.
