GitHub hat am 5. Oktober 2026 neue Detektoren für sein Secret-Scanning-Programm angekündigt: Lovable-Tokens, Supabase-Schlüssel und Pydantic-AI-Gateway-Zugangsdaten werden nun automatisch in Repositories erkannt. Für Webprojekte, die stark auf Supabase als Backend-as-a-Service setzen, verkürzt die Neuerung das Zeitfenster, in dem ein versehentlich eingecheckter Schlüssel ausnutzbar bleibt.
Vier neue Detektoren, zwei unterschiedliche Mechanismen
Das Secret Scanning von GitHub funktioniert nach zwei unterschiedlichen Logiken. Sogenannte „Partner“-Secrets werden bei Fund in einem öffentlichen Repository direkt an den Aussteller weitergeleitet, was eine nahezu sofortige Sperrung ohne Zutun der Entwickler ermöglicht. „Nutzer“-Secrets lösen dagegen eine klassische Warnung aus, sichtbar im Sicherheits-Tab des Repositorys, egal ob öffentlich oder privat. Mit diesem Update tritt Supabase dem Partnerprogramm für zwei Token-Typen bei: supabase_oauth_access_token und supabase_scoped_personal_access_token. Lovable Labs folgt mit lovable_api_key, während Pydantic Services logfire_token und pydantic_ai_gateway_api_key hinzufügt.
Warum gerade Supabase
Supabase hat sich in den vergangenen Jahren als Open-Source-Alternative zu Firebase für zahlreiche Frontend-Projekte etabliert, oft kombiniert mit KI-gestützten App-Generatoren wie Lovable, wo ein Schlüssel in eine Konfigurationsdatei kopiert werden kann, ohne dass die Tragweite eines breit berechtigten Tokens immer bewusst ist. Ein geleaktes persönliches Supabase-Zugriffstoken kann potenziell Zugriff auf sämtliche Projekte einer Organisation gewähren, Datenbanken eingeschlossen. Die Aufnahme ins Partnerprogramm bedeutet, dass jeder in einem öffentlichen Repository gefundene Supabase-Schlüssel nun eine direkte Benachrichtigung an Supabase auslöst, das den Token ungültig machen kann, bevor der Maintainer des Repositorys es überhaupt bemerkt.
| Anbieter | Erkannter Secret-Typ | Status im Programm |
|---|---|---|
| Supabase | OAuth-Token, eingeschränktes persönliches Zugriffstoken | Partner (automatische Sperrung in öffentlichen Repos) |
| Lovable Labs | Lovable-API-Schlüssel | Partner (automatische Sperrung in öffentlichen Repos) |
| Pydantic Services | Logfire-Token, Pydantic-AI-Gateway-Schlüssel | Partner (automatische Sperrung in öffentlichen Repos) |
Worauf zu achten ist. Die automatische Sperrung gilt nur für öffentliche Repositories. In einem privaten Repository erzeugt ein geleakter Supabase-Schlüssel zwar eine Sicherheitswarnung, bleibt aber aktiv, bis ihn jemand manuell bei Supabase widerruft: Secret Scanning verringert das Risiko hier, beseitigt es aber nicht für Organisationen, die ausschließlich in privaten Repositories arbeiten.
Die bewährte Praxis bleibt durch diese Ankündigung unverändert: niemals einen Schlüssel committen, auch nicht vorübergehend, und stattdessen auf Umgebungsvariablen setzen, die beim Deployment geladen werden. Dieselbe Empfehlung findet sich bereits auf Mail Studio im Beitrag zur Härtung des WordPress-Logins, in dem die Verwaltung von Anwendungs-Zugangsdaten eine zentrale Rolle spielt.
# Prüfen, ob ein Supabase-Schlüssel in der lokalen Git-Historie steckt
git log -p --all | grep -E "supabase_(oauth_access_token|scoped_personal_access_token)"
# In .gitignore grundsätzlich Umgebungsdateien ausschließen
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
Ein in einem öffentlichen Repository vergessener Supabase-Schlüssel ist nicht mehr nur ein theoretisches Risiko: Er löst jetzt eine automatische Benachrichtigung an den Anbieter aus, der ihn sperren kann, noch bevor der Maintainer des Repositorys es bemerkt.
Für Teams, die bereits mehrere Projekte mit dedizierten Secret-Managern betreiben, ersetzt diese Erweiterung des Secret Scanning keinen eigenen Tresor, schließt aber einen Teil der Lücke zwischen Leck und Entdeckung. Sie fügt sich in einen breiteren Trend bei GitHub ein, das sein Partnerprogramm im Laufe von 2026 kontinuierlich ausgeweitet hat, da neue Cloud-Dienste und generative KI-Werkzeuge bei Webentwicklern zunehmend Verbreitung finden – ein Feld, das bereits in der Übersicht der auf Mail Studio verglichenen JavaScript-Paketmanager behandelt wurde.
Was man sich merken sollte
GitHub nimmt Lovable, Supabase und Pydantic in sein Partner-Secret-Scanning-Programm auf: Jeder in einem öffentlichen Repository gefundene Schlüssel dieser Anbieter wird nun automatisch zur Sperrung an den Aussteller weitergeleitet. Der Schutz bleibt auf öffentliche Repositories und die explizit von einem Detektor erfassten Secret-Typen beschränkt, was Teams nicht von einer soliden Secret-Management-Praxis im Vorfeld entbindet.
Ich begrüße diese Erweiterung, bleibe aber vorsichtig, wie man sie einordnet. Sie behandelt das Symptom, nicht die Ursache. Die eigentliche Frage bleibt seit Jahren dieselbe: warum breit berechtigte Schlüssel überhaupt in Commits landen. Solange KI-gestützte Scaffolding-Werkzeuge standardmäßig Konfigurationsdateien mit Klartext-Schlüsseln erzeugen, bleibt Secret Scanning ein nützliches, aber unzureichendes Sicherheitsnetz. — Simon Janvier
Zum Weiterlesen: offizielle Ankündigung im GitHub-Changelog.
