LGR Reutlingen – 15 Juni 2026 | GitHub hat kürzlich seinen Verifizierungsschritt für das Secret Scanning um eine kontextbasierte LLM-Analyse erweitert. Das Resultat dieser Innovation ist beeindruckend: Dreiviertel der Fehlalarme entfallen, ohne dass dabei die Erkennungsrate leidet. Diese Entwicklung könnte für viele Entwickler eine spürbare Entlastung in ihrem Arbeitsalltag darstellen.
Das Secret Scanning von GitHub hat die entscheidende Aufgabe, offengelegte Zugangsdaten in Code-Repositories frühzeitig zu identifizieren. Wenn API-Schlüssel, Passwörter oder Tokens versehentlich in einen Commit gelangen, kann das Tool rechtzeitig eingreifen, bevor ernsthafte Sicherheitsvorfälle entstehen. Täglich verarbeitet dieses System Milliarden von Push-Vorgängen und schützt Entwickler in Millionen von Projekten weltweit.
Doch die schiere Größe dieser Infrastruktur hat ihre Schattenseiten. Selbst eine geringe Rate an Fehlalarmen kann in der Summe zu erheblichen Reibungsverlusten führen. Entwickler, die täglich mit einer Vielzahl von Warnmeldungen konfrontiert sind, von denen viele irrelevant sind, beginnen, das System nicht mehr als verlässlichen Hinweisgeber zu sehen, sondern als Quelle von Störsignalen. Dies führt dazu, dass die Bereitschaft, auf Meldungen sofort zu reagieren, abnimmt. Echte Sicherheitsbedrohungen werden dadurch möglicherweise zu spät erkannt oder behoben, was das Vertrauen in das Tool schrittweise untergräbt.
Wie das bestehende System funktioniert
Das Secret Scanning von GitHub kombiniert zwei grundlegende Erkennungsansätze. Die musterbasierte Erkennung nutzt einen Katalog bekannter Formate: Tokens und API-Schlüssel von Anbietern wie Cloud-Providern oder Zahlungsdienstleistern hinterlassen charakteristische Zeichenfolgen, die sich zuverlässig identifizieren lassen. GitHub gibt an, dass es in dieser Kategorie bereits ein branchenführendes Präzisionsniveau erreicht hat.
Zusätzlich kommt eine KI-gestützte generische Erkennung zum Einsatz. Diese zweite Ebene erfasst unstrukturierte Zugangsdaten – Passwörter und andere sensible Werte, die keinem spezifischen Anbietermuster entsprechen. Gerade weil solche Werte keine vorhersehbare Form haben, ist die Unterscheidung zwischen einem echten Geheimnis und einem harmlosen, aber ähnlich aussehenden Wert deutlich herausfordernder. Hier setzt der wesentliche Ansatzpunkt für die jüngste Weiterentwicklung an.
Ein einfacher Musterabgleich kann zwar erkennen, ob ein Wert wie ein Geheimnis aussieht, doch er kann nicht beurteilen, ob dieser Wert im Code tatsächlich als Geheimnis verwendet wird. Beispielsweise kann eine zufällig generierte UUID, ein hartcodierter Platzhalter in einer Testdatei oder eine leere Konfigurationsvariable formal einem API-Schlüssel ähneln, ohne dass eine reale Gefährdung besteht. Diese Fälle führen oft zu Fehlalarmen und belasten die tägliche Bearbeitung.
Kontextbasierte Verifizierung durch LLM-Analyse
Um diese Lücke zu schließen, war es notwendig, mehr als nur syntaktisches Musterwissen zu nutzen. Es bedurfte eines Verständnisses dafür, in welchem Kontext ein Wert im Code auftaucht und ob dieser Kontext darauf hindeutet, dass der Wert operativ verwendet wird. In Zusammenarbeit mit dem „Agents Offense“-Team von Microsoft Security & AI wurde der Verifizierungsschritt gezielt erweitert. Grundlage dieser neuen Methode ist der „Agentic Secret Finder“, ein System, das nicht nur prüft, ob ein Wert einem Geheimnis-Muster entspricht, sondern auch analysiert, wie er im umgebenden Code eingesetzt wird.
Das zentrale Designprinzip bestand darin, nicht mehr Code in die Analyse einzubeziehen, sondern die relevanten Signale gezielt zu extrahieren. Entscheidend ist, ob ein Wert einer Variablen zugewiesen wird und anschließend an eine API-Anfrage, einen Authentifizierungsheader oder einen Cloud-SDK-Aufruf übergeben wird. Diese Nutzungsmuster sind Indikatoren für ein echtes Geheimnis.
Anstatt ganze Dateien oder Repositories an das Sprachmodell zu übergeben, extrahiert das System eine kompakte Menge aussagekräftiger Nutzungsinformationen auf Dateiebene. Dies hält sowohl die Verarbeitungslatenz als auch die Kosten niedrig und macht den Betrieb in der für GitHub typischen Größenordnung praktikabel. Werte, die Platzhaltern, Testdaten oder ungenutzten Konfigurationsfeldern ähneln, können auf dieser Ebene häufig bereits herausgefiltert werden, ohne dass eine tiefere Analyse des gesamten Repositories notwendig ist.
Wenn der Kontext innerhalb einer einzelnen Datei ausreicht, um eine Einschätzung zu treffen, wird keine weitere Eskalation vorgenommen. Auf diese Weise liefert das System präzisere Ergebnisse, ohne den Ressourcenaufwand unverhältnismäßig zu steigern.
Die Erweiterung greift direkt in den Verifizierungsschritt ein, der den Erkennungskandidaten nachgelagert ist. Die Erkennung selbst – sowohl die musterbasierte als auch die KI-gestützte – bleibt unverändert und liefert weiterhin die Ausgangsmenge potenzieller Funde. Der neue Kontextschritt bewertet diese Kandidaten anschließend mit einem stärkeren Fokus auf die tatsächliche Verwendung im Code. Durch diese Architektur lässt sich die Präzision verbessern, ohne die Abdeckung zu reduzieren: Echte Geheimnisse werden weiterhin erkannt, während Störsignale herausgefiltert werden.
Der Ansatz wurde anhand von Hunderten durch Kunden bestätigter Fehlalarme evaluiert. Das definierte Ziel war eine Reduktion um 65 Prozent, doch der tatsächlich erzielte Wert lag bei 75,76 Prozent – und damit deutlich über der Zielmarke. Die Erkennungsrate für echte Geheimnisse blieb stabil, was für die praktische Arbeit im Entwickleralltag eine spürbare Entlastung bedeutet: Ein deutlich höherer Anteil der angezeigten Warnungen ist handlungsrelevant. Die Zeit, die für die Sichtung und Einstufung nicht relevanter Meldungen aufgewendet werden muss, sinkt erheblich. Wer weniger Rauschen verarbeiten muss, kann sich schneller den Funden zuwenden, die tatsächlich Aufmerksamkeit erfordern – und das Vertrauen in das System wächst, weil die Meldungen verlässlicher werden.
Die Arbeit an diesem Ansatz ist jedoch noch nicht abgeschlossen. Das Team evaluiert den Ansatz weiterhin anhand größerer Datensätze und echtem Live-Traffic. Parallel dazu wird die Methodik zur Kontextextraktion weiter verfeinert. Fragen wie: Welche Signale aus dem Code sind besonders aussagekräftig? Wie lassen sich diese effizient und skalierbar bereitstellen? treiben die Weiterentwicklung voran.
Das übergeordnete Ziel bleibt konstant: Die Warnmeldungen sollen so verlässlich und eindeutig sein, dass Entwickler beim Lesen einer Meldung sofort einschätzen können, ob Handlungsbedarf besteht – ohne aufwendige manuelle Nachrecherche. Weniger Ablenkung, klarere Signale und schnelleres Handeln bei tatsächlichen Risiken sind die wesentlichen Ziele dieser Neuerung.
