Explorez les préoccupations de l’entreprise avec les composants logiciels open source

  • 8 minutes

Le développement logiciel moderne dépend fondamentalement des composants open source. Cette dépendance présente des préoccupations importantes pour les organisations qui créent des logiciels, que ce soit pour la vente commerciale, l’utilisation interne ou les services publics. Bien que l’open source offre d’énormes avantages, les organisations doivent comprendre et gérer les risques associés.

Le défi fondamental

Les organisations sont confrontées à un acte d’équilibrage critique lors de l’adoption de logiciels open source :

Besoins du développeur : Les développeurs souhaitent utiliser des composants open source qui permettent un développement plus rapide, des frameworks modernes, des bibliothèques éprouvées et des pratiques de développement contemporaines. La restriction de l’utilisation open source réduit la productivité, empêche les développeurs de recruter des ingénieurs talentueux.

Risques organisationnels : Une adoption open source illimitée peut exposer les organisations aux vulnérabilités de sécurité, aux passifs juridiques, aux interruptions opérationnelles et aux violations de conformité. Les entreprises doivent protéger la propriété intellectuelle, maintenir la sécurité, assurer la stabilité opérationnelle et respecter les obligations légales.

La solution : Les organisations réussies trouvent des moyens d’aider les développeurs tout en gérant les risques, ce qui permet l’utilisation open source dans les frameworks de gouvernance qui identifient et atténuent les problèmes potentiels.

Problèmes de sécurité

Les risques de sécurité représentent les préoccupations les plus immédiates et les plus graves concernant les logiciels open source :

Vulnérabilités de sécurité connues

Les composants open source contiennent fréquemment des vulnérabilités de sécurité :

  • Prévalence: Les chercheurs en sécurité découvrent des milliers de nouvelles vulnérabilités dans les composants open source chaque année. La base de données de vulnérabilité nationale (NVD) catalogue les vulnérabilités avec des identificateurs CVE.
  • Plage de gravité : Les vulnérabilités varient des problèmes à faible impact aux défauts critiques qui permettent l’exécution de code à distance, le vol de données ou une compromission complète du système.
  • Délai de divulgation : Les vulnérabilités sont souvent présentes pendant des années avant la découverte. Les applications utilisant des versions affectées restent vulnérables jusqu’à ce que les mises à jour soient appliquées.
  • Dépendances transitives : Les vulnérabilités peuvent ne pas exister dans les packages que vous utilisez directement, mais dans leurs dépendances, ce qui rend la détection plus difficile.

Exemple d’impact : La vulnérabilité Log4Shell (CVE-2021-44228) dans la bibliothèque de journalisation Java populaire Log4j a affecté des millions d’applications dans le monde entier. Les organisations se sont précipitées pour identifier toutes les applications utilisant Log4j et déployer des correctifs, démontrant comment une vulnérabilité open source unique peut avoir des répercussions importantes.

Injection de code malveillante

Les attaques de chaîne d’approvisionnement ciblent des logiciels open source :

  • Détournement de package : Les attaquants contrôlent les comptes de maintenance de package populaires et poussent les mises à jour malveillantes qui volent des informations d’identification, installent des portes dérobées ou minent la crypto-monnaie.
  • Typosquatting : Les packages malveillants avec des noms similaires aux packages populaires inséquent les développeurs pour installer du code compromis (par exemple, « python-dateutil » ou « python-datutil »).
  • Confusion des dépendances : Les attaquants publient des packages malveillants sur des registres publics avec des noms correspondant à des packages privés internes, qui exploitent le comportement de résolution du gestionnaire de package.
  • Compromission de la maintenance : Les attaquants compromissent les comptes de maintenance via le hameçonnage, le vol d’informations d’identification ou l’ingénierie sociale pour injecter du code malveillant dans des packages approuvés.

Exemples d’incidents : Le package eventstream dans npm est compromis pour voler les informations d’identification de portefeuille de crypto-monnaie. Le mainteneur de Colors.js et Faker.js a intentionnellement ajouté des boucles infinies pour protester contre l'utilisation par les entreprises sans soutien financier, mettant en panne des milliers d'applications.

Projets non maintenus et abandonnés

De nombreux projets open source n’ont pas de maintenance active :

  • Abandon du projet : Les mainteneurs perdent de l’intérêt, changent d’emploi ou manquent de temps pour continuer à maintenir des projets. Les projets abandonnés ne reçoivent pas de mises à jour de sécurité même lorsque des vulnérabilités sont découvertes.
  • Risque de maintenance unique : De nombreux projets open source critiques dépendent d’individus uniques. Si cette personne n’est plus disponible, le projet peut devenir effectivement inutilisable pendant la nuit.
  • Défis liés au financement : De nombreux mainteneurs travaillent volontairement. Sans financement, le maintien de grands projets devient insoutenable, ce qui entraîne l’abandon éventuel.
  • Décalage de maintenance : Même les projets actifs peuvent avoir des temps de réponse lents aux problèmes de sécurité, ce qui laisse les applications vulnérables en attendant des correctifs.

Impact organisationnel : Les organisations en fonction des packages non gérés doivent basculer vers des alternatives (nécessitant une refactorisation importante), dupliquer et maintenir le package eux-mêmes (ajout de charge de maintenance) ou continuer à utiliser du code vulnérable (acceptant les risques de sécurité).

Problèmes de qualité et de fiabilité

Au-delà de la sécurité, la qualité du code affecte la fiabilité et la maintenance des applications :

Qualité du code variable

Les composants open source varient considérablement en qualité :

  • Manque de normes de qualité : Les projets open source n’ont pas d’exigences de qualité obligatoires. La qualité du code dépend entièrement des compétences, des pratiques et des priorités de maintenance.
  • Tests limités : Les projets plus petits peuvent avoir un test automatisé minimal, une couverture de cas de périphérie insuffisante ou aucune intégration continue, ce qui augmente la probabilité de bogues.
  • Lacunes de documentation : La documentation insuffisante rend les composants plus difficiles à utiliser correctement, ce qui augmente le risque d’erreurs d’intégration et d’utilisation incorrecte.
  • Problèmes de performances : Les composants peuvent ne pas être optimisés pour les performances, l’extensibilité ou l’efficacité des ressources, ce qui affecte les performances des applications.

Impact sur les composants de faible qualité :

  • Maintenabilité: Une structure de code médiocre rend le débogage et la personnalisation difficiles.
  • Fiabilité: Un test insuffisant entraîne des bogues qui provoquent des échecs d’application.
  • Performance: Les implémentations inefficaces affectent les temps de réponse des applications et l’utilisation des ressources.

Compatibilité et stabilité

Les composants open source ne hiérarchisent pas toujours la compatibilité descendante :

  • Changements cassants : les mises à jour de versions majeures introduisent fréquemment des modifications cassants nécessitant des modifications d’application.
  • Instabilité de l’API : Les projets plus jeunes peuvent changer fréquemment les interfaces à mesure que les conceptions arrivent à maturité.
  • Conflits de dépendances : Les composants peuvent nécessiter des versions spécifiques des dépendances qui entrent en conflit avec d’autres composants.
  • Compatibilité de la plateforme : Tous les composants ne fonctionnent pas sur toutes les plateformes, navigateurs ou environnements.

Les licences open source créent des obligations légales que les organisations doivent respecter :

Obligations de conformité des licences

Chaque licence open source impose des exigences :

  • Conditions requises pour copyleft : Certaines licences (commePG) nécessitent que les dérivés utilisent la même licence, ce qui force potentiellement les organisations à utiliser du code propriétaire open source.
  • Exigences d’attribution : La plupart des licences nécessitent la gestion des avis de copyright et du texte de licence, qui doivent apparaître dans des logiciels distribués.
  • Divulgation de code source : Certaines licences nécessitent de fournir du code source à toute personne qui reçoit des fichiers binaires.
  • Octrois de brevets : Certaines licences incluent des octrois de brevets ou des clauses d’arrêt qui interagissent avec les stratégies de brevet organisationnelles.

Les défaillances de conformité peuvent entraîner :

  • Action juridique : Les titulaires de droits d’auteur peuvent demander une violation de licence, demander des dommages-intérêts et des injonctions.
  • Dommages à la réputation : Les violations de licence deviennent publiques, ce qui nuit à la réputation de l’organisation dans les communautés de développeurs.
  • Restrictions de distribution : La résolution des violations peut nécessiter l’arrêt de la distribution des produits jusqu’à ce que la conformité soit atteinte.
  • Approvisionnement ouvert forcé : Dans les cas extrêmes, les organisations peuvent être tenues d’utiliser du code propriétaire open source qui enfreint les licences copyleft.

Prolifération et compatibilité des licences

Les applications modernes incorporent des centaines de composants avec diverses licences :

  • Inventaire des licences : Les organisations doivent suivre les licences qui s’appliquent à chaque dépendance dans leurs applications.
  • Analyse de compatibilité : Certaines licences ne sont pas compatibles : les logiciels sous LICENCE GÉNÉRALE ne peuvent pas être combinés avec des logiciels sous certaines autres licences.
  • Interprétation des termes du contrat de licence : Les équipes juridiques doivent interpréter les termes du contrat de licence et déterminer les obligations pour des cas d’usage spécifiques.
  • Modification des licences : Les maintenances de projet modifient parfois les licences entre les versions, ce qui nécessite une réévaluation de la conformité.

Échelle du défi : Une application d’entreprise peut dépendre de manière transitive de 500 à 1 000 packages open source avec 20 à 40 licences différentes. Le suivi de la conformité manuellement n’est pas pratique, nécessitant des outils et des processus automatisés.

Préoccupations opérationnelles

Au-delà des risques de sécurité et juridiques, l’open source présente des défis opérationnels :

Dépendance vis-à-vis de l’infrastructure externe

Les écosystèmes open source dépendent de l’infrastructure publique :

  • Disponibilité du Registre : Les applications récupèrent des dépendances à partir de registres de packages publics (npm, PyPI, NuGet). Les pannes de Registre empêchent les builds et les déploiements.
  • Suppression du package : Les auteurs peuvent annuler la publication de packages, en cassant les applications qui en dépendent. L’incident « left-pad » a démontré ce risque lorsque la suppression d’un tout petit package de 11 lignes de code a cassé des milliers d’applications JavaScript.
  • Accès géographique : Certaines organisations opèrent dans des régions disposant d’un accès restreint aux registres de packages publics.
  • Fiabilité du réseau : Les connexions réseau lentes ou non fiables affectent les temps de génération et peuvent entraîner des défaillances de build.

Les stratégies d’atténuation sont les suivantes :

  • Registres privés : Mettre en miroir des packages publics dans des registres privés sous contrôle organisationnel.
  • Packages de fournisseurs : Incluez des dépendances dans le contrôle de code source pour éliminer les dépendances externes pendant la génération.
  • Cache: Packages de cache pour réduire les téléchargements répétés et améliorer la fiabilité des builds.

Charge de gestion des mises à jour

La conservation des dépendances actuelles nécessite un effort continu :

  • Mises à jour continues : De nouvelles versions de package sont publiées en permanence. Les organisations doivent évaluer les mises à jour, tester la compatibilité et déployer des modifications.
  • Urgence de sécurité : Les vulnérabilités de sécurité critiques nécessitent des mises à jour immédiates, ce qui peut perturber le travail planifié.
  • Modifications majeures : Les mises à jour importantes peuvent nécessiter des modifications de code, ce qui augmente la charge de maintenance.
  • Exigences de test : Chaque mise à jour de dépendance nécessite des tests de régression pour s’assurer que rien ne s’arrête.

Sans processus de mise à jour systématique :

  • Dérive des dépendances : Les applications sont en retard sur les versions actuelles, accumulant une dette technique.
  • Exposition à la sécurité : Les vulnérabilités non corrigées restent exploitables.
  • Avalanches de mises à jour : Retarder les mises à jour crée des backlogs volumineux qui deviennent de plus en plus difficiles et risqués à appliquer.

Équilibrage de la liberté et du contrôle

Les organisations doivent développer des stratégies qui équilibrent l’autonomisation des développeurs avec la gestion des risques :

Approches de gouvernance

Les organisations réussies implémentent une gouvernance équilibrée :

Processus de pré-approbation :

  • Évaluation du package : Les équipes de sécurité et juridiques examinent les packages avant la première utilisation, l’évaluation de l’historique de sécurité, la compatibilité des licences et la qualité.
  • Listes de packages approuvées : Conservez les listes organisées de packages pré-approuvés que les développeurs peuvent utiliser librement.
  • Processus d’exception : Permettre aux développeurs de demander l’approbation des packages non sur les listes approuvées, avec l’évaluation par les équipes appropriées.

Analyse automatisée :

  • Analyse des vulnérabilités : Analysez automatiquement les dépendances pour détecter les vulnérabilités connues, en alertant immédiatement les développeurs.
  • Détection de licence : Identifiez les licences pour toutes les dépendances et signalez les licences incompatibles ou préoccupantes.
  • Métriques de qualité : Utilisez l’analyse de code automatisée pour évaluer la qualité des dépendances.

Éducation pour les développeurs :

  • Sensibilisation à la sécurité : Former les développeurs à prendre en compte la sécurité lors de la sélection des dépendances.
  • Compréhension des licences : Aidez les développeurs à comprendre les implications de licence pour différents cas d’usage.
  • Bonnes pratiques : Partagez des instructions pour l’évaluation des composants open source.

Surveillance continue :

  • Nouvelles vulnérabilités : Surveillez les vulnérabilités nouvellement divulguées dans les dépendances existantes.
  • Modifications de licence : Suivez le moment où les projets modifient les licences.
  • État de maintenance : Identifiez quand les dépendances ne sont plus maintenues.

Préoccupations pour les organisations qui publient open source

Les organisations qui publient leurs propres logiciels open source font face à d’autres défis :

Considérations relatives au modèle métier

La monétisation de logiciels open source nécessite une stratégie prudente :

  • Modèle open-core : Offrir des fonctionnalités de base en tant qu’open source tout en vendant des extensions propriétaires ou des fonctionnalités d’entreprise.
  • Support et services : Fournissez librement des logiciels open source, mais vendez des contrats de support, des conseils ou des formations.
  • Services hébergés : Open source du logiciel, mais vendre des services d’hébergement gérés.
  • Double licence : Proposez des logiciels sous licences open source pour des projets open source et des licences commerciales pour des logiciels propriétaires.

Gestion des contributions

Les projets open source publiés reçoivent des contributions externes :

  • Révision des contributions : Les organisations doivent examiner les contributions de la communauté pour la qualité, la sécurité et l’alignement avec l’orientation du projet.
  • Licences de contributeur : Établissez des processus garantissant que les contributeurs accordent les droits nécessaires pour leurs contributions.
  • Ressources de maintenance : Répondre aux problèmes, examiner les pull requests et gérer la communauté nécessitent des ressources dédiées.
  • Conflits de direction : Les désirs communautaires peuvent entrer en conflit avec les priorités organisationnelles, ce qui nécessite une diplomatie pour gérer.

Approche open source fermée : Certaines organisations publient du code publiquement, mais limitent les personnes pouvant apporter des modifications. Les membres de la communauté peuvent suggérer des modifications par le biais de problèmes ou de pull requests, mais seuls les mainteneurs de l'organisation approuvent les modifications. Cela offre une transparence tout en maintenant le contrôle de la qualité et de la direction du code.

Protection de la propriété intellectuelle

Les organisations doivent soigneusement prendre en compte ce qui doit être open source :

  • Avantage concurrentiel : Évitez le code d’approvisionnement ouvert qui offre une différenciation concurrentielle.
  • Problèmes de sécurité : Ne publiez pas de code qui expose des mécanismes de sécurité ou des vulnérabilités.
  • Décisions de minutage : Parfois, il est stratégiquement avantageux de conserver le code propriétaire initialement et open source ultérieurement.
  • Considérations relatives aux brevets : Assurez-vous que les licences open source incluent des octrois de brevets ou des protections appropriés.

Il est essentiel de comprendre ces préoccupations d’entreprise pour implémenter efficacement des logiciels open source. Les unités suivantes explorent en détail les licences open source, ce qui vous aide à comprendre les obligations légales que créent les différentes licences et comment évaluer les implications des licences pour votre organisation.