Explorer les points de validation clés

La validation continue de la sécurité doit être intégrée à chaque étape du développement à la production pour garantir que les applications restent sécurisées tout au long de leur cycle de vie. Cette approche transforme la façon dont les équipes de sécurité interagissent avec le développement, passant de l’approbation manuelle de chaque version à la supervision et à l’audit continus de l’ensemble du processus CI/CD.

Transformation de la conversation de sécurité

Approche traditionnelle : Les équipes de sécurité examinent et approuvent manuellement chaque version avant de pouvoir passer en production. Cela crée des goulots d’étranglement, des retards de mise en production et ne s’adapte pas aux fréquences de déploiement modernes.

Approche DevOps sécurisée : Les équipes de sécurité consentent au processus CI/CD lui-même plutôt qu’aux versions individuelles. Ils définissent les exigences de sécurité, implémentent la validation automatisée et surveillent le processus en continu. La sécurité devient intégrée plutôt qu’une porte distincte.

Avantages de ce changement :

• Les mises en production se poursuivent automatiquement lorsqu’elles répondent aux critères de sécurité.
• Les équipes de sécurité se concentrent sur l’amélioration du processus plutôt que sur l’examen des modifications individuelles.
• La validation de la sécurité est mise à l’échelle pour prendre en charge plusieurs déploiements par jour.
• Les pistes d'audit documentent la validation de la sécurité de manière automatique.
• Les problèmes de sécurité sont détectés immédiatement plutôt qu’au moment de l’examen.

Points de validation critiques dans le pipeline

Le diagramme ci-dessous met en évidence les points de validation critiques dans un pipeline CI/CD pour la création d’applications à partir de la base :

Implémentation progressive : Vous pouvez implémenter progressivement des outils de validation de sécurité en fonction de la plateforme et de l’étape de cycle de vie de votre application. Cette approche par phases est particulièrement importante si votre produit est mature et que vous n’avez pas déjà exécuté la validation de sécurité sur votre site ou votre application. L’introduction de toutes les vérifications de sécurité à la fois peut submerger les équipes avec des résultats.

Stratégie de hiérarchisation : Lors de l’implémentation de la validation de sécurité dans les applications existantes :

1. Commencez par les vérifications de sécurité les plus critiques (détection de secrets, vulnérabilités connues).
2. Abordez les constats dans les domaines à haut risque.
3. Étendez progressivement la couverture aux contrôles de sécurité supplémentaires.
4. Paramétrez les outils pour réduire les faux positifs avant d’ajouter d’autres vérifications.
5. Créez une approbation de développeur en démontrant la valeur de l’automatisation de la sécurité.

Validation de l’IDE et de la pull request

La validation de la sécurité commence avant que les développeurs valident leur code dans le référentiel partagé. Cette approche de « décalage vers la gauche » intercepte les problèmes dès que possible lorsqu’elles sont plus simples et moins coûteuses à résoudre.

Vérifications de sécurité au niveau de l’IDE

Analyse statique du code dans l’IDE : Les outils d’analyse de code statique intégrés à l’IDE fournissent la première ligne de défense pour s’assurer que les vulnérabilités de sécurité ne sont pas introduites dans le processus CI/CD.

Commentaires en temps réel : Les développeurs reçoivent des commentaires immédiats sur les problèmes de sécurité au fur et à mesure qu’ils écrivent du code :

• Les vulnérabilités de sécurité sont mises en surbrillance directement dans l’éditeur de code.
• Les suggestions de pratiques de codage sécurisées s’affichent en tant que types de développeurs.
• Des correctifs rapides pour les problèmes de sécurité courants sont disponibles en un seul clic.
• Les explications aident les développeurs à comprendre pourquoi certains modèles sont problématiques.

Exemples d’outils de sécurité IDE :

• Extensions de sécurité Visual Studio Code : Les extensions telles que Snyk, SonarLint et GitHub Copilot fournissent des conseils de sécurité lors du codage.
• Plug-ins de sécurité IntelliJ IDEA : Les plug-ins axés sur la sécurité analysent le code en temps réel.
• Analyseurs de sécurité Visual Studio : Les analyseurs intégrés détectent les problèmes de sécurité pendant le développement.

Avantages des vérifications au niveau de l’IDE :

• Les problèmes sont détectés lorsque le code est écrit, pas de jours ou de semaines plus tard.
• Les développeurs apprennent des pratiques de codage sécurisées par le biais de commentaires immédiats.
• Les problèmes de sécurité sont résolus avant la validation du code, ce qui réduit les défaillances du pipeline.
• La boucle de rétroaction est mesurée en secondes, pas en heures ou jours.

Contrôles de validation de référentiel

Empêcher le code vulnérable d’entrer dans la base de code : Le processus de validation du code dans un référentiel central doit avoir des contrôles qui empêchent l’introduction de vulnérabilités de sécurité.

Stratégies de branche Git : L’utilisation du contrôle de code source Git dans Azure DevOps, GitHub ou des plateformes similaires avec des stratégies de branche fournit une expérience de validation contrôlée qui applique la validation de sécurité :

Application de la protection des branches : L’activation de stratégies de branche sur des branches partagées (comme main ou develop) nécessite une pull request pour démarrer le processus de fusion. Les validations directes sur les branches protégées sont bloquées, ce qui garantit que toutes les modifications de code transitent par le processus de validation.

Conditions requises pour les demandes de tirage : Les demandes de tirage doivent appliquer plusieurs exigences pertinentes en matière de sécurité :

Exigence de révision du code :

• Au moins un autre développeur doit passer en revue les modifications du code.
• Cette révision manuelle est essentielle pour identifier les problèmes de sécurité que les outils automatisés risquent de manquer.
• Les réviseurs doivent rechercher spécifiquement des problèmes de sécurité, notamment :
  • Validation d’entrée appropriée.
  • Vérifications d’authentification et d’autorisation appropriées.
  • Gestion sécurisée des données sensibles.
  • Utilisation correcte des bibliothèques et infrastructures de sécurité.
  • Absence de secrets ou d’informations d’identification codés en dur.

Liaison des éléments de travail :

• Les validations doivent être liées à des éléments de travail (récits, tâches, bogues) pour l’audit.
• Cette liaison documente la raison pour laquelle la modification du code a été apportée.
• Les pistes d’audit aident les équipes de sécurité à comprendre le contexte des modifications pendant les enquêtes sur les incidents.
• La liaison d’éléments de travail permet la traçabilité des exigences par le biais du déploiement.

Exigence de construction pour l'intégration continue (CI) :

• Un processus de génération CI doit réussir avant que la demande de tirage puisse être fusionnée.
• La build CI inclut des vérifications de sécurité automatisées (décrites dans la section suivante).
• Les vérifications de sécurité ayant échoué bloquent la fusion, empêchant ainsi le code vulnérable d’entrer dans la branche principale.
• Les résultats de la génération sont visibles dans la demande de tirage, ce qui donne aux réviseurs le contexte de sécurité.

Vérifications d’état :

• Les outils de sécurité externes peuvent signaler des contrôles d'état sur les pull requests.
• Toutes les vérifications d’état requises doivent être effectuées avant la fusion.
• Les équipes de sécurité peuvent ajouter de nouvelles vérifications requises sans modifier les définitions de pipeline.

Exemple de configuration de stratégie de branche :

Dans Azure DevOps ou GitHub, les stratégies de branche peuvent nécessiter :

• Minimum de 1 approbation de réviseur (2 pour les branches critiques).
• Éléments de travail liés pour toutes les modifications.
• Validation de build réussie.
• Tous les commentaires résolus avant la fusion.
• Branches à jour (doit incorporer les dernières modifications avant la fusion).
• Vérifications d’état requises à partir des outils de sécurité qui passent.

Avantages de la validation des pull requests :

• Les vérifications de sécurité se produisent avant que le code n’entre dans la base de code partagée.
• Plusieurs perspectives examinent le code pour les problèmes de sécurité.
• Les pistes d’audit indiquent qui ont approuvé des modifications potentiellement risquées.
• Les développeurs reçoivent des commentaires de sécurité dans leur flux de travail normal.
• L’équipe crée une culture de sensibilisation à la sécurité par le biais de révisions de code.

Vérifications de sécurité automatisées dans les pull requests :

Les demandes de tirage peuvent déclencher une analyse de sécurité automatisée :

• Analyse statique : Le code est analysé pour les vulnérabilités de sécurité.
• Vérifications des dépendances : Les dépendances nouvelles ou mises à jour sont vérifiées pour les vulnérabilités connues.
• Détection de secrets : Des analyses détectent les identifiants validés accidentellement.
• Vérifications de la qualité du code : L’analyse identifie les problèmes de qualité du code susceptibles d’entraîner des problèmes de sécurité.

Les résultats s’affichent directement dans l’interface de la pull request, ce qui permet aux réviseurs et aux auteurs de résoudre les problèmes avant la fusion.