Évaluation des bibliothèques nécessitant des contrôles de sécurité particuliers

Fondation formée par la Linux Foundation Initiative d'infrastructure de base, dans lequel de grandes entreprises ont uni leurs forces pour soutenir des projets open source dans des domaines clés de l'industrie informatique, passé deuxième étude dans le cadre du programme Recensement, visant à identifier les projets open source nécessitant des audits de sécurité prioritaires.

La deuxième étude se concentre sur l'analyse du code open source partagé implicitement utilisé dans divers projets d'entreprise sous la forme de dépendances téléchargées depuis des référentiels externes. Les vulnérabilités et les compromissions des développeurs de composants tiers impliqués dans le fonctionnement des applications (chaîne d'approvisionnement) peuvent annuler tous les efforts visant à améliorer la protection du produit principal. À la suite de l'étude, il a été certainement Les 10 packages les plus utilisés en JavaScript et Java, dont la sécurité et la maintenabilité nécessitent une attention particulière.

Bibliothèques JavaScript du référentiel npm :

• async (196 mille lignes de code, 11 auteurs, 7 committers, 11 problèmes ouverts) ;
• hérite (3.8 mille lignes de code, 3 auteurs, 1 committer, 3 problèmes non résolus) ;
• isarray (317 lignes de code, 3 auteurs, 3 committers, 4 problèmes ouverts) ;
• en quelque sorte (2 mille lignes de code, 11 auteurs, 11 committers, 3 problèmes non résolus) ;
• Lodash (42 mille lignes de code, 28 auteurs, 2 committers, 30 problèmes ouverts) ;
• minimiste (1.2 mille lignes de code, 14 auteurs, 6 committers, 38 problèmes ouverts) ;
• vierge (3 mille lignes de code, 2 auteurs, 1 committer, aucun problème ouvert) ;
• qs (5.4 mille lignes de code, 5 auteurs, 2 committers, 41 problèmes ouverts) ;
• flux lisible (28 mille lignes de code, 10 auteurs, 3 committers, 21 problèmes ouverts) ;
• string_decoder (4.2 mille lignes de code, 4 auteurs, 3 committers, 2 problèmes ouverts).

Bibliothèques Java des référentiels Maven :

• jackson-core (74 mille lignes de code, 7 auteurs, 6 committers, 40 problèmes ouverts) ;
• liaison de données jackson (74 mille lignes de code, 23 auteurs, 2 committers, 363 problèmes ouverts) ;
• goyave.git, bibliothèques Google pour Java (1 million de lignes de code, 83 auteurs, 3 committers, 620 problèmes ouverts) ;
• codec-communs (51 mille lignes de code, 3 auteurs, 3 committers, 29 problèmes ouverts) ;
• communs-io (73 mille lignes de code, 10 auteurs, 6 committers, 148 problèmes ouverts) ;
• httpcomponents-client (121 mille lignes de code, 16 auteurs, 8 committers, 47 problèmes ouverts) ;
• httpcomponents-core (131 mille lignes de code, 15 auteurs, 4 committers, 7 problèmes ouverts) ;
• se connecter (154 mille lignes de code, 1 auteur, 2 committers, 799 problèmes ouverts) ;
• communes-lang (168 mille lignes de code, 28 auteurs, 17 committers, 163 problèmes ouverts) ;
• slf4j (38 mille lignes de code, 4 auteurs, 4 committers, 189 problèmes ouverts) ;

Le rapport aborde également les questions de normalisation du schéma de dénomination des composants externes, de protection des comptes de développeurs et de maintenance des versions existantes après la création de nouvelles versions majeures. Également publié par la Linux Foundation document avec des recommandations pratiques pour organiser un processus de développement sécurisé pour les projets open source.

Le document aborde les problèmes de répartition des rôles dans le projet, de création d'équipes responsables de la sécurité, de définition des politiques de sécurité, de surveillance des pouvoirs dont disposent les participants au projet, d'utilisation correcte de Git lors de la correction des vulnérabilités pour éviter les fuites avant de publier le correctif, de définition des processus de réponse aux rapports. des problèmes de sécurité, mise en œuvre de systèmes de tests de sécurité, application de procédures de révision du code, prise en compte des critères liés à la sécurité lors de la création des versions.

Source: opennet.ru