Explorer la validation continue de la sécurité

Effectué

Les développeurs modernes utilisent régulièrement des composants disponibles dans des sources de package publiques telles que npm, NuGet, PyPI, Maven Central et RubyGems. Cette pratique est devenue standard dans le secteur des logiciels, car les organisations adoptent des composants logiciels open source (OSS) pour une livraison plus rapide et une meilleure productivité.

L'épée à double tranchant des composants tiers

Avantages des composants tiers :

• Développement plus rapide : Les développeurs n’ont pas besoin de créer de fonctionnalités courantes à partir de zéro.
• Solutions éprouvées : Les packages populaires ont été testés par des milliers d’utilisateurs.
• Support communautaire : Les communautés actives fournissent de la documentation, des mises à jour et de l’assistance.
• Économies: Les composants OSS gratuits réduisent considérablement les coûts de développement.
• Accélération de l’innovation : Teams peut se concentrer sur une logique métier unique plutôt que de réinventer les fonctionnalités standard.

Risques de sécurité et de conformité croissants : Toutefois, étant donné que la dépendance vis-à-vis des composants OSS tiers augmente, les risques sont donc les suivants :

Vulnérabilités de sécurité :

• Les packages tiers peuvent contenir des vulnérabilités de sécurité connues que les attaquants peuvent exploiter.
• Les vulnérabilités sont découvertes en continu dans les packages existants.
• Les dépendances transitives (dépendances de vos dépendances) introduisent des vulnérabilités dont vous n’êtes peut-être pas conscient.
• Les attaques de chaîne d’approvisionnement ciblent des packages populaires pour compromettre de nombreuses applications en aval.

Problèmes de conformité des licences :

• Les exigences de licence masquées peuvent créer des obligations légales.
• Certaines licences OSS vous obligent à ouvrir votre propre code si vous utilisez leurs composants.
• Les violations de licence peuvent entraîner des poursuites, des pénalités financières et des versions forcées du code.
• Différentes licences peuvent être incompatibles les unes avec les autres, créant des conflits de conformité.

Critique pour l’entreprise : Pour une entreprise, ces problèmes sont essentiels. Les problèmes liés à la conformité, aux passifs et aux données personnelles des clients peuvent entraîner de graves problèmes de confidentialité et de sécurité :

• Responsabilité légale : Les violations de licence exposent les organisations à des actions légales.
• Violations de données : Les composants vulnérables peuvent entraîner des violations de données affectant les données personnelles des clients.
• Conformité réglementaire : Les violations de réglementations telles que RGPD, CCPA ou HIPAA peuvent entraîner des amendes importantes.
• Dommages à la réputation : Les incidents de sécurité et les violations de licence endommagent la confiance du client et la réputation de la marque.
• Contrats client : Les clients d’entreprise nécessitent souvent des garanties de sécurité et de conformité que les composants vulnérables violent.

Valeur de la détection anticipée

Avertissement avancé : L’identification des problèmes de sécurité et de conformité au début du cycle de mise en production fournit un avertissement avancé et suffisamment de temps pour résoudre les problèmes avant qu’ils atteignent la production.

Coût de la correction : Le coût de la correction des problèmes est considérablement plus bas plus tôt le problème est découvert dans le projet.

• Pendant le développement : Changer une dépendance coûte des heures de travail du développeur.
• Pendant les tests : La résolution des problèmes nécessite de retester l’ensemble de l’application.
• En production : La correction nécessite une mise à jour corrective d’urgence, une réponse aux incidents de sécurité, des notifications client et des rapports réglementaires potentiels.

Impact économique : Les études montrent que les problèmes de sécurité trouvés en production coûtent 10 à 100 fois plus à résoudre que ceux détectés pendant le développement.

Validation continue de la sécurité de l’intégration

Une fois le code fusionné dans la branche principale, la validation de sécurité complète doit s’exécuter dans le cadre du processus de génération d’intégration continue (CI).

Build CI vs. Build PR-CI

CI de demande de tirage (PR-CI) : s’exécute pendant la validation de la demande de tirage avant la fusion du code. Fournit des commentaires rapides pour empêcher le code vulnérable d’entrer dans la base de code.

Compilation CI complète : S’exécute une fois le code fusionné dans la branche principale. Inclut des vérifications plus complètes et prépare les artefacts pour le déploiement.

Différences classiques : La principale différence entre PR-CI et les builds CI complètes est que PR-CI n’a pas besoin d’empaquetage ou d’artefacts intermédiaires générés par la build CI complète. Cela permet à PR-CI de fonctionner rapidement tout en conservant la validation de la sécurité.

Les deux doivent inclure des vérifications de sécurité : Les deux types de build doivent exécuter des validations de sécurité principales, mais les builds CI complètes peuvent inclure des vérifications plus longues.

Analyse statique du code dans les builds CI

But: Les builds CI doivent exécuter des tests d’analyse de code statique pour s’assurer que le code suit toutes les règles pour la maintenance et la sécurité.

Outils d’analyse statique courants :

SonarQube :

• Plateforme complète de qualité et de sécurité du code.
• Détecte les bogues, les odeurs de code et les vulnérabilités de sécurité.
• Effectue le suivi des métriques de qualité du code au fil du temps.
• Intègre des portes de qualité qui échouent lorsque les seuils de qualité ne sont pas respectés.
• Prend en charge plusieurs langages de programmation.

Analyse de Visual Studio Code et Roslyn Security Analyzers :

• Analyse intégrée pour les applications .NET.
• Roslyn Security Analyzers détecte les vulnérabilités de sécurité dans le code C#.
• S’exécute pendant la compilation en fournissant des commentaires immédiats.
• Aucune infrastructure supplémentaire n’est requise pour les projets .NET.

Checkmarx :

• Outil SAST (Static Application Security Testing).
• Analyse approfondie de la sécurité du code source.
• Identifie les vulnérabilités telles que l’injection SQL, XSS et les problèmes d’authentification.
• Fournit des conseils de correction détaillés.
• Prend en charge de nombreux langages et frameworks de programmation.

BinSkim :

• Outil d’analyse statique binaire de Microsoft.
• Fournit des résultats de sécurité et de correction pour les exécutables portables Windows (fichiers PE).
• Analyse les fichiers binaires compilés plutôt que le code source.
• Identifie les problèmes de sécurité dans les paramètres de compilation et la structure binaire.
• Utile pour analyser les composants compilés tiers.

Outils supplémentaires :

• ESLint avec plug-ins de sécurité : Analyse de sécurité JavaScript/TypeScript.
• Bandit: Analyse de sécurité Python.
• Brakeman: Analyseur de sécurité pour Ruby on Rails.
• gosec : Outil de vérification de sécurité pour Go.

Intégration d’Azure Pipelines : De nombreux outils de sécurité s’intègrent en toute transparence à Azure Pipelines et à d’autres plateformes CI/CD. Visual Studio Marketplace fournit des extensions pour différents outils de sécurité, ce qui simplifie l’intégration :

• Les outils apparaissent en tant que tâches de pipeline que vous pouvez ajouter à votre définition de pipeline.
• Les résultats s'affichent dans les logs de pipeline et peuvent faire échouer les builds lorsque des problèmes sont détectés.
• Les résultats de sécurité s’intègrent au suivi des éléments de travail Azure DevOps.

Analyse des vulnérabilités des packages tiers

Critique mais souvent négligé : Au-delà de la vérification de la qualité du code, deux autres validations critiques sont souvent ignorées ou exécutées de manière incorrecte :

1. Analyse des packages tiers pour détecter les vulnérabilités de sécurité connues.
2. Vérification de la conformité des licences OSS.

Réponse organisationnelle courante : Lorsqu’on vous demande des vulnérabilités et des licences de package tierces, de nombreuses organisations répondent à la peur ou à l’incertitude. Ils n’ont pas de processus clairs pour gérer ces risques.

Problèmes de processus manuels : Les organisations qui tentent de gérer les vulnérabilités des packages tiers ou les licences OSS expliquent souvent que leur processus est fastidieux et manuel :

• Les développeurs recherchent manuellement des bases de données de vulnérabilité.
• Les équipes de sécurité gèrent les feuilles de calcul des packages approuvés.
• Les révisions de licence nécessitent une implication de l’équipe juridique pour chaque package.
• Les mises à jour sont suivies manuellement, ce qui entraîne des informations de dépendance obsolètes.
• Le processus prend des semaines, ce qui ralentit considérablement le développement.

Solutions automatisées : Les outils d’analyse de composition logicielle moderne automatisent ce processus d’identification, ce qui le rend presque instantané :

Mend (anciennement WhiteSource) :

• Détecte automatiquement tous les composants OSS dans vos applications.
• Identifie les vulnérabilités de sécurité connues dans les dépendances.
• Vérifie la conformité des licences par rapport aux stratégies organisationnelles.
• Fournit des conseils de correction, notamment les versions fixes disponibles.
• Surveille en permanence les nouvelles vulnérabilités dans les packages utilisés.

GitHub Dependabot :

• Analyse automatiquement les dépendances pour détecter les vulnérabilités connues.
• Crée des pull requests pour mettre à jour les dépendances vulnérables.
• Prend en charge de nombreux écosystèmes de packages (npm, Maven, pip, etc.).
• Gratuit pour les dépôts GitHub publics et privés.

Snyk :

• Outil de sécurité de premier développeur pour la recherche et la résolution des vulnérabilités.
• Analyse les dépendances, les images conteneur et l’infrastructure en tant que code.
• Fournit des conseils de correction et des demandes de tirage automatisées.
• S’intègre aux IDE, au contrôle de code source et aux pipelines CI/CD.

Sources en amont d’Azure Artifacts :

• Peut être configuré pour analyser des packages à partir de sources en amont.
• Bloque les packages avec des vulnérabilités connues.
• Fournit une visibilité sur tous les packages utilisés au sein de l’organisation.

Avantages de l’analyse de composition logicielle

Visibilité complète : Les outils SCA fournissent une visibilité complète de votre chaîne d’approvisionnement logicielle :

• Dressez l'inventaire de toutes les dépendances directes et transitives.
• Effectuez le suivi des versions et de l’état de mise à jour.
• Identifiez les composants qui ne sont plus conservés.
• Cartographiez les dépendances par rapport à des applications et des équipes spécifiques.

Hiérarchisation des risques : Toutes les vulnérabilités ne sont pas tout aussi critiques. Les outils SCA permettent de hiérarchiser les priorités :

• Scores de gravité (évaluations CVSS) indiquant la gravité des vulnérabilités.
• Évaluations d’exploitabilité montrant si des attaques sont connues.
• Analyse d’accessibilité déterminant si le code vulnérable est réellement utilisé dans votre application.
• Contexte métier sur lequel les applications sont les plus critiques.

Surveillance continue : Les vulnérabilités de sécurité sont découvertes en permanence. Les outils SCA fournissent une surveillance continue :

• Alertes quand de nouvelles vulnérabilités sont découvertes dans les packages que vous utilisez.
• Rapports réguliers sur les tendances de posture de sécurité.
• Intégration avec les systèmes de suivi des problèmes pour gérer le travail de correction.

Documentation de conformité : Les outils SCA génèrent des rapports de conformité :

• Obligations de licence pour tous les composants utilisés.
• Exigences d’attribution qui doivent être remplies.
• Preuve que des examens de sécurité ont été effectués.
• Vérification des pistes de conformité réglementaire.

Intégration dans la chaîne de traitement

La validation de sécurité continue s’intègre à votre pipeline CI/CD en tant que tâches automatisées :

1. Fusion de code : Le pull request est approuvé et le code fusionne dans la branche principale.
2. Déclencheurs de build CI : La fusion déclenche automatiquement une build CI complète.
3. Exécutions d’analyse statique : Les outils SAST analysent le code source pour les vulnérabilités.
4. Analyse des dépendances : Les outils SCA analysent toutes les dépendances pour détecter les vulnérabilités et les problèmes de licence.
5. Portes de qualité : la build échoue si les problèmes de sécurité dépassent les seuils acceptables.
6. Résultats disponibles : Les résultats de sécurité sont disponibles pour les développeurs et les équipes de sécurité.
7. Création d’artefacts : Si les contrôles de sécurité passent, les artefacts de build sont créés pour le déploiement.

Dans les modules ultérieurs, nous aborderons l’intégration de plusieurs outils de sécurité et de conformité utiles et couramment utilisés dans votre configuration de pipeline spécifique.