devsecops ou secdevops voici la nouvelle question à la mode dans l'univers IT

À 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 exercée pour achever les projets dans les délais et les budgets prime souvent d’autres considérations. En conséquence, nous avons tendance à voir la sécurité ajoutée comme la dernière étape de déclenchement pour un candidat à la publication, comme illustré ci-dessous:

 

Approche traditionnelle de la sécurité par DevSecOps

 

Comme les connaissances en matière de sécurité sont généralement rares et 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 à outils magique" afin de détecter les vulnérabilités dans la version candidate avant le déploiement. Lorsque l'équipe détecte inévitablement une vulnérabilité, elle transmet la "mauvaise nouvelle" à l'équipe de développement ... mais parce que l'équipe de développement ne dispose pas de la formation en sécurité ni des connaissances pour utiliser les outils qu'elle utilise. utilisent, l'équipe de sécurité est souvent considérée comme des "méchants" car ils retardent maintenant la publication en raison de "certaines failles de sécurité". Alors, quelle est la réaction typique de l'équipe?

L’approche traditionnelle conduit à des vulnérabilités de publication et / ou de sécurité retardées en production

Admettons-le, il est difficile d'intégrer des correctifs de sécurité, des contrôles et des normes de codage importants dans un projet "terminé" à l'aide de la technologie de développement. Alors qu'est-ce qui se passe? Le produit sort de la porte avec des vulnérabilités de sécurité connues et inconnues avec éventuellement une certaine promesse de "les réparer dans la prochaine version". Voici 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 politiques doivent être complètement intégrés au processus de développement logiciel. Ceci est fait en intégrant la sécurité dans le processus et le pipeline depuis 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é dans la sécurité) définit d'emblée les règles nécessaires pour l'équipe.

Ces stratégies peuvent comprendre des normes de codage sécurisé, des règles permettant d’éviter les API non sécurisées et un cryptage faible, des instructions pour l’utilisation des analyses statiques et dynamiques et des instructions de test. L’objectif est de faire travailler les développeurs vers des 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 modifier votre approche de la sécurité pour une stratégie SecDevOps ressemblant à 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 en matière de sécurité seront détectées à la fin du pipeline.

Les vulnérabilités qui y parviennent peuvent ensuite être examinées et les résultats de l'analyse des causes premières utilisés pour améliorer les politiques et les directives de sécurité - améliorant essentiellement les résultats obtenus à chaque cycle.

Les améliorations itératives apportées à la stratégie génèrent des remontées de cycle en fin de cycle moins gênantes et se présentent comme suit:

Cette approche progressive et intégrée fonctionne beaucoup mieux que d'essayer de se baser sur un audit de sécurité à la fin du projet.

Comment implémentez-vous cela?

Il est indéniable que la sécurité impose une exigence supplémentaire aux développeurs, mais la façon dont vous gérez l'impact de ce travail est ce qui fait la différence entre un produit sécurisé, ponctuel, et un produit tardif, non sécurisé. Une exigence essentielle 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 avec CWE de Parasoft pour intégrer la sécurité à la qualité et au flux de travail global.

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

Le flux de travail commence par la stratégie de codage sécurisé. L'architecte ou le responsable crée une configuration (éventuellement basée sur des instructions de codage telles que CERT, CWE, OWASP, UL-2900 ou PCI-DSS) que le reste de l'équipe peut 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 source - en détectant et en corrigeant les violations de la sécurité là où et quand cela 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 dépasse le cadre du code modifié localement par le développeur et fournit un filet de sécurité pour ouvrir le pipeline de distribution afin de garantir que le code non sécurisé ne soit pas promu à des é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 génération de rapports et d'analyse, où les progrès peuvent être suivis, les corrections apportées et les rapports d'audit générés en temps réel. 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. Ces tableaux de bord peuvent afficher des informations sur les tendances et 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?"

Pouvoir répondre à ces questions et à d’autres, et prendre des mesures, transforme l’équipe de développement de DevSecOps à SecDevOps.

Résumé

Malgré l'utilisation interchangeable de DevSecOps et de SecDevOps, l'ordre des mots est tout aussi important que les implications des outils, des techniques et des processus que le mot implique. La sécurité est souvent laissée comme un ajout ou un processus de déclenchement 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 être intégrée au pipeline de logiciels.Parasoft automatise le décalage gauche des contrôles et politiques de sécurité pour intégrer la sécurité au pipeline tout en réduisant l'impact et le risque de SecDevOps (et de DevSecOps!).


Rejoindre la conversation