SecDevOps vs DevSecOps : la voie vers la transformation

Qu’est-ce que SecDevOps ?

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 choses radicalement différentes. Pourquoi? Parce que l’ordre des mots est important. Dans la plupart des cas, la sécurité est encore « renforcé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.

À 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:

Les connaissances en matière de sécurité étant généralement rares et limitées à quelques individus au sein d’une organisation, ces individus sont souvent regroupés au sein d’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 d'astuces » pour trouver les vulnérabilités dans la version candidate avant le déploiement. Lorsque l’équipe découvre inévitablement une vulnérabilité, elle transmet la « mauvaise nouvelle » à l’équipe de développement. Cependant, comme l'équipe de développement n'a pas la formation en sécurité ni les connaissances nécessaires pour utiliser les outils qu'elle 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 retards de publication et/ou à des vulnérabilités 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 entièrement 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 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.

Comment transformer DevSecOps en SecDevOps ?

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.

Intégrez la sécurité à 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 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 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 : donner la priorité à la sécurité dans le développement

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.