Certaines personnes naïves peuvent encore penser qu’elles n’utilisent pas de logiciel open source. Ils ont tort. Tout le monde le fait. Selon le Centre de recherche en cybersécurité de Synopsys (CyRC) Rapport 2021 « Open Source Security and Risk Analysis » (OSSRA), 95% de tous les programmes commerciaux contiennent des logiciels open source. D’après le décompte de CyRC, la grande majorité de ce code contient du code obsolète ou non sécurisé. Mais comment pouvez-vous savoir quelles bibliothèques et autres composants sont sûrs sans faire une analyse approfondie du code ? Google et le Fondation de sécurité open source (OSSF) avoir une réponse simple et rapide : le Cartes de pointage de sécurité OpenSSF.
Ces tableaux de bord sont basés sur un ensemble de vérifications de réussite/échec automatisées pour fournir un examen rapide de nombreux projets de logiciels open source. le Projet de tableaux de bord est un outil de sécurité automatisé qui produit un « score de risque » pour les programmes open source.
C’est important car seules certaines organisations ont mis en place des systèmes et des processus pour vérifier les nouvelles dépendances open source pour les problèmes de sécurité. Même chez Google, cependant, avec toutes ses ressources, ce processus est souvent fastidieux, manuel et sujet aux erreurs. Pire encore, bon nombre de ces projets et développeurs sont limités en ressources. Le résultat? La sécurité finit souvent par être une priorité faible sur la liste des tâches. Cela conduit à des projets critiques qui ne suivent pas les bonnes pratiques de sécurité et deviennent vulnérables aux exploits.
Le projet Scorecards espère faciliter les contrôles de sécurité pour rendre la sécurité plus facile à réaliser avec la sortie de Cartes de pointage v2. Cela comprend de nouveaux contrôles de sécurité, une augmentation du nombre de projets notés et des données facilement accessibles pour l’analyse.
Pour les développeurs, les Scorecards aident à réduire le labeur et l’effort manuel requis pour évaluer en permanence les changements de packages lors de la maintenance de la chaîne d’approvisionnement d’un projet. Les consommateurs peuvent accéder automatiquement aux risques pour prendre des décisions éclairées sur l’acceptation du programme, rechercher une solution alternative ou travailler avec les responsables pour apporter des améliorations.
Voici les nouveautés :
Identification des risques : Depuis l’automne dernier, la couverture de Scorecards s’est élargie; le projet a ajouté plusieurs nouvelles vérifications, suite à celle de Google Connaître, prévenir, réparer le cadre.
Repérer les contributeurs malveillants : Les contributeurs avec des intentions malveillantes ou des comptes compromis peuvent introduire des portes dérobées potentielles dans le code. Les revues de code aident à atténuer de telles attaques. Avec le nouveau Branche-Protection check, les développeurs peuvent vérifier que le projet applique la revue de code obligatoire d’un autre développeur avant que le code ne soit validé. Actuellement, cette vérification ne peut être exécutée que par un administrateur de référentiel en raison des limitations de l’API GitHub. Pour un référentiel tiers, utilisez le moins informatif Révision de code vérifier à la place.
Code vulnérable : Même avec les meilleurs efforts des développeurs et des pairs, un mauvais code peut toujours entrer dans une base de code et rester non détecté. C’est pourquoi il est important de permettre une brouiller et des tests de code statique pour détecter les bogues tôt dans le cycle de développement. Le projet vérifie maintenant si un projet utilise le fuzzing et SAST outils dans le cadre de sa intégration continue/déploiement continu (CI/CD) pipeline.
Compromis du système de construction : Une solution CI/CD courante utilisée par les projets GitHub est Actions GitHub. Un danger avec ces workflows d’action est qu’ils peuvent gérer des entrées utilisateur non fiables. Cela signifie qu’un attaquant peut créer une demande d’extraction malveillante pour accéder au jeton GitHub privilégié, et avec lui la possibilité de pousser le code malveillant vers le dépôt sans avis. Pour atténuer ce risque, Scorecard Jeton-Autorisations Le contrôle de prévention vérifie désormais que les workflows GitHub suivent le principe du moindre privilège en rendant les jetons GitHub en lecture seule par défaut.
Mauvaises dépendances : Un programme n’est aussi sûr que sa plus faible dépendance. Cela peut sembler évident, mais la première étape pour connaître nos dépendances est simplement de les déclarer… et de faire déclarer vos dépendances également. Armé de ces informations de provenance, vous pouvez évaluer les risques pour vos programmes et atténuer ces risques.
C’est la bonne nouvelle. La mauvaise nouvelle est qu’il existe plusieurs anti-modèles largement utilisés qui enfreignent ce principe de provenance. Le premier de ces anti-modèles sont les binaires archivés – car il n’y a aucun moyen de vérifier ou de vérifier facilement le contenu du binaire dans le projet. Grâce notamment à l’utilisation continue de pilotes propriétaires, cela peut être un mal inévitable. Pourtant, Scorecards fournit un Binary-Artefacts vérifier pour tester cela.
Un autre anti-modèle est l’utilisation de curl ou de bash dans les scripts, qui extrait dynamiquement les dépendances. Les hachages cryptographiques nous permettent d’épingler nos dépendances à une valeur connue. Si cette valeur change, le système de génération la détecte et refuse la génération. L’épinglage des dépendances est utile partout où nous avons des dépendances : pas seulement pendant la compilation, mais aussi dans les fichiers Docker, les workflows CI/CD, etc. Frozen-Deps Chèque. Cette vérification est utile pour atténuer les attaques de dépendance malveillantes telles que la récente CodeCov attaque.
Même avec l’épinglage par hachage, les hachages doivent être mis à jour de temps en temps lorsque les dépendances corrigent les vulnérabilités. Des outils comme robot dépendant ou alors rénover le robot peut examiner et mettre à jour les hachages. Les tableaux de bord Mise à jour automatisée des dépendances check vérifie que les développeurs s’appuient sur de tels outils pour mettre à jour leurs dépendances.
Il est important de connaître les vulnérabilités d’un projet avant de l’utiliser comme dépendance. Les tableaux de bord peuvent fournir ces informations via le nouveau Vulnérabilités check, sans souscrire à un système d’alerte de vulnérabilité.
C’est quoi de neuf. Voici ce que le projet Scorecards a fait jusqu’à présent.
Il a maintenant évalué sécurité pour plus de 50 000 projets open source. Pour faire évoluer ce projet, son architecture a été massivement repensée. Il utilise désormais un Pub/Sub maquette. Cela lui confère une évolutivité horizontale améliorée et un débit plus élevé. Cet outil entièrement automatisé évalue périodiquement les projets open source critiques et expose les informations de vérification des Scorecards grâce à des mises à jour hebdomadaires. ensemble de données BigQuery public
Pour accéder à ces données, vous pouvez utiliser le outil de ligne de commande bq. L’exemple suivant montre comment exporter des données pour le projet Kubernetes. Pour vos besoins, remplacez l’URL du référentiel Kubernetes par celle du programme que vous devez vérifier :
$ bq query –nouse_legacy_sql ‘SELECT Repo, Date, Checks FROM openssf.scorecardcron.scorecard_latest WHERE Repo= »github.com/kubernetes/kubernetes« ‘
Vous pouvez également voir le dernières données sur tous les projets analysés par Scorecards. Ces données sont également disponibles dans le nouveau Informations sur les sources ouvertes de Google projet et le Projet OpenSSF Security Metrics. Les données brutes peuvent également être examinées via des outils d’analyse et de visualisation de données tels que Studio de données Google. Avec les données au format CSV, vous pouvez les examiner avec votre outil d’analyse et de visualisation de données préféré.
Une chose est claire de toutes ces données. Il y a encore beaucoup de failles de sécurité à combler, même dans les packages largement utilisés comme Kubernetes. Par exemple, de nombreux projets ne sont pas continuellement flou, ne définissez pas de stratégie de sécurité pour signaler les vulnérabilités et n’épinglez pas les dépendances. Selon Google, et franchement, tous ceux qui se soucient de la sécurité : « Nous devons tous nous rassembler en tant qu’industrie pour faire prendre conscience de ces risques de sécurité généralisés et apporter des améliorations qui profiteront à tous. »
Aussi utiles que soient les Scorecards v2, il reste encore beaucoup de travail à faire. Le projet compte désormais 23 développeurs, d’autres seraient les bienvenus. Si vous souhaitez vous amuser, consultez ces bons problèmes de première minuterie. Ceux-ci sont tous accessibles via GitHub.
Si vous souhaitez que nous vous aidions à exécuter des Scorecards sur des projets spécifiques, veuillez soumettre une pull request GitHub pour les ajouter. Enfin et surtout, les développeurs de Google ont déclaré : « Nous avons beaucoup d’idées et beaucoup plus de contrôles que nous aimerions ajouter, mais nous voulons vous entendre. Dites-nous quels chèques vous aimeriez voir dans la prochaine version de Scorecards. »
À l’avenir, l’équipe prévoit d’ajouter :
Si j’étais vous, je commencerais à utiliser les Scorecards immédiatement. Ce projet peut déjà rendre votre travail beaucoup plus sûr et il promet de faire encore plus pour améliorer non seulement la sécurité de vos programmes, mais aussi les programmes qu’il couvre.
