SecDevOps vs DevSecOps: comment transformer

SecDevOps contre DevSecOps. Cela peut ressembler à de la sémantique, mais l'ordre des mots a tout le poids. Comment changer culturellement la façon dont nous abordons la sécurité? Nous commençons par le traiter avec la gravité qu'il mérite, et nous commençons à l'intégrer au tout 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é de manière interchangeable, SecDevOps vs DevSecOps compare en fait deux choses radicalement différentes. Pourquoi? Parce que l'ordre des mots est important. Dans la plupart des cas, la sécurité est encore «mise en place» à la fin du processus de déploiement.

Dans cet article, je vais expliquer pourquoi la distinction entre DevSecOps et SecDevOps est cruciale pour la sécurité de vos applications. Je parlerai également de 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.

À quoi ressemble la sécurité dans DevSecOps

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:

Étant donné que les connaissances en matière de sécurité sont généralement rares, limitées à quelques personnes dans une organisation, ces personnes sont souvent regroupées dans une équipe de sécurité centralisée. L'équipe de sécurité est chargée de tester le produit à l'aide de sa «boîte magique de trucs» pour trouver des vulnérabilités dans la version candidate avant le déploiement. Lorsque l'équipe, inévitablement, trouve une vulnérabilité, elle transmet la «mauvaise nouvelle» à l'équipe de développement… mais, parce que l'équipe de développement n'a pas la formation en sécurité ou les connaissances sur la façon d'utiliser les outils que l'équipe de sécurité utilise , l'équipe de sécurité est souvent considérée comme des «méchants» car elle retarde désormais la publication à cause de «certaines vulnérabilités de sécurité». Alors, quelle est la réaction typique de l'équipe?

L'approche traditionnelle conduit à des mises à jour retardées et / ou des failles de sécurité en production

Regardons les choses en face, il est difficile d'intégrer des correctifs de sécurité, des contrôles et des normes de codage importants dans un projet qui est «terminé et dépoussiéré» pour l'équipe de développement. Alors que se passe-t-il? Le produit sort avec des vulnérabilités de sécurité connues et inconnues avec peut-être la promesse de «les corriger ou de les modifier dans la prochaine version». C'est ce que vous obtenez lorsque vous mettez la sécurité après le développement - «Dev» puis «Sec» puis «Ops». Bien que ce ne soit pas l'intention, c'est la réalité dans de nombreuses organisations. Envisagez une meilleure approche décrite ci-dessous.

À quoi ressemble la sécurité avec SecDevOps

Les contrôles de sécurité, les directives, les normes de codage et les meilleures pratiques doivent être complètement intégrés dans le processus de développement logiciel. Cela se fait en incluant la sécurité dès le début - «Sec» puis «Dev» puis «Ops». L'équipe de sécurité (ou peut-être une architecture ou un développeur senior spécialisé en sécurité) définit en amont les politiques nécessaires pour l'équipe.

Ces politiques peuvent comprendre des normes de codage sécurisé, des règles pour éviter les API non sécurisées et un cryptage médiocre, des instructions pour l'utilisation d'analyses statiques et dynamiques et des directives de test. L'objectif est que les développeurs travaillent à l'élaboration de logiciels plus sécurisés dans le cadre de leur routine quotidienne et l'automatisation contribue à en faire une réalité.

Avec l'automatisation, vous pouvez déplacer à gauche votre approche de la sécurité pour une stratégie aSecDevOps 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.

La conduite d'améliorations itératives de 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.

Comment mettez-vous cela en œuvre?

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.

Faire de la sécurité une partie de la qualité avec un flux de travail axé sur la sécurité

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 de code source - en détectant et en corrigeant les violations de sécurité où et quand c'est moins cher et plus facile à 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 que le code non sécurisé ne soit pas promu aux étapes ultérieures.

Enfin, les résultats de l'analyse sont renvoyés à l'EDI du développeur via le tableau de bord centralisé de reporting et d'analyse, où les progrès peuvent être suivis, les corrections de parcours effectuées et les rapports d'audit générés en temps réel.

Le flux de travail SecDevOps complet ressemble à ceci:

Les responsables 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 s’aggrave-t-il?» ou "Quelles zones 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.

DevSecOps vs 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 blocage 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. Déplacer la sécurité vers la gauche, comme dans SecDevOps, est la clé du succès. La sécurité doit faire partie du flux de travail quotidien de chaque développeur et intégrée dans le pipeline de logiciels. 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 le risque de SecDevOps ou de DevSecOps.

Par Marc Lambert

Vice-président des produits chez Parasoft, Mark est chargé de s'assurer que les solutions Parasoft apportent une valeur réelle aux organisations qui les adoptent. Mark travaille chez Parasoft depuis 2004, travaillant avec un large éventail de clients de Global 2000, des implémentations technologiques spécifiques aux initiatives plus larges d'amélioration des processus SDLC.