phantomstars

Automatische Erkennung und Verfolgung von Fake-Engagement auf GitHub

Ein JS Labs-Projekt — Teil der AI Slop Intelligence-Initiative.
Läuft täglich. Bewertet jedes verdächtige Konto. Erkennt koordinierte Bot-Kampagnen.
Öffnet direkt Issues in kompromittierten Repos, damit Maintainer handeln können.

---

Unterstütze dieses Projekt

BTC   3QjWqhQbHdHgWeYHTpmorP8Pe1wgDjJy54
ETH   0x5851e6145F4773d1585b8686095FB16E368a4dA1
ZEC   t1KSR5YkNPbjqRSCoLKo5AddFWdm9Kzxh1B

---

Warum es dieses Projekt gibt

GitHub-Sterne sind ein Vertrauenssignal. Sie bestimmen, was Entwickler bewerten, worauf sie sich verlassen und was sie weiterempfehlen. Dieses Signal wird systematisch korrumpiert.

Während des KI-Booms 2024-2026 entstand eine Branche von Bot-Farmen, die Glaubwürdigkeit für qualitativ minderwertige, oft bösartige Repositories herstellten. Ein Projekt mit 800 Sternen in 48 Stunden wirkt für Entwickler, die Suchergebnisse überfliegen, legitim. Genau das ist der Punkt. Das Ziel von Fake-Engagement sind nicht die Sterne selbst, sondern der soziale Beweis, den diese Sterne erzeugen, und die nachgelagerten Entscheidungen, die dieser soziale Beweis beeinflusst.

Das Muster ist erkennbar. Konten, die in derselben Woche erstellt wurden, keine Bio, keine Follower, keine eigenen Repositories, die innerhalb eines 2-Stunden-Fensters dieselben 15 Repos mit Sternen versehen. Nicht eine Kampagne, sondern dutzende laufen gleichzeitig, jeden Tag, über tausende Konten hinweg. Die Daten zeigen Repos, bei denen 185 von 185 Interagierenden Bots sind. Ein 100%-Fake-Anteil. Komplette Trending-Platzierungen, die auf nichts aufbauen.

phantomstars wurde entwickelt, weil dieses Problem lösbar ist. Das Signal-Rausch-Verhältnis in der öffentlichen GitHub-API ist derzeit noch hoch genug, dass koordinierte Kampagnen deutliche Fingerabdrücke hinterlassen. Dieses Projekt liest diese Fingerabdrücke, veröffentlicht die Rohdaten und benachrichtigt betroffene Repository-Maintainer direkt.

Dies ist Teil der umfassenderen Arbeit zu AI Slop Intelligence bei JS Labs, laufende Forschung zu den Mechanismen und messbaren Auswirkungen von minderwertigen KI-generierten Inhalten, die Entwickler-Ökosysteme überfluten. Fake-Engagement ist kein Randproblem. Es ist der Verteilungsmechanismus, der Slop vor echte Nutzer bringt.

---

Was es tut

phantomstars führt einen täglichen GitHub-Actions-Job aus, der:

1. Die GitHub Trending-Seite nach Repos durchsucht, die heute Sterne erhalten
2. Die GitHub Search API nach Repos abfragt, die in den letzten 7 Tagen erstellt wurden und plötzliche Stern-Aktivität aufweisen (das größere Fenster erfasst mehrtägige Kampagnen, die von reinen 24-Stunden-Scans übersehen werden)
3. Weitere Kandidaten-Repos aus aktuellen Reddit-Beiträgen in r/osinttools und r/coolgithubprojects hinzufügt, indem GitHub-Repo-Links aus den letzten 2 Tagen extrahiert werden
4. Aktuelle Engagement-Ereignisse (Sterne, Forks) über die Events API abruft (letzte 24 Stunden pro Repo)
5. Das vollständige Profil jedes interagierenden Kontos über GraphQL abruft: Erstellungsdatum des Kontos, Follower-/Following-Anzahl, Bio, Repo-Verlauf
6. Jedes Konto anhand eines zusammengesetzten Heuristikmodells bewertet: Kontoalter, Profilvollständigkeit, Repository-Muster und Aktivitätsverlauf
7. Koordinierte Kampagnen mittels Zeitstempel-Clustering und Union-Find erkennt: Cluster verdächtiger Konten, die innerhalb eines 3-Stunden-Fensters interagiert haben
8. Die False-Positive-Allowlist vor Ledger-Einträgen, Repo-Level-Quoten, Dashboards und Benachrichtigungen anwendet, sodass jede sichtbare Metrik dieselbe Grundgesamtheit verwendet
9. Alle Verdächtigen an ein append-only JSONL-Ledger anhängt, das in dieses Repo eingecheckt wird
10. Einen pro-Repo-Intelligence-Feed veröffentlicht, der zeigt, welche Repos angegriffen werden, welche Entdeckungsquellen sie gefunden haben und ob das Events-API-Fenster vollständig oder begrenzt war
11. Direkt GitHub Issues auf den Ziel-Repos eröffnet, damit Maintainer die Kampagnendaten in ihrem eigenen Issue-Tracker sehen
12. Einen formatierten Scan-Bericht in die GitHub-Actions-Job-Zusammenfassung schreibt

Keine Server. Keine Datenbanken. Keine Infrastrukturkosten.

---

Häufig gestellte Fragen

Wird das Ziel-Repo benachrichtigt?

Ja. Wenn der Fake-Anteil eines Repos 40% übersteigt oder eine koordinierte Kampagne erkannt wird, öffnet phantomstars direkt ein Issue in diesem Repository. Das Issue enthält die vollständige Verdächtigen-Tabelle, Kampagnenmitgliedschaft, zusammengesetzte Bewertungen und Erstellungsdaten der Konten: alles, was ein Maintainer zur Untersuchung und Meldung an GitHub benötigt.

Wenn Issues in einem Ziel-Repo deaktiviert sind, wird die Benachrichtigung still übersprungen und im Scan-Log protokolliert.

Kann ich eine Prüfung für ein bestimmtes Repository anfordern?

Ja.

• Für eine normale einmalige Prüfung reiche ein Repo im Format owner/repo ein und führe einen gezielten Scan aus.
• Für eine Lifetime-Audit-Anfrage nutze den einmaligen Lifetimemodus. Er ist getrennt vom täglichen Scan.

Warum die Trennung:

• Das normale Scan-Modell ist für aktuelle öffentliche Interaktionen und geringe Betriebskosten ausgelegt.
• Ein Lifetime-Audit kann bei größeren Repos Zehntausende von Sternen und Tausende von Forks umfassen.
• Das ist für eine einmalige Untersuchung machbar, aber für den standardmäßigen täglichen Ablauf zu teuer und zu langsam.
• Lifetime-Anfragen laufen daher nur im expliziten Einmalmodus mit Schutzmechanismen.

Kann ich einen False Positive melden?

Ja. Wenn dein Konto in data/suspects.jsonl erscheint und du glaubst, dass die Klassifizierung falsch ist, öffne ein False-Positive-Issue mit der bereitgestellten Vorlage. Meldungen werden manuell geprüft, bevor ein Allowlist-Eintrag hinzugefügt wird. Die Allowlist wird in data/allowlist.txt gespeichert; dort aufgeführte Konten werden von allen zukünftigen Scans und vom Verdächtigen-Ledger ausgeschlossen.

Was ist die Kampagnen-ID?

Eine Kampagnen-ID (z. B. c-a3f9b2e1) ist ein deterministischer 8-stelliger Hex-Fingerabdruck, der aus dem SHA-256-Hash der sortierten Menge der Mitglieder-Logins in dieser Kampagne abgeleitet wird. Dieselbe Gruppe von Konten erzeugt über unabhängige Scan-Läufe hinweg dieselbe Kampagnen-ID, was eine Längsschnittverfolgung ermöglicht. Es ist kein Repo-Name, kein Benutzername und keine externe Kennung.

Stabilität: Die ID ist stabil, solange sich die Mitgliedermenge der Kampagne nicht ändert. Wenn zwischen Scans Bots hinzugefügt oder gesperrt werden, ändert sich die ID, weil sich die Mitgliedschaft geändert hat. Das ist erwartet und spiegelt die reale Drift in der Zusammensetzung von Bot-Farmen wider.

Prüft es Erstellungsdaten von Konten?