phantomstars

Détection et suivi automatisés des faux engagements sur GitHub

Un projet de JS Labs — faisant partie de l'initiative AI Slop Intelligence.
Tourne chaque jour. Attribue un score à chaque compte suspect. Détecte les campagnes de bots coordonnées.
Ouvre des issues directement sur les dépôts compromis afin que les mainteneurs puissent agir.

---

Soutenez ce projet

BTC   3QjWqhQbHdHgWeYHTpmorP8Pe1wgDjJy54
ETH   0x5851e6145F4773d1585b8686095FB16E368a4dA1
ZEC   t1KSR5YkNPbjqRSCoLKo5AddFWdm9Kzxh1B

---

Pourquoi ce projet existe

Les étoiles GitHub sont un signal de confiance. C'est ainsi que les développeurs décident quoi évaluer, de quoi dépendre et quoi recommander. Ce signal est en train d'être systématiquement corrompu.

Pendant le boom de l'IA de 2024-2026, une industrie de fermes de bots a émergé pour fabriquer de la crédibilité pour des dépôts de mauvaise qualité, souvent malveillants. Un projet avec 800 étoiles en 48 heures paraît légitime à un développeur qui parcourt les résultats de recherche. C'est tout l'intérêt. L'objectif des faux engagements n'est pas les étoiles en elles-mêmes ; c'est la preuve sociale que ces étoiles produisent, et les décisions en aval que cette preuve sociale influence.

Le schéma est identifiable. Des comptes créés la même semaine, sans bio, sans abonnés, sans dépôts d'origine, qui mettent une étoile aux mêmes 15 dépôts en l'espace de 2 heures. Pas une seule campagne, mais des dizaines qui tournent simultanément, chaque jour, à travers des milliers de comptes. Les données montrent des dépôts où 185 personnes sur 185 ayant interagi sont des bots. Un taux de fausseté de 100 %. Des places entières dans le classement construites sur du vide.

phantomstars a été créé parce que ce problème est traitable. Le rapport signal/bruit dans l'API publique de GitHub est, pour l'instant, encore suffisamment élevé pour que les campagnes coordonnées laissent des empreintes claires. Ce projet lit ces empreintes, publie les données brutes et notifie directement les mainteneurs de dépôts concernés.

Ce projet fait partie des travaux plus larges d'AI Slop Intelligence menés chez JS Labs, une recherche continue sur les mécanismes et les effets mesurables du contenu de mauvaise qualité généré par l'IA qui inonde les écosystèmes de développeurs. Les faux engagements ne sont pas un problème périphérique. C'est le mécanisme de distribution qui met le slop sous les yeux des vrais utilisateurs.

---

Ce qu'il fait

phantomstars exécute un job GitHub Actions quotidien qui :

1. Scrape la page GitHub Trending pour repérer les dépôts qui gagnent des étoiles aujourd'hui
2. Interroge l'API de recherche GitHub pour les dépôts créés au cours des 7 derniers jours avec une activité soudaine d'étoiles (la fenêtre plus large permet de détecter les campagnes de plusieurs jours manquées par les analyses limitées à 24 h)
3. Ajoute des dépôts candidats supplémentaires à partir des publications Reddit récentes dans r/osinttools et r/coolgithubprojects en extrayant les liens de dépôts GitHub des 2 derniers jours
4. Récupère les événements d'interaction récents (étoiles, forks) via l'API Events (dernières 24 heures par dépôt)
5. Récupère le profil complet de chaque compte ayant interagi via GraphQL : date de création du compte, nombre d'abonnés/abonnements, bio, historique des dépôts
6. Note chaque compte selon un modèle heuristique composite : ancienneté du compte, complétude du profil, schémas de dépôts et historique d'activité
7. Détecte les campagnes coordonnées à l'aide du regroupement par horodatage et de l'union-find : des grappes de comptes suspects ayant interagi dans une fenêtre de 3 heures
8. Applique la liste blanche des faux positifs avant les écritures dans le registre, les ratios par dépôt, les tableaux de bord et les notifications, afin que chaque métrique visible utilise la même population
9. Ajoute tous les suspects à un registre JSONL en ajout seul (append-only) et le commit dans ce dépôt
10. Publie un flux de renseignement par dépôt montrant quels dépôts sont ciblés, quelles sources de découverte les ont trouvés et si la fenêtre de l'API Events était complète ou plafonnée
11. Ouvre des issues GitHub directement sur les dépôts ciblés afin que les mainteneurs voient les données de la campagne dans leur propre outil de suivi d'issues
12. Écrit un rapport d'analyse formaté dans le résumé du job GitHub Actions

Pas de serveurs. Pas de bases de données. Pas de facture d'infrastructure.

---

Foire aux questions

Est-ce qu'il notifie le dépôt ciblé ?

Oui. Lorsque le taux de fausseté d'un dépôt dépasse 40 % ou qu'une campagne coordonnée est détectée, phantomstars ouvre une issue directement sur ce dépôt. L'issue contient le tableau complet des suspects, l'appartenance à la campagne, les scores composites et les dates de création des comptes : tout ce dont un mainteneur a besoin pour enquêter et faire un signalement à GitHub.

Si les issues sont désactivées sur un dépôt ciblé, la notification est ignorée silencieusement et consignée dans le journal d'analyse.

Puis-je demander une vérification pour un dépôt spécifique ?

Oui.

• Pour une vérification ponctuelle normale, soumettez un dépôt au format owner/repo et lancez une analyse ciblée.
• Pour une demande d'audit à vie, utilisez le mode ponctuel à vie. Il est séparé de l'analyse quotidienne.

Pourquoi cette distinction :

• Le modèle d'analyse normal est conçu pour les interactions publiques récentes et un coût d'exploitation faible.
• Un audit à vie peut impliquer des dizaines de milliers d'étoiles et des milliers de forks sur les dépôts plus importants.
• Cela est réalisable pour une investigation ponctuelle, mais c'est trop coûteux et trop lent pour le chemin quotidien par défaut.
• Les demandes à vie ne sont donc exécutées qu'en mode ponctuel explicite avec des garde-fous.

Puis-je signaler un faux positif ?

Oui. Si votre compte apparaît dans data/suspects.jsonl et que vous pensez que la classification est incorrecte, ouvrez une issue de faux positif en utilisant le modèle fourni. Les signalements sont examinés manuellement avant toute ajout à la liste blanche. La liste blanche est stockée dans data/allowlist.txt ; les comptes qui y figurent sont exclus de toutes les analyses futures et du registre des suspects.

Qu'est-ce que l'identifiant de campagne ?

Un identifiant de campagne (par ex. c-a3f9b2e1) est une empreinte hexadécimale déterministe de 8 caractères dérivée du hachage SHA-256 de l'ensemble trié des identifiants des membres de cette campagne. Le même groupe de comptes produira le même identifiant de campagne lors d'analyses indépendantes, ce qui permet un suivi longitudinal. Ce n'est ni un nom de dépôt, ni un nom d'utilisateur, ni un identifiant externe.