Inspecter et valider les bases de code pour la conformité

  • 5 minutes

Avant d’implémenter des outils automatisés d’analyse de composition logicielle, les organisations doivent comprendre ce qui doit être inspecté et validé dans leurs bases de code. Les applications modernes contiennent des centaines ou des milliers de dépendances, ce qui rend l’inspection manuelle impraticable. Les approches systématiques pour la découverte de dépendances, l’évaluation des vulnérabilités et la validation de conformité sont essentielles.

Pourquoi l’inspection et la validation ont une importance

Défi de dépendance : Les applications ne dépendent pas seulement des packages que vous importez directement. Chaque dépendance directe dépend généralement de packages supplémentaires (dépendances transitives), de la création d’arborescences de dépendances profondes. Une application classique peut référencer directement 20 à 30 paquets et pourrait dépendre de 200 à 500 paquets transitivement. Vous êtes responsable des vulnérabilités et des obligations de licence dans toutes les dépendances, pas seulement les dépendances directes.

Impératif de sécurité : Les vulnérabilités de sécurité dans les dépendances représentent des risques importants. Les attaquants exploitent activement les vulnérabilités connues dans les packages populaires, ce qui rend les dépendances non corrigées des cibles attrayantes. Les violations à profil élevé impliquent souvent l’exploitation des vulnérabilités connues dans les composants open source que les organisations n’ont pas pu mettre à jour.

Exigence de conformité : Les violations de licence peuvent entraîner une action juridique, l’ouverture forcée du code propriétaire, des restrictions de distribution et des dommages de réputation. Les organisations doivent suivre les obligations de licence pour chaque dépendance et garantir la conformité aux termes du contrat de licence.

La réalité opérationnelle : Les dépendances changent constamment. De nouvelles vulnérabilités sont divulguées quotidiennement, les packages reçoivent des mises à jour, des maintenances abandonnent des projets et de nouvelles versions sont publiées. L’inspection ponctuelle n’est pas suffisante : la validation continue est requise.

Que faire pour inspecter et valider

L’inspection complète de la base de code couvre plusieurs dimensions :

Inventaire des dépendances

Création d’une facture complète de matériaux :

  • Dépendances directes : Packages explicitement répertoriés dans les fichiers manifeste de package (package.json, requirements.txt, pom.xml, *.csproj).
  • Dépendances transitives : Packages requis par vos dépendances directes, plusieurs niveaux de profondeur.
  • Dépendances de développement : Packages utilisés pendant le développement et les tests, mais pas fournis avec du code de production.
  • Suivi des versions : Versions spécifiques de chaque package actuellement en cours d’utilisation.
  • Sources de dépendances : Quels registres de packages fournissent des dépendances (npm, PyPI, NuGet, Maven Central, registres privés).

Pourquoi les inventaires complets sont importants :

  • Gestion des vulnérabilités : Vous ne pouvez pas corriger les vulnérabilités que vous ne connaissez pas.
  • Conformité des licences : Doit suivre les obligations de licence pour toutes les dépendances, et pas seulement les obligations directes.
  • Planification des mises à jour : La compréhension des relations de dépendance permet de planifier les mises à jour qui ne rompront pas la compatibilité.
  • Visibilité de la chaîne d’approvisionnement : Sachez exactement quel code externe est inclus dans vos applications.

Détection des vulnérabilités de sécurité

Identification des vulnérabilités connues :

  • Mappage CVE (Vulnérabilités et expositions courantes) : Mettre en correspondance les versions de dépendances par rapport aux bases de données CVE contenant des vulnérabilités connues.
  • Évaluation de la gravité : Évaluez la gravité des vulnérabilités à l’aide des scores CVSS (Common Vulnerability Scoring System) compris entre 0 et 10.
  • Analyse de l’exploitabilité : Déterminez si les vulnérabilités sont activement exploitées dans la nature.
  • Disponibilité des correctifs : Identifiez les versions qui corrigent les vulnérabilités et indiquez si les correctifs sont disponibles.

Présentation des bases de données de vulnérabilité :

  • Base de données de vulnérabilité nationale (NVD) : Référentiel de données de vulnérabilité du gouvernement américain basé sur les identificateurs CVE.
  • Base de données de conseil GitHub : Conseils de sécurité organisés pour les packages dans plusieurs écosystèmes.
  • Listes de diffusion de sécurité : Notifications de sécurité propres au langage et à l’infrastructure.
  • Bases de données du fournisseur : Les outils SCA commerciaux gèrent les bases de données de vulnérabilité propriétaires avec des informations supplémentaires.

Catégories de vulnérabilités dans les dépendances :

  • Défauts d’injection : Injection SQL, injection de commandes, vulnérabilités de script intersites dans les frameworks web.
  • Problèmes d’authentification : Implémentations d’authentification faibles, problèmes de gestion de session, failles de gestion des informations d’identification.
  • Exposition des données sensibles : Stockage de données non sécurisé, chiffrement insuffisant, fuite d’informations.
  • Configuration incorrecte de la sécurité : Configurations par défaut avec faiblesses connues, fonctionnalités inutiles activées.
  • Déni de service : Vulnérabilités d’épuisement des ressources, problèmes de complexité algorithmique.
  • Défauts de désérialisation : Désérialisation non sécurisée menant à l’exécution de code à distance.

Validation de conformité des licences

Identification des obligations de licence :

  • Détection de licence : Identifiez les licences qui s’appliquent à chaque dépendance.
  • Classification des licences : catégoriser les licences comme permissives, faible copyleft, copyleft forte ou propriétaire.
  • Analyse de compatibilité : Vérifiez que les licences de différentes dépendances sont compatibles lorsqu’elles sont combinées.
  • Suivi des obligations : Documentez les exigences telles que l’attribution, la divulgation de code source ou les licences de travail dérivées.

Problèmes de conformité courants :

  • Contamination de Copyleft : Les dépendances sous licence GPL dans les logiciels propriétaires peuvent nécessiter l’ouverture du code source de l’application entière.
  • Échecs d’attribution : Avis de droits d’auteur et texte de licence manquants dans les logiciels distribués.
  • Combinaisons incompatibles : Utilisation de dépendances avec des licences en conflit qui ne peuvent pas être combinées légalement.
  • Modifications de licence : Les projets modifient parfois les licences entre les versions, ce qui nécessite une nouvelle évaluation.

Évaluation des risques de licence :

  • Risque élevé : Licences copyleft fortes (GPL, AGPL) dans la distribution de logiciels propriétaires.
  • Risque moyen : Licences copyleft faibles (LGPL, MPL) nécessitant des pratiques d’intégration minutieuses.
  • Faible risque : Licences permissives (MIT, Apache 2.0, BSD) avec des restrictions minimales.
  • Risque inconnu : Licences personnalisées, licences non claires ou informations de licence manquantes.

Évaluation de la qualité des dépendances

Évaluation de la maintenance des dépendances :

  • État de maintenance : Déterminez si les dépendances sont activement conservées ou abandonnées.
  • Fréquence de mise à jour : Évaluez la fréquence à laquelle les dépendances reçoivent des mises à jour et des correctifs de bogues.
  • Santé communautaire : Évaluez l’activité des contributeurs, les temps de réponse des problèmes et l’engagement de la communauté.
  • Qualité de la documentation : Vérifiez si les dépendances disposent d’une documentation adéquate pour une utilisation appropriée.
  • Pratiques de sécurité : Vérifiez que les projets ont des processus de divulgation responsable et des avis de sécurité.

Indicateurs de qualité :

  • Maintenance active : Validations régulières, versions récentes, maintenances réactives.
  • Grande communauté : De nombreux contributeurs, étoiles, fournisseurs et utilisateurs contribuent à la durabilité.
  • Communication claire : Suivi des problèmes actifs, discussions réactives, notes de publication claires.
  • Sensibilisation à la sécurité : Politique de sécurité publiée, mise à jour rapide des vulnérabilités, avis de sécurité.

Indicateurs rouges :

  • Projets abandonnés : Aucune mise à jour pendant des années, des maintenances non répondantes, accumulent des problèmes non traités.
  • Risque de maintenance unique : Dépendance critique maintenue par une personne susceptible de devenir indisponible.
  • Mauvaise qualité : Tests insuffisants, bogues fréquents, changements cassants dans les versions mineures.
  • Manque de sécurité : Aucune stratégie de sécurité, réponse lente aux vulnérabilités, problèmes de sécurité non fermés.

Défis manuels liés à l’inspection

Pourquoi l’inspection manuelle n’est pas mise à l’échelle :

Volume écrasant

  • Centaines de dépendances : Même les petites applications dépendent de centaines de packages.
  • Plusieurs applications : Les organisations gèrent des dizaines ou des centaines d’applications, multipliant le nombre de dépendances.
  • Modifications constantes : Les nouvelles versions publiées quotidiennement rendent tous les inventaires manuels immédiatement obsolètes.
  • Erreur humaine : Le suivi manuel manque inévitablement les dépendances, en particulier les dépendances transitives.

Informations dispersées

  • Plusieurs sources : Les informations sur les vulnérabilités proviennent des bases de données CVE, des listes de diffusion de sécurité, des avis GitHub, des notifications du fournisseur et des divulgations de chercheurs de sécurité.
  • Recherche de licence : La détermination des licences exactes nécessite l’examen des fichiers de code source, des documents lisez-moi et des fichiers de licence dans chaque package.
  • Détails spécifiques à la version : Les vulnérabilités et les licences peuvent changer entre les versions, nécessitant une recherche spécifique à la version.
  • Informations en conflit : Différentes sources fournissent parfois des informations de vulnérabilité ou de licence contradictoires.

Analyse fastidieuse

  • Évaluation des vulnérabilités : La recherche de la gravité, de l’exploitabilité et de l’état des correctifs de chaque vulnérabilité prend beaucoup de temps.
  • Analyse des licences : Comprendre les termes du contrat de licence, la compatibilité et les obligations nécessite une expertise juridique.
  • Planification des mises à jour : La détermination des chemins de mise à jour sécurisés compte tenu des changements cassants et des conflits de dépendances est complexe.
  • Surveillance continue : La surveillance continue des nouvelles vulnérabilités et des mises à jour nécessite des ressources dédiées.

Détection différée

  • Décalage de découverte : Les processus manuels détectent les vulnérabilités semaines ou mois après la divulgation.
  • Réponse réactive : Les organisations en apprennent davantage sur les vulnérabilités des incidents de sécurité que sur l’analyse proactive.
  • Cycles d’audit : Les audits périodiques laissent les applications vulnérables entre les audits.
  • Correctifs d’urgence : Sans surveillance continue, les vulnérabilités critiques nécessitent des correctifs d’urgence perturbants.

La solution automatisée

Les outils d’analyse de composition logicielle résolvent les problèmes d’inspection manuels :

Découverte automatisée

  • Analyse des dépendances : Les outils SCA analysent automatiquement les fichiers manifestes de package pour identifier les dépendances.
  • Résolution transitive : Les outils suivent les chaînes de dépendances pour créer une facture complète de matériaux.
  • Analyse des fichiers de verrouillage : Analysez les fichiers de verrouillage (package-lock.json, Pipfile.lock) pour déterminer exactement quelles versions sont installées.
  • Analyse binaire : Certains outils analysent les fichiers binaires compilés et les conteneurs pour découvrir les dépendances incorporées.

Surveillance continue

  • Alertes de vulnérabilité en temps réel : Recevez des notifications immédiates lorsque de nouvelles vulnérabilités affectent vos dépendances.
  • Mises à jour automatisées : Les outils tels que GitHub Dependabot créent automatiquement des pull requests lorsque des mises à jour de sécurité sont disponibles.
  • Visibilité du tableau de bord : Les tableaux de bord centralisés affichent l’état des vulnérabilités dans toutes les applications.
  • Analyse planifiée : Les analyses automatisées régulières garantissent que les données de dépendance restent actuelles.

Bases de données complètes

  • Données de vulnérabilité agrégées : Les outils SCA agrègent les informations de NVD, gitHub Advisory Database, les listes de diffusion de sécurité et les bases de données des fournisseurs.
  • Bases de données de licence : Conservez des informations complètes sur la licence, y compris les textes de licence complets et les résumés des obligations.
  • Curation et vérification : Les fournisseurs vérifient et organisent les données de vulnérabilité pour réduire les faux positifs.
  • Intelligence propriétaire : Les outils commerciaux fournissent des recherches et des analyses supplémentaires au-delà des bases de données publiques.

Analyse intelligente

  • Scoring de gravité : calcule automatiquement les scores CVSS et hiérarchise les vulnérabilités par risque.
  • Analyse de la portée : Déterminez si les chemins de code vulnérables sont réellement utilisés dans votre application.
  • Conseils de correction : Fournissez des recommandations de version spécifiques qui corrigent les vulnérabilités tout en conservant la compatibilité.
  • Application de la stratégie : Échec automatique des builds ou blocages de déploiements lorsque des violations de stratégie sont détectées.

Établissement de bases de référence de validation

Avant d’implémenter l’analyse automatisée, établissez des critères de validation :

Stratégies de sécurité

  • Tolérance aux vulnérabilités : Définissez les niveaux de gravité des vulnérabilités acceptables (par exemple, aucun niveau critique ou élevé, un niveau moyen limité).
  • Délais de mise à jour corrective : Établissez la rapidité avec laquelle différentes vulnérabilités de gravité doivent être corrigées.
  • Processus d’exception : Créez des procédures pour accepter les risques lorsque la mise à jour corrective immédiate n’est pas réalisable.
  • Exigences en matière de création de rapports : Définissez qui a besoin de notifications de vulnérabilité et de la rapidité.

Stratégies de conformité

  • Licences approuvées : Répertoriez les licences toujours acceptables (par exemple, MIT, Apache 2.0).
  • Licences restreintes : Identifiez les licences nécessitant une approbation spéciale (par exemple, LGPL) ou une interdiction (p. ex.,PG pour les logiciels propriétaires).
  • Exigences d’attribution : Définissez la façon dont l’attribution doit être fournie dans les logiciels distribués.
  • Pistes d’audit : Spécifiez les exigences de documentation pour les preuves de conformité.

Normes de qualité

  • Exigences de maintenance : Définissez les attentes de maintenance minimales (par exemple, les mises à jour au cours de l’année dernière).
  • Taille de la communauté : Établissez des seuils pour les métriques de santé de la communauté acceptables.
  • Normes de documentation : Spécifiez la configuration minimale requise pour les dépendances.
  • Pratiques de sécurité : Exiger que les dépendances aient publié des stratégies de sécurité et une gestion des vulnérabilités réactives.

Comprendre ce qu’il faut inspecter et valider constitue la base de l’implémentation d’outils d’analyse de composition logicielle automatisée. L’unité suivante explore les principes fondamentaux de la SCA et explique comment les outils automatisés répondent aux défis de la gestion manuelle des dépendances.