Mehr Low-Code und KI bedeutet auch mehr Secrets
Moderne Webprojekte entstehen heute oft in sehr kurzen Zyklen. Ein Prototyp verbindet Supabase, ein KI-Tool nutzt einen Gateway-Key, ein Agent greift auf externe Services zu und eine Plattform wie Lovable erzeugt innerhalb weniger Minuten eine funktionsfähige Anwendung. Technisch ist das beeindruckend – sicherheitlich entsteht aber ein bekanntes Problem in neuer Geschwindigkeit: API-Keys, Access Tokens und andere Zugangsdaten landen versehentlich im Repository.
GitHub hat sein Secret Scanning deshalb am 5. Oktober 2026 um mehrere neue Muster erweitert. Neu erkannt werden unter anderem `lovable_api_key`, `logfire_token`, `pydantic_ai_gateway_api_key`, `supabase_oauth_access_token` und `supabase_scoped_personal_access_token`. Lovable Labs ist zusätzlich dem Secret-Scanning-Partnerprogramm beigetreten.
Partner Alerts können schneller reagieren als ein Entwickler
Besonders relevant ist das Partnerprogramm. Erkennt GitHub in einem öffentlichen Repository ein Secret eines teilnehmenden Anbieters, wird der Anbieter direkt informiert. Er kann das Credential anschließend validieren und je nach Risiko widerrufen, rotieren oder den Nutzer kontaktieren. Der Vorteil liegt in der Geschwindigkeit: Ein öffentlich veröffentlichter Schlüssel kann theoretisch innerhalb kürzester Zeit von automatisierten Scannern gefunden und missbraucht werden.
GitHub scannt für Partner Alerts nicht nur klassischen Quellcode. Laut Dokumentation gehören auch öffentliche npm-Pakete, Issues, Pull Requests, Discussions, Wikis und Secret Gists zum Erkennungsbereich. Damit reagiert die Plattform auf eine Realität, in der Zugangsdaten nicht nur in `.env`-Dateien versehentlich auftauchen, sondern auch in Debug-Ausgaben, Tickets oder kopierten Support-Beispielen.
Ein Alert ist nur der Anfang der Reaktion
Wer einen Secret-Scanning-Alert erhält, sollte nicht einfach nur die Fundstelle löschen. Sobald ein Secret in einem Git-Commit oder öffentlich zugänglichen Inhalt vorhanden war, muss davon ausgegangen werden, dass es kopiert wurde. Die richtige Reihenfolge lautet deshalb normalerweise: Credential widerrufen oder rotieren, abhängige Systeme prüfen, Missbrauch analysieren und erst danach den Code beziehungsweise die Historie bereinigen.
Das ist besonders wichtig bei Tokens mit weitreichenden Berechtigungen. Ein Supabase-Token, ein AI-Gateway-Key oder ein Service-Credential kann je nach Scope Zugriff auf Daten, Infrastruktur oder kostenpflichtige APIs ermöglichen. Selbst ein nur wenige Minuten öffentlich sichtbarer Schlüssel sollte daher nicht als 'wahrscheinlich ungesehen' weiterverwendet werden.
Push Protection ist besser als nachträgliches Aufräumen
Secret Scanning ist reaktiv, wenn ein Schlüssel bereits committed wurde. Noch sinnvoller ist es, den Fehler vor dem Push zu stoppen. GitHub bietet dafür Push Protection. Erkennt das System ein unterstütztes Secret beim Push, kann der Vorgang blockiert oder ein bewusster Bypass verlangt werden. Für Entwickler ist das deutlich angenehmer, als später Keys zu rotieren und mögliche Zugriffe zu untersuchen.
Öffentliche Repositories werden von GitHub automatisch auf unterstützte Secret-Muster geprüft. Für private und interne Organisations-Repositories hängt der Funktionsumfang vom eingesetzten GitHub-Plan und Secret Protection ab. Unternehmen sollten deshalb nicht einfach annehmen, dass jedes private Repository automatisch denselben Schutz besitzt.
Gerade Agenten-Workflows brauchen klare Secret-Regeln
Mit KI-Coding-Agenten wird Secret Management noch wichtiger. Agenten lesen Konfigurationsdateien, erzeugen Beispielcode, führen Shell-Befehle aus und verbinden Dienste miteinander. Wenn ein Workflow nicht sauber gestaltet ist, kann ein Credential unbeabsichtigt in generierten Code, Logs oder Commits übernommen werden. Das gilt unabhängig davon, ob ein Mensch oder ein Agent die Zeile geschrieben hat.
Ein robuster Workflow verwendet deshalb möglichst kurzlebige und minimal berechtigte Tokens, getrennte Development-Credentials und zentrale Secret Stores. `.env`-Dateien gehören in `.gitignore`, Beispielkonfigurationen enthalten nur Platzhalter und CI/CD-Systeme sollten Secrets über geschützte Variablen injizieren. Zusätzlich lohnt sich Push Protection auf Entwicklerkonten und Repositories.
Die neuen Detectoren von GitHub sind kein spektakuläres Feature, aber ein sehr praktisches. Gerade Tools wie Lovable, Supabase und Pydantic werden in schnellen Web- und KI-Projekten genutzt, in denen Geschwindigkeit oft vor Prozessreife kommt. Je früher die Plattform solche Zugangsdaten erkennt, desto kleiner wird das Zeitfenster für Missbrauch. Die eigentliche Aufgabe bleibt trotzdem beim Team: Secrets so zu behandeln, dass sie möglichst nie im Repository landen.