introduction

Il a été estimé que les logiciels libres et open source (FOSS) constituent 70 à 90 % de n’importe quelle solution logicielle moderne. Les FOSS sont une ressource de plus en plus vitale dans presque toutes les industries, secteurs public et privé, parmi les entreprises technologiques et non technologiques. Par conséquent, assurer la santé et la sécurité des FOSS est essentiel pour l’avenir de presque toutes les industries de l’économie moderne.

En mars 2022, la Linux Foundation, en partenariat avec le Laboratory for Innovation Science de Harvard (LISH), a publié les résultats finaux d’une étude en cours, « Recensement II des logiciels libres et open source – Bibliothèques d’applications.« Cela fait suite à la publication préliminaire, »Vulnerabilities in the Core », rapport préliminaire et recensement II des logiciels open source” en février 2020 et identifie désormais plus d’un millier des bibliothèques d’applications open source les plus largement déployées trouvées à partir d’analyses d’applications commerciales et d’entreprise. Cette étude indique quels projets open source sont couramment utilisés dans les applications et justifient une analyse proactive des opérations et de la prise en charge de la sécurité.

Le rapport final de l’étude Census II identifie les composants logiciels libres et open source (FOSS) les plus couramment utilisés dans les applications de production. Il commence à examiner les communautés open source des composants, qui peuvent éclairer les actions visant à maintenir la sécurité et la santé à long terme des FOSS. Les objectifs annoncés étaient :

Identifiez les composants logiciels libres et open source les plus couramment utilisés dans les applications de production.

Examinez les vulnérabilités potentielles de ces projets en raison de :

Utilisation généralisée de versions obsolètes ; Projets en sous-effectif

Utilisez ces informations pour hiérarchiser les investissements et autres ressources nécessaires pour soutenir la sécurité et la santé des FOSS

Qu’est-ce que la Linux Foundation et Harvard ont appris de l’étude Census II ?

L’étude a été la première à analyser les risques de sécurité des logiciels open source utilisés dans les applications de production. C’est contrairement au précédent Recensement j’étudie qui reposait principalement sur les données de paquets du référentiel public de Debian et sur des facteurs qui identifieraient le profil de chaque paquet comme un risque potentiel pour la sécurité.

Pour mieux comprendre les points communs, la distribution et l’utilisation des logiciels open source au sein des organisations, l’étude a utilisé des données d’analyse de la composition des logiciels (SCA) fournies par Snyk, Synopsiset FOSSE. SCA est le processus d’automatisation de la visibilité sur n’importe quel logiciel, et ces outils sont souvent utilisés pour la gestion des risques, la sécurité et la conformité des licences. Les fournisseurs de solutions SCA analysent régulièrement les bases de code utilisées par les organisations des secteurs privé et public. Les analyses et les audits fournissent un aperçu approfondi de ce que l’open source est utilisé dans les applications de production.

Avec ces données, l’étude a créé une référence et des identifiants uniques pour les packages et composants logiciels courants utilisés par les grandes organisations, qui ont ensuite été liés à un projet spécifique. Cet effort de base a permis à l’étude d’identifier les packages et les composants les plus largement déployés.

Le recensement II comprend huit classements des 500 packages FOSS les plus utilisés parmi ceux rapportés dans les données d’utilisation privée fournies par les partenaires de SCA. L’analyse effectuée est basée sur 500 000 observations d’utilisation des FOSS en 2020.

Celles-ci incluent différentes tranches de données basées sur les versions, la structure et le système de conditionnement. Par exemple, cette recherche permet d’identifier les 10 principaux packages indépendants de la version disponibles sur le gestionnaire de packages npm qui ont été appelés directement dans les applications :

Lodashatteindreaxiosdéboguer@babel/coreExpressSemveruuidréagir-domjquery

D’autres tranches de données examinées dans l’étude incluent les packages versionnés versus indépendants de la version, npm versus non-npm, directs versus indirects (et directs). Les huit listes des 500 meilleurs sont incluses dans un référentiel de données ouvert sur Data.World.

Les observations et l’analyse de ces paramètres spécifiques ont conduit l’étude à tirer certaines conclusions. C’étaient:

Les composants logiciels doivent être nommés dans un schéma standardisé pour que les stratégies de sécurité soient efficaces. L’étude a déterminé qu’un manque de conventions de nommage utilisées par les packages et les composants dans les référentiels était très incohérent. Ainsi, tout effort continu pour créer des stratégies de sécurité et de transparence des logiciels sans la participation de l’industrie aurait un effet limité et ralentirait ces efforts. Les complexités associées à la gestion des versions des packages. En plus de la nécessité d’un schéma de nommage normalisé mentionné ci-dessus, les directives sur la nomenclature des logiciels (SBOM) devront refléter les informations de version cohérentes avec le référentiel public « principal » pour ce package, plutôt que les référentiels privés. De nombreuses versions signalées par nos partenaires de données n’existaient pas dans les référentiels publics de ces packages, car les développeurs maintenaient des forks internes du code.Les comptes de développeur doivent être sécurisés. L’analyse des progiciels les plus utilisés a révélé que beaucoup étaient hébergés sur des comptes de développeur individuels (personnels). Les pratiques de sécurité des développeurs laxistes ont des implications considérables pour les grandes organisations qui utilisent ces progiciels, car ils ont moins de protections et moins de granularité des autorisations associées. L’OpenSSF encourage les jetons MFA ou les comptes d’organisation à atteindre une plus grande sécurité de compte.L’open source hérité est omniprésent dans les solutions commerciales. De nombreuses applications de production sont déployées qui intègrent des packages open source hérités. Cette prévalence de packages hérités est un problème car ils ne sont souvent plus pris en charge ou maintenus par les développeurs ou présentent des vulnérabilités de sécurité connues. Ils manquent souvent de mises à jour pour les problèmes de sécurité connus à la fois dans leur base de code ou dans la base de code des dépendances dont ils ont besoin pour fonctionner. Apache log4jla version 1.x, par exemple, était dix fois plus répandue que log4j 2.x (la version nécessitant une correction récente), et 1.x a toujours connu des vulnérabilités divulguées non corrigées car le logiciel a été déclaré en fin de vie (EOL) en 2015. Les packages hérités présentent une vulnérabilité pour les entreprises qui les déploient dans leurs environnements – cela signifie qu’ils devront savoir quels packages open source ils ont déployés et où maintenir et mettre à jour ces bases de code au fil du temps.La prévalence des « supercodeurs » dans la communauté FOSS. Une grande partie des FOSS les plus utilisés est développée par une poignée de contributeurs seulement – les résultats d’un ensemble de données montrent que 136 développeurs étaient responsables de plus de 80 % des lignes de code ajoutées aux 50 meilleurs packages. De plus, comme indiqué dans les résultats préliminaires du recensement II en 2020, l’atrophie des projets et l’abandon des contributeurs sont un problème connu avec les logiciels open source hérités. Le nombre de contributeurs développeurs qui travaillent sur des projets pour assurer les mises à jour des améliorations de fonctionnalités, de la sécurité et de la stabilité diminue au fil du temps, car ils donnent la priorité à d’autres travaux de développement de logiciels dans leur vie professionnelle ou décident de quitter le projet pour un certain nombre de raisons. Par conséquent, il est beaucoup plus probable que ces communautés soient confrontées à des défis sans suffisamment de développeurs pour agir en tant que mainteneurs au fil du temps.

Quelles ressources existent pour mieux comprendre et atténuer les problèmes potentiels dans le développement de logiciels Open Source ?

La communauté de la Linux Foundation et d’autres initiatives de projets open source offrent des normes, des outils et des conseils importants qui aideront les organisations et l’ensemble de la communauté open source à mieux comprendre et à résoudre directement les problèmes potentiels de leur approvisionnement en logiciels.

chaîne.

Nomenclature logicielle : Adoptez la norme ISO/IEC 5962:2021 SPDX SBOM

Une recommandation concrète de Census II consiste à adopter la nomenclature des logiciels (SBOM) au sein de votre organisation. Les SBOM servent d’enregistrement qui délimite la composition des systèmes logiciels. Échange de données de progiciels (SPDX) est un open standard international pour communiquer des informations SBOM qui prennent en charge l’identification précise des composants logiciels, le mappage explicite des relations entre les composants et l’association des informations de sécurité et de licence avec chaque composant.

De nombreuses entreprises soucieuses de la sécurité logicielle font des SBOM la pierre angulaire de leur stratégie de cybersécurité. La Fondation Linux a récemment publié une étude distincte sur la préparation SBOM au sein des organisations, L’état de la nomenclature logicielle (SBOM) et la préparation à la cybersécurité. Le rapport offre un nouvel aperçu de l’état de préparation de la SBOM par les entreprises du monde entier, en identifiant les tendances des innovateurs, des adopteurs précoces et des procrastinateurs.

Différenciées par région et par chiffre d’affaires, ces organisations ont identifié les niveaux actuels de production et de consommation de SBOM ainsi que les motivations et les défis concernant leur adoption actuelle et future. Ce rapport est destiné aux organisations qui cherchent à mieux comprendre les SBOM en tant qu’outil important pour sécuriser les chaînes d’approvisionnement logicielles et pourquoi il est maintenant temps de les adopter.

Suivez la formation gratuite sur le développement de logiciels sécurisés

L’Open Source Security Foundation (OpenSSF) a développé un trio de cours gratuits sur la façon de développer des logiciels sécurisés. Ces cours font partie du Certificat professionnel Fondamentaux du développement logiciel sécurisé programme. Il y a des frais si vous voulez essayer d’obtenir un certificat (pour prouver que vous avez appris la matière). Cependant, si vous souhaitez simplement apprendre le matériel sans obtenir de certificat, c’est gratuit. auditez simplement le cours. Vous pouvez également commencez gratuitement et mettez à niveau plus tard si vous payez dans le délai de mise à niveau. Les trois cours sont disponibles sur la plateforme edX.

Les cours inclus dans le programme sont :

Développement de logiciels sécurisés : exigences, conception et réutilisation (LFD104x)Développement de logiciels sécurisés : mise en œuvre (LFD105x)Développement de logiciels sécurisés : vérification et sujets plus spécialisés (LFD106x)

Concentrez-vous sur l’intégration des meilleures pratiques de sécurité dans vos projets open source

L’OpenSSF développe et héberge ses Les meilleures pratiques programme de badges pour les développeurs de logiciels open source. Cette initiative a été l’un des premiers résultats produits à la suite de la Recensement Iachevé en 2015. Depuis, plus de 4 000 projets de logiciels open source ont engagé, commencé ou terminé l’obtention d’un badge des meilleures pratiques.

Les projets conformes aux meilleures pratiques OpenSSF peuvent afficher un badge sur leur page GitHub ou leurs propres pages Web et autres supports. En revanche, les utilisateurs du badge peuvent rapidement évaluer quels projets FLOSS suivent les meilleures pratiques et, par conséquent, sont plus susceptibles de produire des logiciels sécurisés et de meilleure qualité. De plus, un API de badge existe qui permet aux développeurs et aux organisations d’interroger le score d’entraînement d’un projet spécifique, tel que Silver, Gold et Passing. Cela signifie que toute organisation peut effectuer une vérification de l’API dans son flux de travail pour vérifier les packages open source qu’elle utilise et voir si la communauté de ce projet a obtenu un badge.

Plus d’informations sur le programme OpenSSF Best Practices Badging, y compris le contexte et Critèresest disponible sur GitHub. le page des projets affiche les projets participants et prend en charge les requêtes (telles qu’une liste de projets qui ont un badge de passage). Des statistiques de projet et des statistiques de critères sont disponibles.

Comprendre les vecteurs de vulnérabilité de votre chaîne logistique logicielle

En plus d’examiner les résultats du recensement II, nous vous encourageons à lire le document de la Linux Foundation Livre blanc sur la sécurité de la chaîne d’approvisionnement open source. Cette publication explore les vulnérabilités de l’écosystème des logiciels open source à travers des exemples historiques de faiblesses dans les composants d’infrastructure connus (comme les pratiques de sécurité des développeurs et le comportement des utilisateurs finaux laxistes, les référentiels de packages de dépendance mal sécurisés, les gestionnaires de packages et les bases de données de vulnérabilités incomplètes). Il fournit un ensemble de recommandations aux organisations pour naviguer dans les zones à problèmes potentiels.

Conclusion

L’étude Census II montre que même les progiciels open source les plus largement déployés peuvent avoir des problèmes avec les pratiques de sécurité, l’engagement des développeurs, l’exode des contributeurs et l’abandon du code. Par conséquent, les projets open source nécessitent des outils de support, une infrastructure, du personnel et une gouvernance appropriée pour agir comme un projet en amont stable et sain pour votre organisation.

La poste Un résumé de Census II : les bibliothèques d’applications logicielles open source dont le monde dépend est apparu en premier sur Fondation Linux.