Résumé

  • 8 minutes

Dans ce module, vous avez découvert comment le développement de logiciels modernes dépend des composants open source et des stratégies apprises pour implémenter des logiciels open source tout en gérant les risques de sécurité, juridiques et opérationnels associés. La compréhension de ces concepts vous permet d’exploiter les avantages open source tout en protégeant votre organisation contre les passifs potentiels.

Création d’un logiciel moderne

Vous avez appris que les applications contemporaines sont assemblées à partir de composants plutôt que entièrement construites à partir de zéro :

  • Composition du composant : Les applications modernes se composent d’environ 80% composants existants gérés en dehors du projet, avec seulement 20% étant du code logique métier d’origine.
  • Open source ou source fermée : Les composants open source fournissent du code source disponible publiquement que tout le monde peut inspecter, modifier et distribuer, tandis que les composants sources fermées distribuent uniquement les fichiers binaires sans accès source.
  • Écosystèmes de package : Les composants sont distribués par le biais de gestionnaires de packages tels que npm, PyPI, NuGet et Maven Central, qui automatisent la gestion des dépendances.
  • Avantages du développement basé sur les composants : La réutilisation des composants éprouvés accélère le développement, améliore la qualité grâce à la vérification communautaire, réduit les coûts en évitant les frais de licence et permet d’accéder à des innovations de pointe.
  • Vitesse de développement : L’utilisation de composants open source réduit considérablement le temps de commercialisation en permettant aux équipes de se concentrer sur une valeur métier unique plutôt que de reconstruire une infrastructure commune.

Préoccupations d’entreprise concernant les logiciels open source

Vous avez examiné les risques importants auxquels les organisations sont confrontées lors de l’adoption de composants open source :

Problèmes de sécurité :

  • Vulnérabilités connues : Des milliers de vulnérabilités de sécurité sont découvertes chaque année dans les composants open source, nécessitant une surveillance continue et une mise à jour corrective rapide.
  • Attaques de chaîne d’approvisionnement : Les attaquants compromissent les comptes de maintenance de package, utilisent le typosquatting ou exploitent la confusion des dépendances pour injecter du code malveillant.
  • Projets non maintenus : De nombreux projets open source n’ont pas de maintenance active, ce qui laisse des vulnérabilités non corrigées lorsque les maintenances abandonnent les projets.

Problèmes de qualité et de fiabilité :

  • Qualité des variables : Les composants open source vont de projets gérés professionnellement à du code de passe-temps mal testé.
  • Changements cassants : les composants ne hiérarchisent pas toujours la compatibilité descendante, nécessitant des modifications de code lors de la mise à jour.
  • Lacunes de documentation : La documentation insuffisante augmente les erreurs d’intégration et l’utilisation incorrecte.

Problèmes juridiques et de licences :

  • Obligations de conformité des licences : Chaque licence open source impose des exigences allant de l’attribution simple au libre-approvisionnement obligatoire des travaux dérivés.
  • Propagation de copyleft : des licences copyleft fortes comme CELLE-ci peuvent nécessiter l’approvisionnement en libre-approvisionnement de toute votre application si elle n’est pas gérée avec soin.
  • Prolifération des licences : Les applications peuvent dépendre de centaines de packages avec des dizaines de licences différentes, ce qui crée des charges de conformité complexes.

Préoccupations opérationnelles :

  • Dépendance de l’infrastructure externe : Les applications s’appuient sur des registres de packages publics qui peuvent rencontrer des pannes ou une suppression de package.
  • Charge de gestion des mises à jour : La mise à jour des dépendances nécessite un effort continu, un test et un déploiement.

Qu’est-ce que le logiciel open source est ?

Vous avez appris les caractéristiques fondamentales du logiciel open source :

  • Définition: Logiciel dont le code source est publiquement disponible pour l’inspection, la modification et la distribution, soumis à une licence open source.
  • Développement collaboratif : Les projets open source impliquent des contributeurs distribués dans le monde entier qui participent volontairement, avec le développement se produisant de manière transparente dans les référentiels publics.
  • Adoption généralisée : Plus de 90% d’entreprises utilisent des logiciels open source en production et des technologies open source alimentent l’infrastructure Internet, les plateformes cloud et les appareils mobiles.
  • Transformation de Microsoft : Microsoft est passé de voir l'open source comme une menace à l'adopter de manière exhaustive, en open-sourçant .NET, en contribuant à Linux et Kubernetes, et en créant des outils open source populaires comme Visual Studio Code et TypeScript.
  • Justification stratégique : Les organisations choisissent open source pour les économies, la flexibilité et le contrôle, la transparence et la sécurité par le biais de l’inspection du code, en évitant le verrouillage du fournisseur, le support communautaire et l’accès anticipé aux innovations.

Notions de base de la licence open source

Vous avez exploré comment les licences open source régissent l’utilisation des logiciels :

Objectif de la licence :

  • Définir des autorisations : Les licences accordent des droits d’utilisation, de modification et de distribution de logiciels que la loi sur le droit d’auteur interdireait autrement.
  • Imposer des obligations : Les licences nécessitent l’attribution, la divulgation de code source, la conservation des licences et parfois la conformité copyleft.
  • Déni de responsabilité : Les auteurs ne sont pas responsables des dommages, et le logiciel est fourni « tel quel » sans aucune garantie.

Critères de définition open source :

  • Redistribution gratuite : Aucune restriction sur la vente ou le don de logiciels.
  • Disponibilité du code source : Doit inclure la source dans un formulaire préféré pour les modifications.
  • Travaux dérivés autorisés : Doit autoriser les modifications et les travaux dérivés.
  • Aucune discrimination : Impossible de discriminer des personnes, des groupes ou des champs d’efforts.
  • Neutre en technologie : Impossible de nécessiter des technologies ou des interfaces spécifiques.

Catégories de licences :

  • Licences permissives : Autorisez l’incorporation de code dans des logiciels propriétaires avec des restrictions minimales (MIT, Apache 2.0, BSD).
  • Licences Copyleft : Exiger que des dérivés utilisent la même licence, ce qui garantit que les logiciels restent open source (PG, AGPL).
  • Licences copyleft faibles : Exiger des modifications open-sourcing sur le composant, mais autoriser l’utilisation propriétaire (LGPL, MPL).

Licences open source courantes

Vous avez examiné les licences populaires et leurs principales caractéristiques :

Licences permissives :

  • Licence MIT: Licence permissive la plus simple nécessitant uniquement une attribution, ce qui optimise l’adoption et l’utilisation commerciale.
  • Licence Apache 2.0 : Licence permissive avec octrois de brevets explicites et arrêt défensif, offrant ainsi une clarté de brevet.
  • Licences BSD : Similaire à MIT, avec 3-Clause BSD ajoutant des restrictions d’utilisation de nom pour la protection des marques.

Licences copyleft fortes :

  • PG v2 et v3 : Exiger que des dérivés fonctionnent sous licencePG et distribuent du code source avec des fichiers binaires ; PG v3 ajoute des améliorations de protection des brevets et de compatibilité internationale.
  • AGPL : Étend la GPL v3 avec une disposition d'utilisation du réseau nécessitant la divulgation du code source pour les offres SaaS.

Licences copyleft faibles :

  • LGPL : Permet de lier des bibliothèques à partir d’applications propriétaires tout en exigeant des modifications apportées à la bibliothèque elle-même pour être open source.
  • MPL 2.0 : Fournit une copie au niveau du fichier, nécessitant une divulgation de source uniquement pour les fichiers sous licence MPL, et non du code propriétaire dans la même application.

Compatibilité des licences :

  • Combinaisons compatibles : MIT + Apache 2.0, MIT + GPL v3, Apache 2.0 + GPL v3, LGPL + GPL.
  • Combinaisons incompatibles : PG v2 + Apache 2.0,PG + Propriétaire, différentes licences copyleft combinées.

Implications des licences et évaluations des risques

Vous avez appris à évaluer les risques de licence et à implémenter la conformité :

Cadre de risque de licence :

  • Faible risque (vert) : Les licences permissives telles que MIT, BSD, Apache 2.0 sont sécurisées pour toute utilisation commerciale.
  • Risque moyen (jaune) : Les licences copyleft faibles comme LGPL, MPL autorisent l’utilisation propriétaire avec des restrictions sur les modifications.
  • Risque élevé (rouge) : Les licences copyleft fortes telles quePG, AGPL sont incompatibles avec la distribution de logiciels propriétaires.
  • Risque inconnu (Orange) : Les licences personnalisées ou peu claires nécessitent une révision légale avant l’utilisation.

Implications logicielles commerciales :

  • Licences permissives : Activez la distribution propriétaire avec uniquement les exigences d’attribution.
  • Faible copyleft : Autoriser l’utilisation de bibliothèques dans des applications propriétaires, mais exiger que les modifications apportées aux bibliothèques soient publiées en open source.
  • Fort copyleft : exiger des travaux dérivés open-sourcing, ce qui les rend incompatibles avec les logiciels propriétaires.

Considérations relatives à la propriété intellectuelle :

  • Protection IP propriétaire : Les licences permissives préservent le code propriétaire ; Les licences copyleft nécessitent une divulgation.
  • Dispositions relatives aux brevets : Apache 2.0 etPG v3 incluent des octrois de brevets explicites ; MIT/BSD manque de clarté de brevet.
  • Perte de secret commercial : La divulgation de code source élimine la protection des secrets commerciaux.

Implémentation de conformité :

  • Inventaire des dépendances : Conservez une facture complète de matériaux qui suit tous les composants et versions open source.
  • Vérification de compatibilité des licences : Utilisez des outils automatisés pour identifier les incompatibilités de licence.
  • Conformité de l’attribution : Générez des fichiers d’agrégation de licences, incluez-les dans les boîtes de dialogue À propos et gérez-les dans la documentation.
  • Provision de code source : Pour les licences copyleft, fournissez du code source complet avec des instructions de génération.

Sécurité de la chaîne d’approvisionnement logicielle :

  • Analyse des vulnérabilités : Analysez en continu les dépendances pour détecter les vulnérabilités connues à l’aide d’outils tels que Snyk, Dependabot ou WhiteSource.
  • Atténuation des attaques de la chaîne d’approvisionnement : Vérifiez les signatures de package, préférez les sources dignes de confiance, utilisez des registres privés et épinglez les versions des dépendances.
  • Évaluation de la qualité : Évaluez l’état de maintenance, la taille de la communauté, la qualité de la documentation et les pratiques de sécurité.

Stratégies organisationnelles :

  • Flux de travail d’approbation : Implémentez l’évaluation préalable à l’utilisation pour la sécurité, les licences et la qualité avant d’adopter de nouvelles dépendances.
  • Listes de packages approuvées : Conservez des listes organisées de composants pré-vérifiés que les développeurs peuvent utiliser immédiatement.
  • Éducation pour les développeurs : Former des développeurs sur les implications de licence, les pratiques de sécurité et les processus de conformité.
  • Surveillance continue : Suivez les mises à jour des dépendances, les modifications de licence et les divulgations de vulnérabilités.

Points clés à prendre

Lorsque vous implémentez des logiciels open source dans votre organisation, n’oubliez pas ces principes essentiels :

Embrassez stratégiquement open source : L’open source offre d’énormes avantages, notamment la vitesse de développement, la qualité, les économies de coûts et l’accès à l’innovation. Au lieu d’éviter l’open source en raison de risques, implémentez des processus de gouvernance qui permettent une adoption sécurisée.

Connaissez vos dépendances : Conservez des inventaires complets de tous les composants open source, y compris les dépendances transitives. Vous ne pouvez pas gérer les risques que vous ne connaissez pas, ce qui rend la visibilité des dépendances fondamentale à une gestion open source efficace.

Comprendre les implications de la licence : Différentes licences ont des implications radicalement différentes pour les logiciels commerciaux. Les licences permissives comme MIT sont sécurisées pour les logiciels propriétaires ; les licences copyleft telles que GPL nécessitent que les travaux dérivés soient ouverts. Faire correspondre la sélection de licence à votre modèle d’entreprise.

Évaluer la compatibilité des licences : Vérifiez que les licences de différents composants peuvent être combinées légalement. Les licences incompatibles peuvent créer des problèmes juridiques qui nécessitent une correction coûteuse, y compris le remplacement des composants ou les réécritures de code.

Implémenter la conformité automatisée : Le suivi manuel des licences ne s’adapte pas aux applications modernes avec des centaines de dépendances. Utilisez des outils automatisés pour l’analyse des dépendances, la détection de licence et la surveillance des vulnérabilités.

Hiérarchiser la sécurité : Les vulnérabilités de sécurité dans les dépendances affectent votre application, quel que soit leur origine. Implémentez l’analyse continue des vulnérabilités et établissez des processus de mise à jour rapides pour les correctifs de sécurité critiques.

Gérer les risques liés à la chaîne logistique : Au-delà des vulnérabilités connues, protégez-vous contre les attaques de chaîne d’approvisionnement par le biais de la vérification des packages, de l’évaluation de la réputation source, des registres privés et de l’épinglage des dépendances.

Équilibrer le contrôle avec la liberté : Les développeurs ont besoin de la liberté d’utiliser des outils et des infrastructures modernes. Au lieu de bloquer l’adoption open source, implémentez des flux de travail d’approbation et des listes de packages approuvées qui permettent une utilisation sécurisée.

Informez votre équipe : La sensibilisation des développeurs aux problèmes de licence et de sécurité est essentielle. Les programmes de formation aident les développeurs à prendre de bonnes décisions sur la sélection des composants et à comprendre les stratégies organisationnelles.

Surveillez en continu : La gestion open source n’est pas une activité ponctuelle. De nouvelles vulnérabilités sont constamment divulguées, les licences changent parfois et les projets peuvent être abandonnés. La surveillance continue garantit la conformité et la sécurité en continu.

En appliquant ces principes et en implémentant des pratiques de gestion open source systématiques, vous pouvez permettre à votre organisation d’exploiter les immenses avantages des logiciels open source tout en gérant efficacement les risques de sécurité, juridiques et opérationnels.

En savoir plus