Laisse le Newsletter OSS Entreprise guidez votre parcours open source ! Inscrivez-vous ici.

Google et ses co-membres de l’Open Source Security Foundation (OpenSSF) ont annoncé une mise à jour majeure de sa sécurité open source Projet de tableaux de bord.

L’OpenSSF, un projet de la Linux Foundation lancé en août dernier et dirigé par des organisations telles que Microsoft, GitHub, IBM, Red Hat et Google, a d’abord annoncé Scorecards de retour en novembre. Son objectif principal est de créer automatiquement une cote de sécurité pour les projets open source, ce qui aide à son tour les utilisateurs potentiels (c’est-à-dire les développeurs de grandes entreprises soucieuses de la sécurité) à prendre une décision plus éclairée sur la manière de procéder avec un composant open source spécifique dans leur propre logiciel. projets. Pour l’instant, cela ne fonctionne qu’avec les référentiels GitHub, bien que le plan soit de l’étendre à d’autres à l’avenir.

Vulnérabilités

Pour le contexte, l’adoption des logiciels open source a accéléré dans l’entreprise et ailleurs, cependant les vulnérabilités restent une menace permanente – une estimation 84 % des bases de code contiennent au moins une vulnérabilité open source. De plus, les attaques de la chaîne d’approvisionnement ont fait la une des journaux ces six derniers mois après une série d’attaques très médiatisées. tels que SolarWinds, qui met en évidence pourquoi il est important pour les entreprises d’évaluer correctement les packages externes (open source) qu’elles introduisent dans leurs applications.

Avec des cartes de pointage version 2.0.0, qui s’est discrètement déployé il y a deux jours, l’OpenSSF a ajouté un tas de nouveaux contrôles de sécurité au mélange des Scorecards. Cela comprend un nouveau vérification de la protection de la branche, que les développeurs peuvent utiliser pour vérifier que le projet open source qu’ils souhaitent utiliser dispose d’un processus de révision de code obligatoire mis en place par un autre développeur. De plus, les Scorecards incluent désormais des contrôles pour voir si un projet utilise brouiller et SAST outils dans leur CI/CD processus, qui devrait contribuer dans une certaine mesure à empêcher les vulnérabilités d’entrer dans une base de code.

Ailleurs, un nouveau jeton-autorisations Le contrôle de prévention vérifiera désormais que les flux de travail d’un projet « suivent le principe du moindre privilège » en rendant les jetons GitHub en lecture seule par défaut, ce qui, selon Google, aidera à empêcher les demandes d’extraction malveillantes qui tentent d’accéder à un jeton GitHub privilégié. Et un nouveau vérification des vulnérabilités aide également à mettre en évidence les vulnérabilités des projets open source avant que ils deviennent une dépendance dans un autre projet – cela évite d’avoir à s’abonner à un système d’alerte de vulnérabilité distinct.

Il convient de noter que les Scorecards ne sont pas nécessairement conçus pour éloigner les entreprises de projets open source spécifiques. Si un composant particulier génère une note faible, une entreprise peut décider d’effectuer ses propres tests dessus pour voir à quel point il est vraiment robuste, ou elle peut décider de travailler avec les créateurs du projet pour l’améliorer. Après tout, de nombreux mainteneurs de projets open source ont des ressources insuffisantes pour se consacrer au travail à temps plein, donc un peu de soutien supplémentaire pourrait aller loin.