Là&# 8217;s code open source dans presque tous les projets de développement de logiciels auxquels vous pouvez penser. Les développeurs adorent. Mais vous devez comprendre les risques cachés et comment les minimiser, ou vous pouvez laisser votre application ouverte à des vulnérabilités de sécurité inconnues.
Codage avant l'open source
Il était une fois les développeurs de logiciels qui ont tout écrit à partir de zéro. Ensuite, des bibliothèques de code, des boîtes à outils et d'autres modules complémentaires ont commencé à apparaître. Vous pouvez obtenir une longueur d'avance en utilisant une boîte à outils pour fournir certaines fonctionnalités, telles qu'un module de rapport ou un widget d'interface. Vous pouvez les intégrer à votre projet en tant que composants entièrement formés prêts à l'emploi et les utiliser immédiatement. L'alternative était de perdre du temps, de l'argent et des efforts de développement à réinventer la roue.
Bien sûr, au fil du temps, vous construisiez votre propre bibliothèque de routines et de modules qui avaient été écrits en interne. Ainsi, lorsque vous développiez une nouvelle routine de code ou un élément d'interface, vous aviez trois options. Écrivez-le vous-même, réutilisez du code interne déjà écrit ou achetez dans une bibliothèque ou une boîte à outils.
L'essor de l'Open Source
L'avènement du code open source a changé tout cela. Un logiciel open source rend le code source d'un projet librement disponible pour une utilisation par d'autres, dans les limites d'une licence généralement bénigne. La croissance et l'adoption de l'open source ont toutes deux été stupéfiantes. Le mot prolifération ne semble pas le couvrir. Il y a eu une augmentation phénoménale des logiciels open source, et pas seulement en termes de nombre ahurissant de projets et de produits open source qui existent, mais aussi en termes d'utilisation de l'open source dans les produits commerciaux.
< p>Les logiciels open source ont atteint une masse critique il y a quelques années, et ils sont passés d'une position de niche en marge à une ressource de développement grand public pleinement adoptée. Parce qu'il a été conduit et développé par une communauté et non par une entreprise commerciale traditionnelle, il était également considéré comme un amateur.
Publicité
Maintenant, on a l'impression que l'open source a grandi et mûri. Et c'est le cas. Mais le plus grand changement a été une appréciation plus large de l'open source, une compréhension des avantages qu'il apporte et la reconnaissance du fait que l'inclusion de l'open source dans votre produit n'a pas de quoi avoir honte.
Les estimations suggèrent que les projets logiciels non triviaux écrivent au plus environ 20 pour cent du code original. Les 80 % restants sont open source. Le principal site d'hébergement de référentiels open source, GitHub, a atteint plus de 100 millions de référentiels en 2018. Et il existe de nombreuses autres plates-formes Git hébergées, telles que GitLab et BitBucket.
L'open source est un phénomène de développement de logiciels. Mais ce ne sont pas que des roses dans le jardin de développement. Il y a des problèmes que vous devez connaître et gérer.
Les problèmes de sécurité
L'utilisation de composants open source dans les grands projets logiciels réduit les coûts de développement, raccourcit le temps de développement de bout en bout, et—il a été avancé—promouvoir l'innovation. Parce qu'il libère votre personnel de développement de la banalité, il leur permet de se concentrer sur les aspects uniques et attractifs de votre produit sur le marché.
Certains produits open source ont une entité commerciale derrière eux. L'organisation commercialise son produit dans le cadre d'un système de double licence. Une version commerciale aura un canal d'assistance officiel et professionnel et peut contenir d'autres avantages, tels que des extras propriétaires fournis avec le produit. Ils publient également une version soutenue par la communauté qui bénéficiera des efforts de codage de l'équipe commerciale ainsi que des contributions de sa propre communauté. Les contributions importantes de la communauté seront également réintégrées dans la version commerciale.
Cependant, la majorité des projets open source sont entièrement pilotés par la communauté. Ils peuvent avoir le soutien d'entités commerciales, mais ce soutien est constitué de dons et de parrainage, et non de contributions de code.
Publicité
Quelle que soit leur provenance, les composants open source qui sont choisis pour être inclus dans les nouveaux projets de développement ont tendance à être des projets bien établis et réputés à part entière. Ils ont gagné une grande confiance. Mais ce n'est pas toujours le cas. Parfois, la fonctionnalité dont vous avez besoin est disponible, mais elle est contenue dans un projet nouveau et quelque peu non prouvé. Mais vous avez le code source, n'est-ce pas ? Vous pouvez en faire une revue de code.
Du point de vue de la sécurité, l'open source n'est ni plus ni moins sécurisé qu'un code propriétaire maison. Après tout, ce n'est que du code écrit par l'homme. Les partisans de l'open source se réfèrent à la loi d'Eric S. Raymond qu'il a nommée en l'honneur de Linus Torvalds, qui stipule que « avec suffisamment de globes oculaires, tous les bogues sont superficiels ». Avec suffisamment de personnes examinant le code et le testant en version bêta, les problèmes devraient être identifiés, caractérisés et résolus rapidement.
C'est vrai dans la mesure où il va. Mais les problèmes de sécurité ne sont pas nécessairement des bogues. Une vulnérabilité peut être une circonstance qui survient comme effet secondaire d'une logique complexe dans un projet de nombreux modules de code source représentant des millions de lignes de code. Le produit fait ce qu'il est censé faire, et il semble donc qu'il fonctionne comme prévu. Et ainsi, il réussit l'examen du code, la vérification du produit, les tests sur le terrain et obtient un bilan de santé irréprochable.
En dehors de la chance aveugle et du hasard, cette boucle d'examen, de test, d'essai et de publication ne fonctionnera pas découvrir des vulnérabilités de sécurité.
Pourquoi l'open source est attrayant pour les pirates
De plus, certains aspects de l'open source sont positivement attrayants pour les pirates et les acteurs de la menace. Ils peuvent également voir le code source. Ils peuvent rechercher des vulnérabilités avec un état d'esprit différent de celui du contributeur communautaire moyen qui, bien qu'il soit un développeur compétent, a peu de chances d'avoir une réelle expérience en matière de sécurité.
Bien sûr, les contributeurs à l'open source viennent dans toutes les saveurs avec des origines variées. Certains d'entre eux auront sans aucun doute une expérience de la sécurité dans le monde réel, mais ils seront la minorité. Les acteurs menaçants sont une tout autre bête. Et ils ne se limitent pas à trouver des vulnérabilités, ils peuvent aussi les injecter.
Publicité
Il y a eu de nombreux cas où un acteur malveillant a introduit une vulnérabilité via un correctif qu'il a créé et soumis à un projet. Il a fait son chemin dans la revue de code, dans la base de code et dans la prochaine version du produit.
L'exemple ultime en est peut-être un composant JavaScript appelé event-stream. Ce projet open source a été maintenu par un seul développeur. Le fardeau de la gérance du projet l'a dépassé. Il a été persuadé de le remettre à un nouveau mainteneur.
Le nouveau mainteneur était un acteur menaçant. Ils ont repris le projet, l'ont exécuté normalement pendant une courte période, puis y ont ajouté du code malveillant. Chaque copie de chaque autre programme qui utilisait ce composant logiciel détournait discrètement certains types de portefeuille Bitcoin pour l'acteur de la menace.
Ce que vous pouvez faire pour réduire le risque
Comme pour de nombreux aspects de la sécurité, vous gérez ce risque en appliquant des contrôles. Cela nécessite une gouvernance, c'est-à-dire des politiques et des procédures. Heureusement, il existe des logiciels qui peuvent vous aider.
Créez un registre Open Source
Vous devez quantifier l'open source que vous utilisez. Créez un registre qui répertorie les composants open source que vous utilisez dans vos projets. Répertoriez chaque composant open source, la ou les versions que vous avez utilisées, les projets dans lesquels vous les avez utilisés, quelle est la dernière version et où elle peut être téléchargée. Dans la documentation de conception de chacun de vos projets, vous devez lister les composants open source qui sont utilisés.
Le diable est dans les détails. N'oubliez pas les dépendances et la nature hiérarchique d'une grande partie de l'open source. Les projets open source utilisent souvent d'autres projets en eux-mêmes, imbriqués comme des poupées russes, ou nécessitent l'installation d'autres composants open source sur la machine cible afin qu'ils puissent les utiliser.
Publicité
Découvrez ces dépendances et répertoriez-les dans votre registre open source.
Exécuter des audits automatiques
Les vulnérabilités dans les packages open source sont un problème majeur pour NPM, le gestionnaire de packages pour JavaScript. Pour résoudre ce problème, ils ont créé un outil d'audit automatique qui recherchera les packages obsolètes avec des mises à jour de sécurité.
Ceci, bien sûr, a ses limites, et il est important d'être conscient et de ne pas se fier entièrement à l'outillage automatique. Il ne détectera que les packages présentant des vulnérabilités et des mises à jour connues. Si le package présente une vulnérabilité, mais n'a pas été mis à jour pour la corriger, l'audit NPM ne vous dira rien.
CONNEXES : Audit vos dépendances NPM, Ils représentent 86 % des bogues de sécurité
Créez une carte des vulnérabilités
Votre registre open source vous donne une image claire de l'open source que vous utilisez. L'étape suivante consiste à mapper les vulnérabilités connues sur ce registre. Parfois, ceux-ci peuvent être découverts en visitant la page d'accueil du projet et en consultant la liste des problèmes connus.
La base de données nationale sur les vulnérabilités (NVD) vous donnera une image beaucoup plus granulaire. Vous pouvez utiliser leur page de recherche pour rechercher des produits par nom afin de découvrir quelles vulnérabilités et expositions courantes affectent ce composant logiciel. Le NVD est une excellente ressource, même si son format prend un peu de temps jusqu'à ce que vous vous y habituiez.
Mettre à jour votre registre et votre carte des vulnérabilités
Bien sûr, c'est quelque chose que vous devez garder à l'esprit. De nouvelles vulnérabilités sont découvertes tout le temps, de sorte que l'état de sécurité de votre produit au lancement est susceptible de s'éroder lentement au fil du temps.
Publicité
Reconnaissant ce nouveau besoin, il existe des commerciaux (Black Duck, WhiteSource) applications qui vous aideront à cela. Ils peuvent analyser vos projets, identifier le code open source et rechercher automatiquement les vulnérabilités. Certains d'entre eux (FOSSA) offrent un niveau gratuit.
L'analyse statique de votre base de code, y compris les composants open source, devrait de toute façon faire partie intégrante de votre rigueur de développement. Des outils tels que Coverity Scan peuvent détecter des défauts dans votre code, tels que des débordements de mémoire tampon, qui peuvent entraîner des vulnérabilités. Il vous conseillera même sur la façon dont ils peuvent être rectifiés.
Vérifiez les licences Open Source et respectez-les
Assurez-vous de comprendre les licences en vigueur sur l'open source que vous utilisez . Il existe de nombreuses licences différentes, alors vérifiez que vous vous conformez à toutes les exigences. Impliquez votre responsable des licences ou de la conformité, si vous en avez un.
Le non-respect d'une licence open source peut entraîner des litiges. Les projets open source répondent aussi rapidement aux violations de licence que les éditeurs de logiciels commerciaux.
Mettre à jour vos composants open source
Comme les vulnérabilités sont corrigées par les communautés de l'open source, vous utilisez, assurez-vous de mettre à niveau vos versions afin de bénéficier de ces correctifs. L'open source utilise un “pull” maquette. Ils annoncent un nouveau correctif et vous devez ensuite télécharger cette nouvelle version. C'est le contraire de beaucoup de logiciels commerciaux qui ont un “push” modèle où les mises à jour sont transmises aux utilisateurs enregistrés.
Publicité
Surveillez les pages du projet pour les annonces de nouvelles versions, et téléchargez et testez les nouvelles versions.
Le coût de l'Open Source
Les logiciels Open Source sont gratuits, mais ils s'accompagnent d'une surcharge de gestion et de gouvernance. Les implications doivent être comprises et contrôlées afin de l'utiliser en toute sécurité et avec un minimum de risques.