Der Schutz von Secrets muss mit der Software skalieren

Heute betrifft jede dritte Pull Request auf GitHub einen KI-Agenten. Vor einem Jahr lag diese Zahl bei weniger als einer von 10. Wenn dieses Tempo anhält, könnte innerhalb der nächsten zwei Jahre der Großteil des auf GitHub gepushten Codes von einem Agenten geschrieben sein. Vieles davon wird möglicherweise nie vollständig von einem Menschen gelesen.

Wenn Entwickler und Agenten sich schneller bewegen, haben wir die Verantwortung sicherzustellen, dass der Schutz mit der beschleunigten Rate der Codeerstellung Schritt hält. Das bedeutet, mehr Lecks zu verhindern, bevor sie entstehen, und die Reaktion auf verbleibende Offenlegungen weniger von manueller menschlicher Arbeit abhängig zu machen.

Dies ist ein entscheidender Punkt für durchgesickerte Secrets. Entwickler werden nicht nachlässiger; sie werden überholt. Die Tools, mit denen Entwickler mehr Software erstellen können, sollten auch mehr Arbeit bei deren Schutz übernehmen.

In diesem Aufsatz teile ich die Daten aus neun Quartalen, die dieser Aussage zugrunde liegen. Ich stelle auch den feinabgestimmten Klassifikator vor, den wir mit Microsoft Applied Sciences gebaut haben, um Push Protection auf unstrukturierte Secrets auszuweiten. Das Modell bewertet einen ganzen Satz von Kandidaten-Secrets in weniger als zwei Millisekunden und könnte die Anzahl der Secrets, die wir verhindern können, mehr als verdoppeln.

Überholt, nicht nachlässig

Etwa alle zwei Sekunden erscheint ein neues Secret in öffentlich sichtbarem Code, was sich in den vergangenen drei Jahren jährlich verdoppelt hat. Die öffentliche Diskussion springt schnell zu der Vorstellung, dass KI die Entwickler nachlässig gemacht hat.

Zwischen Q2 2024 und Q2 2026 wuchsen die geprüften Pushes um das 2.84-fache , während Pushes mit Zugangsdaten um das 2.59-fachewuchsen. Über neun vollständige Quartale von Daten fanden wir keinen statistisch nachweisbaren Trend hinsichtlich der Prävalenz pro Push. Gleichzeitig fanden wir Daten, die darauf hindeuten, dass Entwickler mehr denn je das Risiko versehentlicher Offenlegungen verstehen und weniger bereit sind, dieses Risiko zu akzeptieren. Im selben Zeitraum sank der Anteil der von Entwicklern übersteuerten Push-Blockierungen linear von 6.63% auf 3.93%. Diese Zahlen widerlegen die verbreitete Behauptung, dass Agenten Entwickler nachlässiger machen.

Bei konstanter Rate verdoppelt eine verdoppelte Aktivität die erwarteten Offenlegungen. Wenn jede Offenlegung dieselbe menschliche Reaktion erfordert, verdoppelt sich auch die Arbeitslast. Die mittlere Zeit zum manuellen Widerrufen eines Secrets liegt bei etwa 40 Tagen; ungefähr jeder Fünfte dauerte mehr als 90 Tage. Wir beschleunigen die Erstellung von Software, während offen gelegte Zugangsdaten wochen- oder monatelang nutzbar bleiben können, da menschliche Behebung nicht im gleichen Tempo wie die Entwicklung skalieren kann.

Entwicklern zu sagen, sie sollen vorsichtiger sein, kann allein dieses Problem nicht lösen. Wenn die Menge an Code wächst, müssen wir mehr Offenlegungen verhindern und den menschlichen Aufwand für die verbleibenden reduzieren, wenn Softwareentwicklung nachhaltig bleiben soll.

Prävention skaliert mit Rechenleistung

Ich habe die letzten Jahre an Secret Scanning bei GitHub gearbeitet und das vergangene Jahr als Product Lead für diesen Bereich. Unser größter Impact kam daher, die Punkte zwischen Erkennung und Systemen zu verbinden, die handeln können.

GitHubs Katalog umfasst mehr als 150 technische Partner durch unser Secret-Scanning-Partnerschaftsprogramm. Durch unser Partnerprogramm arbeiten wir mit teilnehmenden Secret-Herausgebern zusammen, um Detektoren auszubauen und öffentliche Offenlegungen zu melden, damit diese reagieren können. Im Q2 2026 meldete das öffentliche Scanning im Durchschnitt erfolgreich 26 Zugangsdaten-Treffer pro Sekunde, einschließlich wiederholter Beobachtungen. Nach Benachrichtigung widerrufen viele dieser Partner sofort das Token: OpenAI API-Schlüssel, Google Cloud-Kontozugangsdaten, Slack-Webhooks, Hugging Face-Benutzertokens, SendGrid-Schlüssel usw. Der Eigentümer muss das Token möglicherweise noch ersetzen, aber der Widerruf kann geschehen, ohne auf einen Entwickler zu warten, der eine GitHub-Warnung findet und bearbeitet.

Push Protection greift früher ein. Es stoppt erkennbare Zugangsdaten, bevor sie in den Repository-Verlauf gelangen, und gibt dem Entwickler oder Agenten die Möglichkeit, die Änderung zu korrigieren, bevor es eine Offenlegung zu untersuchen gibt. Wir arbeiten mit unseren technischen Partnern zusammen, um die Präzisionsraten ihrer Detektoren so weit wie möglich zu erhöhen, bis wir sicher genug sind, diese Secrets standardmäßig für die Entwickler-Community per Push zu schützen.

Dank der Bemühungen unserer Partner wurde im vergangenen Monat mindestens einmal pro Sekunde ein Geheimnis durch den Push-Schutz blockiert. Bei issuer-gebundenen Zugangsdaten blockiert GitHub mehr Geheimnisse, als durchrutschen. Ich bin stolz darauf, wie selbstverständlich wir das für Entwickler gemacht haben.

Behebung skaliert mit Menschen

Unter Einbeziehung zusätzlicher Geheimnistypen stoppt der Push-Schutz etwa 30% der neu erkannten Geheimnisse, bevor sie in den Repository-Verlauf gelangen. Die übrigen 70% finden wir erst, nachdem die Zugangsdaten leider bereits verloren sind. Und:

1. Prävention skaliert mit Rechenleistung, aber Behebung skaliert weiterhin mit Menschen.
2. Das Zurückweisen eines Pushs kostet Rechenleistung; das Bereinigen eines bereits im sichtbaren Verlauf verlorenen Geheimnisses kostet die Zeit und Aufmerksamkeit eines Entwicklers.
3. Da die Menge an Code wächst, müssen wir mehr Offenlegungen verhindern und den menschlichen Aufwand für die verbleibenden reduzieren, sonst wird das Volumen der eingeführten Schwachstellen untragbar.

Entwicklern zu sagen, dass sie vorsichtiger sein sollen, kann dieses Ungleichgewicht nicht lösen. Mehr dieser Geheimnisse zu erkennen, und zwar früher im Entwicklungsprozess, ist eine Aufgabe, die die Plattform übernehmen muss.

Lösung des Vierkörperproblems

Bevor ein Geheimnis die Push-Grenze überschreitet, sind die Kosten für dessen Stopp gering, und die Entscheidung ist binär: blockieren oder zulassen. Nach dem Überschreiten kann sich dieselbe Zeichenkette an einem echten System authentifizieren, und die Kosten sind unbegrenzt.

In vielen Fällen kann unser einziger Hinweis zur Erkennung der umgebende Code und der Weltkontext sein. Ein von einem Provider ausgestelltes Token kann ein erkennbares Präfix haben. Ein internes Datenbankpasswort kann vollkommen unstrukturiert sein, ohne jedes identifizierende Muster. Wir nutzten den Kontext bereits, um diese Geheimnisse nach dem Push zu finden; das Problem bestand darin, diese kontextbewusste Beurteilung mit anderen Faktoren in Einklang zu bringen.

Wir bezeichnen dies als das „Vier-Körper-Problem“ des Geheimschutzes: Präzision, Latenz, Durchsatz und Kosten „sind gekoppelte Randbedingungen. Prävention muss die Zeit eines Entwicklers wert sein. Ein Befund, der sich für eine spätere Überprüfung eignet, rechtfertigt möglicherweise nicht das Blockieren eines Push. Ein Fehlalarm unterbricht einen Entwickler und macht den nächsten Block schwerer vertrauenswürdig. Eine Prüfung, die zu langsam, teuer oder schwer zu skalieren ist, begrenzt, wie oft sie ausgeführt werden kann."

Schutz auf Knopfdruck in unter 2 ms

Unser neuer ModernBERT-Klassifikator bewertet Kandidaten-Geheimnisse im Kontext, ohne Code oder Text zu generieren. Er ist nicht nur präziser als bestehende LLM-basierte Pipelines, sondern auch unglaublich schnell und wertet Kandidaten-Batches in unter zwei Millisekunden aus. Zudem ist er äußerst kosteneffizient – genug, um im großen Maßstab im kritischen Pfad betrieben zu werden.

Die Aufnahme unseres Modells in den Push-Schutz ermöglicht es uns, die Anzahl der Geheimnisse, die wir verhindern können, mehr als zu verdoppeln. Die Funktion befindet sich derzeit in privater Vorschau. Später in diesem Monat wird die Funktion für Organisationen mit GitHub Secret Protection über Enterprise Cloud und GitHub Teams verfügbar sein. Sie verbraucht AI-Credits.

Wir bringen das Modell auch auf Entwickleroberflächen, die über den Push hinausgehen.

• Ab heute kann jeder Organisation mit KI-Geheimniserkennung will be automatisch aktualisiert auf das neue Modell. Warnungen, die aus diesen Post-Push-Scans geöffnet werden, bleiben weiterhin in dem Kauf von Secret Scanning einer Organisation enthalten, ohne zusätzliche Kosten.
• Die Das Modell wird auch mit GitHub Enterprise Server 3.23 ausgeliefert in der öffentlichen Vorschau„…und bringt KI-erkannte Warnungen auch in air-gapped Umgebungen zu Secret-Protection-Kunden.“
• Wir das Hinzufügen des Klassifikators zur /security-review Befehl für die Copilot CLI und Copilot App, damit Copilot-Nutzer Geheimnisse noch vor einem Push beheben können, ohne dass die Organisation über einen GitHub Secret Protection-Tarif verfügen muss. Die Nutzung von AI Credits wird in Ihren AI-Nutzungseinblicken GitHub Secret Protection zugerechnet.

Ausblick

Die Zukunft, die wir uns wünschen, ist eine, in der Entwickler Agenten mehr Arbeit anvertrauen können, ohne jede Anfrage überwachen zu müssen, und eine, in der die Zahl der Personen, die eine Organisation zur Sicherung ihrer Zugangsdaten benötigt, nicht mehr mit der Menge des geschriebenen Codes skaliert. Wir schulden der Entwickler-Community denselben Fortschritt beim Schutz von Software, den wir bei deren Erstellung liefern.

Wir wollen, dass Menschen mehr Software entwickeln. Unsere Fähigkeit, sie zu schützen, sollte mit unserer Fähigkeit, sie zu erschaffen, wachsen.

Der Beitrag Geheimnisschutz muss mit der Software skalieren erschien zuerst auf The GitHub Blog.