Communauté
1,7-
Activité
Le score d'activité mesure la date de la dernière mise à jour d'un projet, en se basant sur le nombre de jours depuis le dernier commit sur sa branche par défaut. Des commits réguliers indiquent un projet activement maintenu, réactif face aux bugs, aux problèmes de sécurité et aux besoins évolutifs des utilisateurs.
Un projet obtient 5 si son dernier commit date de moins de 30 jours, 4 si de moins de 6 mois, 3 si de moins d'un an, et 2 si de moins de 2 ans. Les projets n'ayant reçu aucun commit depuis plus de 2 ans obtiennent 1, ce qui peut signaler un abandon ou une transition vers une phase de maintenance uniquement.
1,0 -
Popularité
Le score de popularité est basé sur le nombre d'étoiles GitHub que le projet a reçues. Bien que les étoiles soient un indicateur imparfait de l'adoption, elles restent l'un des signaux les plus largement disponibles et comparables de l'intérêt communautaire et de la visibilité.
Un projet ayant moins de 5 000 étoiles obtient 1. Le score passe à 2 à 5 000 étoiles, 3 à 20 000, 4 à 40 000, et atteint le maximum de 5 à 80 000 étoiles ou plus. Ces seuils sont volontairement élevés pour différencier les projets open source les plus connus.
1,0 -
Ancienneté
Le score d'ancienneté reflète depuis combien de temps un projet existe, mesuré par le temps écoulé depuis son tout premier commit. Un long historique est le signe d'un projet qui a résisté à l'épreuve du temps, accumulé un savoir institutionnel et s'est stabilisé au fil de plusieurs cycles de publication.
Les projets reçoivent un score de 1 si leur premier commit date de moins d'un an, indiquant un projet très jeune. Un score de 2 est attribué à partir d'un an, 3 à partir de 5 ans, 4 à partir de 10 ans, et le score maximal de 5 est réservé aux projets ayant 20 ans ou plus d'historique. Ces seuils récompensent la durabilité à long terme sans pénaliser trop sévèrement les projets plus récents.
4,0 -
Nombre de contributeurs
Le score de contributeurs évalue le nombre de personnes travaillant activement sur le projet. Plutôt que de compter tous les contributeurs historiques, il se concentre sur ceux ayant effectué plus de 3 commits au cours des 6 derniers mois, en excluant les bots. Cela filtre les contributeurs ponctuels et les comptes automatisés.
Un projet sans contributeur actif éligible obtient 1. Un score de 2 nécessite au moins 1 contributeur actif, 3 en nécessite 5, 4 en nécessite 20, et le score le plus élevé de 5 est attribué aux projets comptant 50 contributeurs actifs ou plus. Cela reflète l'étendue et la santé de la communauté de développement autour du projet.
Une base de contributeurs diversifiée réduit le risque du « bus factor » : la probabilité que le projet s'arrête si un seul mainteneur se retire. Les projets avec de nombreux contributeurs actifs sont généralement plus résilients, mieux révisés et plus susceptibles de maintenir un développement à long terme.
1,0 -
Documentation technique
Le score de documentation est une évaluation composite de la qualité de la documentation d'un projet, combinant quatre sous-métriques avec des pondérations différentes : qualité du README (40 %), présence et richesse d'un répertoire docs (30 %), nombre de sections clés du README (20 %) et fonctionnalités d'accessibilité (10 %).
La qualité du README est évaluée sur sa longueur et sa structure. Un README complet de plus de 3 000 mots et comportant au moins 8 sections clés (telles que installation, utilisation, configuration, contribution, exemples et licence) obtiendra le score le plus élevé. La sous-métrique du répertoire docs récompense les projets maintenant un dossier de documentation dédié, avec des points supplémentaires pour un plus grand nombre de fichiers. L'accessibilité vérifie la présence d'un fichier CONTRIBUTING.md et de modèles d'issues GitHub, qui abaissent la barrière d'entrée pour les nouveaux contributeurs.
Ces quatre sous-métriques sont combinées en une valeur pondérée unique (0-100), puis converties en un score de 1 à 5 à l'aide de seuils à 20, 40, 60 et 80 points. Un projet ne disposant que d'un court README et d'aucun répertoire docs obtiendra un score faible, tandis qu'un projet avec une documentation approfondie dans toutes les dimensions atteindra le score maximal. Une bonne documentation est l'un des indicateurs les plus forts d'un projet soucieux de ses utilisateurs et contributeurs.
1,0
Tech
3,5-
Dette technique
Le score de dette technique reflète la santé structurelle du code de production : complexité excessive, couplage fort, violations des conventions de codage, etc.
Un score de 5 correspond à un code propre et bien structuré ; un score de 1 indique une dette importante susceptible de freiner l'évolution du projet. Les valeurs intermédiaires traduisent des niveaux croissants de dégradation structurelle.
Contrairement à la taille ou à la couverture de tests, la dette technique est un indicateur qualitatif : elle ne dit pas combien de code existe, mais dans quel état il se trouve. Elle conditionne directement la facilité à corriger un bug, à ajouter une fonctionnalité ou à reprendre un projet après une longue période d'inactivité.
2,5 -
Couverture des tests
Le score de tests évalue l'investissement du projet dans les tests automatisés, mesuré par le ratio entre les lignes de code de test et les lignes de code de production. Les fichiers de tests sont identifiés par des conventions de nommage courantes (_test, .test., .spec.) et des motifs de répertoires (/tests/, /tests/, /t/, etc.).
Un ratio de 0,1 (10 % de code de test par rapport au code de production) donne un score de 2, 0,4 (40 %) donne 3, 0,8 (80 %) donne 4, et un ratio de 1,6 ou plus (160 %, soit plus de code de test que de code de production) donne le score maximal de 5. Les projets avec un ratio de tests inférieur à 10 % obtiennent 1.
Un ratio de tests sain est l'un des signaux les plus forts de qualité logicielle. Les projets disposant de suites de tests étendues sont plus susceptibles de détecter les régressions, plus faciles à refactoriser en toute sécurité et plus accueillants pour les contributeurs qui peuvent valider leurs modifications. Les seuils sont volontairement progressifs : atteindre un ratio test/code de 1:1 ou au-delà démontre un engagement exceptionnel envers la fiabilité.
1,0 -
Taille globale
Le score de taille reflète le volume de code de production du projet, mesuré en lignes de code (LOC). Le comptage des lignes est effectué par Tokei, un outil rapide et précis qui ne compte que les lignes de code effectives, en excluant les commentaires et les lignes vides. Les fichiers de tests sont exclus de ce décompte.
Les projets de moins de 1 000 lignes de code obtiennent 5, tandis que ceux dépassant 1 000 000 de lignes obtiennent 1. Les seuils intermédiaires sont 10 000 (score 4), 100 000 (score 3) et 1 000 000 (score 2).
Un code source plus petit est généralement plus facile à comprendre, à auditer et à maintenir. Les bases de code volumineuses ont tendance à accumuler de la dette technique et sont plus difficiles à aborder pour les nouveaux contributeurs. Cependant, ce score doit être interprété en contexte : un grand projet n'est pas intrinsèquement mauvais si sa complexité et sa couverture de tests restent saines. Certains domaines nécessitent tout simplement plus de code.
4,0 -
Complexité
Le score de complexité mesure la proportion de fonctions dans le code source présentant une complexité cyclomatique élevée, telle qu'analysée par Lizard. La complexité cyclomatique compte le nombre de chemins d'exécution indépendants à travers une fonction. Une fonction est considérée comme très complexe lorsque sa complexité cyclomatique dépasse 15.
La métrique utilisée est le pourcentage de fonctions à haute complexité par rapport au nombre total de fonctions. L'analyse se concentre sur les 1 000 plus gros fichiers de production, en filtrant le code tiers (vendored), les fichiers générés, les scripts de build, la documentation et les autres répertoires non essentiels. Cela garantit que le score reflète le code propre du projet plutôt que les dépendances tierces.
Le score utilise une logique « plus petit est mieux » : un projet où 5 % ou moins des fonctions sont très complexes obtient 5. Le score diminue à 4 à 10 %, 3 à 20 %, 2 à 30 %, et 1 au-delà de 30 %. Une complexité cyclomatique élevée est souvent corrélée à du code plus difficile à tester, plus sujet aux bugs et plus difficile à maintenir.
5,0
Sécurité
2,7-
Politique de sécurité
Nous utilisons Scorecard
Cette vérification tente de déterminer si le projet a publié une politique de sécurité. Elle fonctionne en recherchant un fichier nommé SECURITY.md (insensible à la casse) dans quelques répertoires bien connus.
Une politique de sécurité (généralement un fichier SECURITY.md) peut fournir aux utilisateurs des informations sur ce qui constitue une vulnérabilité et comment en signaler une de manière sécurisée, afin que les informations sur un bug ne soient pas publiquement visibles.
Cette vérification examine le contenu du fichier de politique de sécurité en attribuant des points aux politiques qui décrivent les processus de gestion des vulnérabilités, les délais de divulgation et contiennent des liens (par exemple, URL et adresses e-mail) pour accompagner les utilisateurs.
1,0 -
Dépendances épinglées
Nous utilisons Scorecard
Cette vérification tente de déterminer si le projet épingle les dépendances utilisées lors de son processus de build et de publication. Une « dépendance épinglée » est une dépendance explicitement définie sur un hash spécifique au lieu d'autoriser une version mutable ou une plage de versions. Elle est actuellement limitée aux dépôts hébergés sur GitHub et ne prend pas en charge les autres plateformes d'hébergement de code source (c'est-à-dire les forges).
La vérification fonctionne en recherchant les dépendances non épinglées dans les Dockerfiles, les scripts shell et les workflows GitHub utilisés lors du processus de build et de publication d'un projet. Des considérations spéciales pour les modules Go traitent les versions sémantiques complètes comme épinglées en raison de la manière dont l'outil Go vérifie le contenu téléchargé par rapport aux hashs lors du premier téléchargement du module.
Les dépendances épinglées réduisent plusieurs risques de sécurité :
- Elles garantissent que la vérification et le déploiement sont tous effectués avec le même logiciel, réduisant les risques de déploiement, simplifiant le débogage et permettant la reproductibilité.
- Elles peuvent aider à atténuer l'impact de dépendances compromises sur la sécurité du projet (dans le cas où vous avez évalué la dépendance épinglée, vous êtes confiant qu'elle n'est pas compromise, et qu'une version ultérieure publiée est compromise).
- Elles constituent un moyen de contrer les attaques par confusion de dépendances (alias substitution), dans lesquelles une application utilise plusieurs sources pour acquérir des paquets logiciels (une « configuration hybride »), et les attaquants trompent l'utilisateur en lui faisant utiliser un paquet malveillant via une source inattendue pour ce paquet.
Cependant, épingler les dépendances peut freiner les mises à jour logicielles, que ce soit en raison d'une vulnérabilité de sécurité ou parce que la version épinglée est compromise. Atténuez ce risque en :
- utilisant des outils automatisés pour notifier les applications lorsque leurs dépendances sont obsolètes ;
- mettant à jour rapidement les applications qui épinglent leurs dépendances.
-
Empaquetage
Nous utilisons Scorecard
Cette vérification tente de déterminer si le projet est publié sous forme de paquet. Elle est actuellement limitée aux dépôts hébergés sur GitHub et ne prend pas en charge les autres plateformes d'hébergement de code source (c'est-à-dire les forges).
Les paquets offrent aux utilisateurs d'un projet un moyen simple de télécharger, installer, mettre à jour et désinstaller le logiciel via un gestionnaire de paquets. En particulier, ils facilitent la réception des correctifs de sécurité sous forme de mises à jour.
La vérification recherche actuellement les workflows de packaging GitHub et les GitHub Actions spécifiques aux langages qui téléversent le paquet vers un hub correspondant, par exemple Npm. Nous prévoyons d'ajouter un meilleur support pour interroger directement les hubs de gestionnaires de paquets à l'avenir, par exemple pour Npm, PyPi.
Vous pouvez créer un paquet de plusieurs manières :
- De nombreux écosystèmes de langages de programmation ont un format de packaging couramment utilisé, supporté par un outil de gestion de paquets au niveau du langage et un dépôt public de paquets.
- De nombreuses plateformes de systèmes d'exploitation disposent également d'au moins un format de paquet, un outil et un dépôt public (dans certains cas, le dépôt source génère des paquets source indépendants du système, qui sont ensuite utilisés par d'autres pour générer des paquets exécutables système).
- En utilisant des images de conteneurs.
-
Vulnérabilités
Nous utilisons Scorecard
Cette vérification détermine si le projet présente des vulnérabilités ouvertes et non corrigées dans son propre code ou ses dépendances, en utilisant le service OSV (Open Source Vulnerabilities). Une vulnérabilité ouverte est facilement exploitable par des attaquants et doit être corrigée dès que possible.
5,0 -
Artefacts binaires
Nous utilisons Scorecard
Cette vérification détermine si le projet a généré des artefacts exécutables (binaires) dans le dépôt source.
Inclure des exécutables générés dans le dépôt source augmente les risques pour les utilisateurs. De nombreux systèmes de langages de programmation peuvent générer des exécutables à partir du code source (par exemple, le code machine généré par C/C++, les fichiers .class Java, les fichiers .pyc Python et le JavaScript minifié). Les utilisateurs utilisent souvent directement les exécutables s'ils sont inclus dans le dépôt source, ce qui conduit à de nombreux comportements dangereux.
Problèmes liés aux artefacts exécutables (binaires) générés :
- Les artefacts binaires ne peuvent pas être révisés, permettant la présence possible d'exécutables obsolètes ou malicieusement altérés. Les revues examinent généralement le code source, pas les exécutables, car il est difficile d'auditer les exécutables pour s'assurer qu'ils correspondent au code source. Avec le temps, les exécutables inclus pourraient ne plus correspondre au code source.
- Les exécutables générés permettent au processus de génération de s'atrophier, ce qui peut conduire à l'impossibilité de créer des exécutables fonctionnels. Ces problèmes peuvent être contrebalancés par des builds reproductibles vérifiés, mais il est plus facile de mettre en place des builds reproductibles vérifiés lorsque les exécutables ne sont pas inclus dans le dépôt source (car le processus de génération est moins susceptible de s'être atrophié).
Autorisés par Scorecard :
- Les fichiers dans le dépôt source qui sont simultanément du code source révisable et des exécutables, car ils sont révisables. (Certains systèmes interprétatifs, comme de nombreux shells de systèmes d'exploitation, n'ont pas de mécanisme pour stocker des exécutables générés différents du fichier source.)
- Le code source dans le dépôt source généré par d'autres outils (par exemple, par bison, yacc, flex et lex). Le code source généré présente des inconvénients potentiels, mais il tend à être beaucoup plus facile à réviser et présente donc un risque moindre. Le code source généré est aussi souvent difficile à détecter pour les outils externes.
- La documentation générée dans les dépôts source. La documentation générée est destinée à être utilisée par des humains (pas des ordinateurs) qui peuvent évaluer le contexte. Ainsi, la documentation générée ne présente pas le même niveau de risque.
-
Protection des branches
Nous utilisons Scorecard
Cette vérification détermine si les branches par défaut et de publication du projet sont protégées par les paramètres de protection de branche ou les règles de dépôt de GitHub. La protection de branche permet aux mainteneurs de définir des règles imposant certains workflows pour les branches, comme exiger une revue ou le passage de certaines vérifications de statut avant l'acceptation dans une branche principale, ou empêcher la réécriture de l'historique public.
Différents types de protection de branche protègent contre différents risques :
- Exiger une revue de code :
- exiger au moins un réviseur réduit considérablement le risque qu'un contributeur compromis puisse injecter du code malveillant. La revue augmente également la probabilité qu'une vulnérabilité involontaire dans une contribution soit détectée et corrigée avant que la modification ne soit acceptée.
- exiger deux réviseurs ou plus protège encore davantage contre le risque interne où un contributeur compromis peut être utilisé par un attaquant pour approuver la PR de l'attaquant et injecter du code malveillant comme s'il était légitime.
- Empêcher le force push : empêche l'utilisation de la commande --force sur les branches publiques, qui écrase le code de manière irréversible. Cette protection empêche la réécriture de l'historique public sans notification externe.
- Exiger des vérifications de statut : garantit que tous les tests CI requis sont satisfaits avant qu'une modification ne soit acceptée.
-
Revue de code
Nous utilisons Scorecard
Cette vérification détermine si le projet exige une revue de code humaine avant que les pull requests (merge requests) ne soient fusionnées.
Les revues détectent divers problèmes involontaires, y compris des vulnérabilités qui peuvent être corrigées immédiatement avant leur fusion, ce qui améliore la qualité du code. Les revues peuvent également détecter ou dissuader un attaquant tentant d'insérer du code malveillant (soit en tant que contributeur malveillant, soit en tant qu'attaquant ayant compromis le compte d'un contributeur), car un réviseur pourrait détecter la subversion.
La vérification détermine si les modifications les plus récentes (sur les ~30 derniers commits) ont reçu une approbation sur GitHub ou si la personne qui fusionne est différente de celle qui a commité (revue implicite). Elle effectue également une vérification similaire pour les revues utilisant Prow (labels « lgtm » ou « approved ») et Gerrit (« Reviewed-on » et « Reviewed-by »). Si les modifications récentes sont uniquement de l'activité de bots (par exemple Dependabot, Renovate bot ou des bots personnalisés), la vérification renvoie un résultat non concluant.
Le scoring est par paliers plutôt que proportionnel pour rendre la vérification plus prévisible. Si des modifications d'origine bot ne sont pas révisées, 3 points sont déduits. Si des modifications humaines ne sont pas révisées, 7 points sont déduits si une seule modification n'est pas révisée, et 3 points supplémentaires sont déduits si plusieurs modifications ne sont pas révisées.
Les revues par des bots, y compris ceux utilisant l'intelligence artificielle / l'apprentissage automatique (IA/ML), ne comptent pas comme revue de code. De telles revues ne garantissent pas qu'une seconde personne comprenne la modification du code (par exemple, si l'auteur devient soudainement indisponible). Cependant, l'analyse par des bots peut être en mesure de satisfaire (au moins en partie) le critère SAST.
1,4 -
Versions signées
Nous utilisons Scorecard
Cette vérification tente de déterminer si le projet signe cryptographiquement ses artefacts de publication. Elle est actuellement limitée aux dépôts hébergés sur GitHub et ne prend pas en charge les autres plateformes d'hébergement de code source (c'est-à-dire les forges).
Les publications signées attestent de la provenance de l'artefact.
Cette vérification recherche les noms de fichiers suivants dans les cinq derniers assets de publication du projet :
*.minisig,*.asc(pgp),*.sig,*.sign,*.sigstore,*.sigstore.json,*.intoto.jsonl.Si une signature est trouvée dans les assets de chaque publication, un score de 8 est attribué. Si un fichier de provenance SLSA est trouvé dans les assets de chaque publication (*.intoto.jsonl), le score maximal de 10 est attribué.
Cette vérification examine les 30 publications les plus récentes associées à un artefact. Elle ignore les publications contenant uniquement le code source qui sont créées automatiquement par GitHub.
4,2
Aperçu
Pitrery est un ensemble d’outils open‑source qui simplifient la gestion des sauvegardes PITR (Point‑In‑Time Recovery) pour PostgreSQL, de la version 9 à 14. Il automatise la prise de backup de base, l’archivage compressé des segments WAL (localement ou via SSH), permet la restauration à une date précise et assure la rétention des sauvegardes. Le projet est désormais en mode maintenance‑only (LTS jusqu’en décret 2026) sous licence BSD 2‑clauses. L’installation se fait en quelques lignes : make && make install, puis pitrery configure -o pitrery -f [[user@]host:]/chemin/vers/backups.