Une meilleure approche de DevSecOps

La plupart des problèmes avec DevSecOps aujourd'hui reviennent aux organisations qui tentent de «corriger» la sécurité en ajoutant des tests à la fin du cycle du produit, dans l'espoir de détecter certaines des vulnérabilités critiques. Dans cet article, découvrez comment inverser cette tendance grâce à une stratégie efficace pour déplacer les tests de sécurité vers les premières étapes du développement à l'appui de DevSecOps.

Dans mon post précédent, J'ai discuté SecDevOps et pourquoi c'est un meilleur terme que le terme couramment utilisé DevSecOps. La sécurité est souvent laissée en tant que complément ou processus de blocage avant de lancer 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 (ce que le nom plus commun DevSecOps n'implique pas), est le clé de la réussite. La sécurité doit faire partie du flux de travail quotidien de chaque développeur et intégrée dans le pipeline de logiciels.

En tant que vice-président des produits chez Parasoft, mon travail consiste à m'assurer que nous facilitons la tâche pour nos clients. Qu'est-ce que ça veut dire? Eh bien, pour commencer, cela signifie automatiser le passage à gauche des contrôles et des politiques de sécurité, pour aider nos clients à intégrer la sécurité dans le pipeline tout en réduisant l'impact et les risques de DevSecOps. Alors, comment faites-vous cela? Lisez la suite ci-dessous pour savoir comment relever les défis traditionnels de l'intégration de la sécurité dans DevOps. Ensuite, nous inspecterons le flux de travail DevSecOps qui a réussi à déplacer la sécurité vers la gauche, là où elle devrait être.

Résoudre les défis qui empêchent la réussite des stratégies DevSecOps

La plupart des problèmes avec DevSecOps aujourd'hui reviennent aux organisations qui tentent de «corriger» la sécurité en ajoutant des tests à la fin du cycle du produit, dans l'espoir de détecter certaines des vulnérabilités critiques. Voici quelques-unes des raisons pour lesquelles cela se produit et comment vous pouvez les résoudre avec une approche plus intelligente de la sécurité.

Défi: difficile de savoir comment «réparer» la sécurité

La plupart des développeurs et des testeurs ne sont pas (encore!) Des experts en sécurité, il est donc difficile de se voir dire de «réparer» la sécurité aux derniers stades du développement quand on ne sait pas quoi faire.

Solution: améliorez progressivement la sécurité

Au lieu de cela, les équipes peuvent utiliser des politiques centralisées, telles que des normes de codage sécurisé et des contrôles d'analyse statique des vulnérabilités courantes, pour améliorer progressivement la sécurité tout au long du cycle de développement. En outre, les outils de sécurité peuvent donner aux développeurs et aux testeurs des conseils sur les raisons pour lesquelles des vulnérabilités existent, comment elles sont exploitées et, finalement, supprimées et testées. Avec les outils d'analyse statique de Parasoft, vous pouvez facilement définir une politique centralisée basée sur les normes de codage sécurisé de l'industrie (c'est-à-dire CWE, OWASP, CERT, UL 2900). De la documentation, des exemples et une formation intégrée sont également intégrés pour permettre à toute l'équipe de continuer à apprendre ce qu'il faut faire ensuite.

Défi: les tests de sécurité de fin de cycle entraînent des retards et des vulnérabilités laissés en production

L'approche courante consistant à tenter de faire de la sécurité par klaxon un produit presque complet est insuffisante. Trop de vulnérabilités se retrouvent dans le code de production.

Solution: intégrez l'analyse de sécurité aux premières étapes du développement

Au lieu de cela, la sécurité peut être intégrée au développement et aux opérations quotidiennes. Les développeurs doivent pouvoir effectuer des analyses directement dans l'IDE, en faisant passer la conformité de la sécurité au plus premiers stades de développement. Les outils Parasoft s'intègrent au processus de construction et fournissent des plugins CI pour vérifier que les vulnérabilités restent en dehors du pipeline CI. Les données collectées sont stockées sur une base par construction et disponibles pour les tableaux de bord de reporting et d'analyse.

Défi: état inconnu du risque de sécurité du projet jusqu'au dernier moment

Dépourvus de toute sorte d'évaluation des vulnérabilités, les projets présentent des risques de sécurité totalement inconnus jusqu'à ce qu'une sorte de test soit effectué. Lorsque des tests de fin de cycle sont effectués, les vulnérabilités de sécurité découvertes ont tendance à provoquer une désabonnement et des retouches de fin de cycle. Malgré ces efforts héroïques de dernière minute, de nombreuses vulnérabilités en matière de sécurité continuent d'être entre les mains des clients.

Solution: surveillance continue de la qualité et de la sécurité des logiciels

Pour permettre la hiérarchisation et la correction des parcours, les rapports de conformité en temps réel doivent fournir des tableaux de bord faciles d'accès, avec une vue détaillée et approfondie des données. Parasoft élimine les frais généraux liés à la surveillance de la sécurité avec des tableaux de bord de sécurité hautement personnalisables, interactifs, accessibles depuis n'importe quel endroit et pouvant être conçus pour n'importe quel utilisateur, du développeur au chef d'équipe en passant par le responsable de niveau supérieur.

Utilisation de Parasoft pour un flux de travail SecDevOps plus intelligent

Si vous comprenez les défis ci-dessus et que vous êtes prêt à commencer, cela commence par l'intégration d'outils de test dans votre flux de travail de développement existant. C'est la clé de l'adoption quotidienne et de l'optimisation du retour sur investissement de votre investissement. Voyons comment les outils Parasoft sont intégrés dans un pipeline CI / CD typique et comment ils peuvent être mis à profit pour «déplacer la sécurité vers la gauche» dans DevOps.

Ici, vous voyez à la fois pré-commit et post-commit dans le flux de travail, avec une analyse de code avant et après avoir soumis le code au référentiel source. Aider les développeurs à améliorer la qualité et la sécurité Eux avant nous le code est enregistré est un avantage significatif de «décalage vers la gauche». Nos outils commencent là, puis continuent à aider après l'archivage, la création et le déploiement du code.

Workflow de pré-validation:

1. Décidez d'une norme de sécurité qui convient aux besoins du projet et de l'organisation (par exemple, OWASP, CWE, CERT). Les niveaux de conformité et la composition d'une norme de codage, par exemple, peuvent être personnalisés en fonction de vos besoins et peuvent être une combinaison de normes de sécurité et de qualité.
2. Encapsulez la politique de sécurité dans une configuration de test. Ceci est généralement effectué de manière centralisée, pour un projet entier, par un chef d'équipe.
3. Rendre la ou les configurations définies disponibles pour que les développeurs les utilisent lorsqu'ils écrivent et testent leur code. Le principal avantage ici est la mise en place de ces normes sur l'environnement de bureau de chaque développeur, de sorte que tout le monde travaille selon la même norme.
4. Appliquez des vérificateurs au code avant l'enregistrement. Notre expérience a montré que la meilleure pratique consiste à ne pas faire de la conformité à la configuration de test une porte d'entrée, car cela aura un impact sur l'efficacité de l'équipe et l'adoption de pratiques de codage sécurisées. Le code qui n'est pas entièrement conforme est souvent archivé pour diverses raisons que les outils ne peuvent pas nécessairement évaluer, et le but de la partie post-commit du flux de travail est à la fois d'effectuer une `` analyse complète '' et de servir de filet de sécurité.

Workflow post-commit:

1. Créez du code, exécutez des tests existants et effectuez analyse statique à l'échelle du projet.
2. Inspectez les résultats publiés sur le tableau de bord de sécurité pour déterminer les domaines de préoccupation.
3. Analysez les résultats, hiérarchisez les violations et attribuez-les en conséquence, sous la forme de tâches pour le développeur approprié. Avec Parasoft, un retour instantané est disponible via des tableaux de bord prédéfinis et personnalisables.
4. Prenez des mesures pour résoudre les avertissements et les violations qui sont publiés et disponibles dans l'EDI de tout le monde pour examen.

La sécurité intégrée dans le cadre de la qualité

La plupart des équipes logicielles comprennent la nécessité de fournir un code de haute qualité, quelle que soit la maturité de leur processus actuel. En tirant parti de cet état d'esprit existant pour améliorer la sécurité, vous pouvez entrelacer les exigences, les contrôles et les normes de sécurité dans le cadre de votre processus d'amélioration de la qualité existant. Au niveau du tableau de bord, la visualisation de la conformité de la sécurité en temps réel, avec la possibilité de creuser les zones problématiques en fonction des zones de préoccupation mises en évidence, aide la sécurité à faire partie de la gestion quotidienne de la qualité.

Résumé

Il est important de donner la priorité à la sécurité le plus tôt possible dans le cycle de vie du développement pour «passer à gauche» à la fois l'application des normes de sécurité et des bonnes pratiques, et réussir à atteindre DevSecOps. Pour cela, vous avez besoin d'un processus accessible et facile à adopter pour détecter et supprimer les vulnérabilités dès que le code est écrit par les développeurs. Les tableaux de bord d'analyse et de reporting en temps réel et personnalisables de Parasoft fournissent un retour instantané aux chefs d'équipe et aux experts en sécurité sur l'état du projet, sa conformité aux normes choisies et exactement où se trouvent les préoccupations les plus importantes, afin que l'ensemble de l'organisation puisse comprendre les risques.

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.