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?

Ja. Das Erstellungsdatum jedes Kontos wird über die GitHub-GraphQL-API abgerufen (createdAt-Feld) und in jedem Verdächtigendatensatz als account_created_at gespeichert. Es ist auch die primäre Eingabe für den Kontoalter-Score, das stärkste einzelne Signal für Fake-Konten. Konten, die innerhalb von 2 Tagen nach ihrer Erstellung interagieren, erhalten allein aufgrund des Alters einen Score von 1.0.

Wie sicher ist es?

Einzelne Scores haben durchaus relevante False-Positive-Raten. Ein neuer Entwickler mit spärlichem Profil erreicht legitimerweise 0.75+. Das Tool berücksichtigt dies, indem es kampagnenbezogene Beweise verlangt, bevor Issues erstellt werden; ein einzelnes verdächtiges Konto reicht nicht aus. Ein koordiniertes Cluster aus 40+ Konten, die alle in derselben Woche erstellt wurden, alle 0.75+ erzielen, alle innerhalb von 90 Minuten interagieren, ist eine andere Sache. Hier wird Vertrauen handlungsrelevant.

Die Daten sind immer probabilistisch. Die Issue-Texte sagen das ausdrücklich. Das Ziel ist, Maintainern das Signal und die rohen Beweise zu liefern, um ihr eigenes Urteil zu fällen.

Live-Dashboard

Die am häufigsten angegriffenen Repos heute

Bewertungsmodell

Jedes Konto erhält einen zusammengesetzten Verdachts-Score (0.0 = sauber, 1.0 = vermutlich fake) aus vier Signalen:

Klassifizierungsschwellen:

Kampagnenerkennung

Eine Kampagne ist eine Gruppe von ≥ 4 verdächtigen Konten, die alle innerhalb eines 3-Stunden-Fensters mit demselben Repo interagiert haben. Der Algorithmus verwendet Union-Find, um verbundene Komponenten zu bilden; Konten, die innerhalb des Fensters gemeinsam interagiert haben, werden zusammengeführt, und jede Komponente über der Mindestgröße wird als koordinierte Kampagne markiert.

Kampagnen-IDs sind stabile SHA-256-Fingerabdrücke der sortierten Mitgliedermenge. Dieselbe Kampagne, die an aufeinanderfolgenden Tagen erkannt wird, hat dieselbe ID, solange sich die Mitgliedschaft nicht ändert.

Warum Kampagnen das eigentliche Signal sind: Einzelne Scores haben relevante False-Positive-Raten. Ein neuer Entwickler mit spärlichem Profil kann allein 0.80 erreichen. Vierzig Konten, die alle 0.75+ erzielen, in derselben Woche erstellt wurden und alle innerhalb von 90 Minuten dasselbe Repo mit Sternen versehen, sind kein Zufall. Das Kampagnensignal ist der Punkt, an dem die Daten handlungsrelevant werden: der Unterschied zwischen einem verdächtigen Datenpunkt und dem Beweis einer koordinierten Operation.

Datenformat

Alle Ergebnisse werden in data/suspects.jsonl und data/repos.jsonl eingecheckt, ein JSON-Datensatz pro Zeile, append-only. Die GitHub-Actions-Job-Zusammenfassung (nach jedem Lauf in der Actions-Oberfläche sichtbar) liefert einen formatierten Bericht pro Scan.

suspects.jsonl — ein Datensatz pro gekennzeichnetem Konto pro Scan:```json { "login": "user98432", "account_age_score": 0.9, "profile_score": 0.8, "repo_pattern_score": 0.8, "activity_score": 0.85, "composite": 0.842, "classification": "likely_fake", "campaign_id": "c-a3f9b2e1", "scan_date": "2026-05-17", "account_created_at": "2026-05-15", "target_repos": ["owner/repo-a", "owner/repo-b"] }

**repos.jsonl** — ein Datensatz pro Ziel-Repository pro Scan:```json
{
  "full_name": "owner/suspicious-repo",
  "total_scanned": 87,
  "likely_fake": 62,
  "suspicious": 18,
  "known_likely_fake": 27,
  "known_likely_fake_ratio": 0.310,
  "repeat_offenders": 11,
  "allowlisted_excluded": 3,
  "fakeness_ratio": 0.713,
  "classification": "likely_fake",
  "campaign_count": 3,
  "discovery_sources": ["github_search_recent", "reddit_osinttools"],
  "event_sample_complete": false,
  "scan_date": "2026-05-17"
}

Abfragebeispiele:```bash

All likely_fake accounts from today

jq 'select(.scan_date == "2026-05-17" and .classification == "likely_fake") | .login' data/suspects.jsonl

Accounts created in the last 3 days that were flagged

jq 'select(.account_created_at >= "2026-05-14") | [.login, .account_created_at, .classification] | @tsv' -r data/suspects.jsonl

Which repos were targeted today, sorted by fakeness ratio

jq 'select(.scan_date == "2026-05-17") | [.full_name, .fakeness_ratio, .likely_fake] | @tsv' -r data/repos.jsonl | sort -t$'''\t''' -k2 -rn

Repos with the highest recycled-bot share from previously seen likely_fake accounts

jq 'select(.scan_date == "2026-05-17") | [.full_name, .known_likely_fake_ratio, .repeat_offenders] | @tsv' -r data/repos.jsonl | sort -t$'''\t''' -k2 -rn

All members of a specific campaign

jq 'select(.campaign_id == "c-a3f9b2e1") | [.login, .account_created_at, .composite] | @tsv' -r data/suspects.jsonl

Repos a specific account targeted

jq 'select(.login == "user98432") | .target_repos[]' data/suspects.jsonl

High-confidence repos: fakeness ratio above 60%

jq 'select(.fakeness_ratio >= 0.6) | [.full_name, .fakeness_ratio, .campaign_count] | @tsv' -r data/repos.jsonl | sort -t$'\t' -k2 -rn

---

## Einrichtung

### 1. Forke dieses Repository

Dein Fork besitzt die Daten. Nach jedem täglichen Lauf werden die Ergebnisse in `data/suspects.jsonl` und `data/repos.jsonl` in deinem Fork committet.

### 2. Füge ein GitHub-PAT-Secret hinzu

Erstelle einen **klassischen** Personal Access Token mit den folgenden Bereichen:
- `public_repo`: öffentliche Repo-Events und Stargazer lesen, Issues in öffentlichen Repos erstellen
- `read:user`: Benutzerprofile über GraphQL abrufen

**Einstellungen → Geheimnisse und Variablen → Actions → Neues Repository-Geheimnis** → nenne es `GH_TOKEN`.

> Das Standard-`GITHUB_TOKEN` hat eingeschränkte Ratenlimits und kann den GraphQL-Endpunkt für Benutzer nicht mit voller Kapazität aufrufen. Ein PAT ist erforderlich.

### 3. Aktiviere Actions

**Actions → GitHub Actions aktivieren** auf deinem Fork. Der Workflow läuft täglich um **07:00 Uhr britischer Zeit** unter Verwendung der `Europe/London`-Uhr:
- **06:00 UTC** während der britischen Sommerzeit
- **07:00 UTC** während der Greenwich Mean Time

Es ist keine zusätzliche Umgebungsvariable für die Zeitplanung erforderlich. Der GitHub-Actions-Cron ist ausschließlich UTC-basiert, sodass der Workflow zu beiden UTC-Stunden ausgelöst wird und nur fortfährt, wenn die lokale Londoner Zeit 07:00 Uhr ist. Manueller Trigger über **Actions → Daily Phantom Stars Scan → Workflow ausführen** verfügbar.

Nach jedem Lauf ist der formatierte Scan-Bericht unter **Actions → [run] → Zusammenfassung** sichtbar.

### 4. Lokal ausführen```bash
git clone https://github.com/YOUR_USERNAME/phantomstars.git
cd phantomstars
python -m venv venv && source venv/bin/activate
pip install -e .
GH_TOKEN=ghp_your_token python -m phantomstars.main

Für einen Ad-hoc-Lokallauf nach der Einrichtung:```bash GH_TOKEN=ghp_your_token python -m phantomstars.main

Um ein einzelnes Repository anstelle des normalen Discovery-Sets zu scannen:```bash
PHANTOMSTARS_TARGET_REPO=owner/repo GH_TOKEN=ghp_your_token python -m phantomstars.main

Einmalige Anfragen

Benutzer können eine einmalige Repo-Überprüfung auf zwei Arten anfordern:

1. Öffnen Sie die Issue-Vorlage Repo Check Request und geben Sie das Ziel-Repo sowie die gewünschte Tiefe an.
2. Verwenden Sie Actions -> Daily Phantom Stars Scan -> Run workflow und legen Sie optional fest:
   • target_repo: owner/repo
   • request_depth: recent oder lifetime-request

Aktuelles Verhalten:

• recent: führt den gezielten Scan der jüngsten Interaktionen sofort aus.
• lifetime-request: führt einen gezielten Lifetime-Scan über historische Stars und Forks nur für dieses Repo aus.
• Der täglich geplante Scan bleibt unverändert und verwendet weiterhin die Methode der jüngsten Interaktionen.

Schutzvorkehrungen für den Lifetime-Modus:

• nur für explizite einmalige gezielte Anfragen verfügbar
• durch konfigurierte Repository-Größenlimits vor Beginn des Scans begrenzt
• langsamer und API-intensiver als der tägliche Scan

Projektstruktur```

phantomstars/ ├── .github/ │ ├── workflows/daily-scan.yml # Runs daily at 07:00 Europe/London │ └── ISSUE_TEMPLATE/false_positive.yml ├── src/phantomstars/ │ ├── config.py # All constants, no argparse, no env parsing │ ├── models.py # Frozen dataclasses │ ├── github_client.py # REST + GraphQL, tenacity retries, rate-limit aware │ ├── heuristics.py # Per-user composite scoring engine │ ├── campaigns.py # Timestamp clustering + union-find │ ├── storage.py # JSONL append + query helpers │ ├── reporter.py # README dashboard injector │ ├── notifier.py # GitHub Issues notifier (files on targeted repos) │ └── main.py # Orchestration entry point ├── tests/ │ ├── conftest.py │ ├── test_heuristics.py │ └── test_campaigns.py ├── data/ │ ├── suspects.jsonl # Append-only account findings ledger │ ├── repos.jsonl # Append-only per-repo intelligence │ └── allowlist.txt # Accounts excluded from future scans └── pyproject.toml

---

## Einschränkungen und bekannte Fehlermodi

- **Events-API-Obergrenze:** maximal 300 letzte Events pro Repo. Repos mit Tausenden von Sternen pro Tag sind nur teilweise abgedeckt.
- **Coverage-Flag:** Repos, die die 300-Event-Grenze erreichen, werden in Berichten und Dashboards als `capped` markiert; die Verhältnisse für diese Repos sind konservative Stichproben und keine Ganztageszählungen.
- **Suchindex-Verzögerung:** Der Suchindex von GitHub ist letztendlich konsistent. Repos, die Sekunden vor der Scan-Grenze erstellt wurden, können übersehen werden.
- **Heuristik-Drift:** Bot-Betreiber passen sich an. Die Score-Gewichte müssen möglicherweise regelmäßig angepasst werden; passe die Konstanten in `config.py` an.
- **Einzelne Fehlpositive:** Ein neuer Entwickler mit einem spärlichen Profil erreicht isoliert einen Score von 0,75+. Die Mitgliedschaft in einer Kampagne ist das Signal mit hoher Konfidenz.
- **Kampagnen-ID-Drift:** Wenn sich die Mitgliedschaft einer Bot-Farm zwischen Scans ändert (Bots gesperrt, neue Bots hinzugefügt), ändert sich die Kampagnen-ID. Dies spiegelt die tatsächliche Kampagnenentwicklung wider und ist kein Fehler.
- **Rate-Limits:** 5.000 API-Anfragen pro Stunde mit einem authentifizierten PAT. Deutlich innerhalb der Limits für Standard-Trending-Seitengrößen.
- **Issues deaktiviert:** Einige untersuchte Repos deaktivieren Issues. Benachrichtigungen für diese Repos werden stillschweigend übersprungen.

---

## Prozess für Fehlpositive

Wenn dein Konto in `data/suspects.jsonl` erscheint und du glaubst, dass es falsch klassifiziert wurde:

1. Finde deinen Eintrag: `jq 'select(.login == "YOUR_LOGIN")' data/suspects.jsonl`
2. [Erstelle ein Fehlpositiv-Issue](../../issues/new?template=false_positive.yml) mit deinem Login, der Klassifikation, dem Scan-Datum und einer Erklärung
3. Berichte werden manuell geprüft. Verifizierte Fehlpositive werden zu `data/allowlist.txt` hinzugefügt und von allen zukünftigen Scans, Repo-Verhältnissen und Issue-Benachrichtigungen ausgeschlossen.

Hinweis: Das Erstellen eines Issues verändert oder entfernt keine vorhandenen Daten. Das Suspects-Ledger ist append-only. Die Allowlist wirkt sich nur auf zukünftige Scans aus.

---

## Mitwirken```bash
pip install -e ".[dev]"
python -m black .
python -m ruff check .
python -m mypy src
python -m pytest

Alle vier müssen bestanden sein, bevor ein PR erstellt wird.

Disclaimer

Dieses Tool führt eine schreibgeschützte Analyse öffentlicher GitHub-Daten mithilfe der offiziellen GitHub-API durch. Wo Issues in gezielten Repositorys erstellt werden, enthalten sie probabilistische Ergebnisse und sind klar als automatisiert gekennzeichnet. Die Ergebnisse sind Indikatoren, keine Anschuldigungen. Fehlalarme existieren und sind zu erwarten.

Entwickelt mit KI als Codierungspartner, als Reaktion auf ein Ökosystemproblem, das teilweise durch KI verursacht wurde.

Lizenz

Apache 2.0. Siehe LICENSE

Autor

Erstellt von tg12 · GitHub

Ein JS Labs Projekt · AI Slop Intelligence Dashboards