Classement des bibliothèques nécessitant une vérification de sécurité particulière

Le fonds créé par l'organisation Linux Foundation Core Infrastructure Initiative, dans le cadre duquel des entreprises leaders ont uni leurs efforts pour soutenir des projets open source dans des domaines clés de l'industrie informatique, a mené la deuxième étude dans le cadre du programme Census, visant à identifier les projets open source nécessitant un audit de sécurité prioritaire.

La deuxième étude se concentre sur l'analyse du code source partagé, utilisé de manière implicite dans divers projets d'entreprise sous forme de dépendances téléchargées depuis des dépôts externes. Les vulnérabilités et la compromission des développeurs de composants tiers utilisés dans le fonctionnement des applications (supply chain) peuvent annuler tous les efforts pour améliorer la sécurité du produit principal. L'étude a permis de déterminer les 10 paquets les plus utilisés en JavaScript et Java, dont la sécurité et le maintien nécessitent une attention particulière.

Bibliothèques JavaScript du dépôt npm :

• async (196 000 lignes de code, 11 auteurs, 7 contributeurs, 11 problèmes non résolus);
• inherits (3 800 lignes de code, 3 auteurs, 1 contributeur, 3 problèmes non résolus);
• isarray (317 lignes de code, 3 auteurs, 3 contributeurs, 4 problèmes non résolus);
• kind-of (2 000 lignes de code, 11 auteurs, 11 contributeurs, 3 problèmes non résolus);
• lodash (42 000 lignes de code, 28 auteurs, 2 contributeurs, 30 problèmes non résolus);
• minimist (1 200 lignes de code, 14 auteurs, 6 contributeurs, 38 problèmes non résolus);
• natives (3 000 lignes de code, 2 auteurs, 1 contributeur, aucun problème non résolu);
• qs (5 400 lignes de code, 5 auteurs, 2 contributeurs, 41 problèmes non résolus);
• readable-stream (28 000 lignes de code, 10 auteurs, 3 contributeurs, 21 problèmes non résolus);
• string_decoder (4 200 lignes de code, 4 auteurs, 3 contributeurs, 2 problèmes non résolus).

Bibliothèques Java des dépôts Maven :

• jackson-core (74 000 lignes de code, 7 auteurs, 6 contributeurs, 40 problèmes non résolus);
• jackson-databind (74 000 lignes de code, 23 auteurs, 2 contributeurs, 363 problèmes non résolus);
• guava.git, bibliothèques Google pour Java (1 million de lignes de code, 83 auteurs, 3 contributeurs, 620 problèmes non résolus);
• commons-codec (51 000 lignes de code, 3 auteurs, 3 contributeurs, 29 problèmes non résolus);
• commons-io (73 000 lignes de code, 10 auteurs, 6 contributeurs, 148 problèmes non résolus);
• httpcomponents-client (121 000 lignes de code, 16 auteurs, 8 contributeurs, 47 problèmes non résolus);
• httpcomponents-core (131 000 lignes de code, 15 auteurs, 4 contributeurs, 7 problèmes non résolus);
• logback (154 000 lignes de code, 1 auteur, 2 contributeurs, 799 problèmes non résolus);
• commons-lang (168 000 lignes de code, 28 auteurs, 17 contributeurs, 163 problèmes non résolus);
• slf4j (38 000 lignes de code, 4 auteurs, 4 contributeurs, 189 problèmes non résolus);

Le rapport examine également les questions de normalisation du schéma de nomination des composants externes, de protection des comptes des développeurs et de maintien des versions obsolètes après la création de nouvelles versions significatives. De plus, la Linux Foundation a publié un document avec des recommandations pratiques pour organiser un processus de développement sécurisé des projets open source.

Le document aborde la répartition des rôles dans le projet, la création d'équipes responsables de la sécurité, la définition des politiques de sécurité, le suivi des autorisations des participants au projet, l'utilisation correcte de Git lors de la correction des vulnérabilités pour éviter les fuites avant la publication des correctifs, la définition des processus de réponse aux signalements de problèmes de sécurité, la mise en œuvre de systèmes de test de sécurité, l'application de procédures de révision du code, et la prise en compte des critères liés à la sécurité lors de la formation des versions.

Source : opennet.ru