Open Source ist keine Sicherheitsgrenze

Am 14. Mai 2026 veröffentlichte der britische Government Digital Service Leitlinien zu KI, offenem Code und Schwachstellenrisiken im öffentlichen Sektor. Sie beantworten die richtige Frage: KI kann Schwachstellensuche günstiger machen, doch die Vertraulichkeit eines Repositorys wird dadurch trotzdem nicht zur Sicherheitsgrenze.¹

Neun Tage zuvor berichtete ein öffentlicher Artikel, NHS England plane, Hunderte von GitHub-Repositorys privat zu stellen, nachdem intern die Sorge aufgekommen war, KI-gestützte Schwachstellentools könnten öffentlichen Code in großem Maßstab prüfen.² Die Sorge ist nachvollziehbar. Die vorgeschlagene Kontrolle ist es nicht. Wer Code verbirgt, behandelt Auffindbarkeit als Bedrohung. Ernsthafte Sicherheitsarbeit behandelt nicht behobene Schwächen als Bedrohung.

Open-Source-Sicherheit wird besser, wenn Teams die tatsächliche Angriffsfläche reduzieren: keine Geheimnisse im Code, klare Ausnahmen, verantwortete Repositorys, funktionierende Meldewege, schnelle Patches und öffentliche Belege dafür, dass Korrekturen bei Benutzern angekommen sind. Die Vertraulichkeit eines Repositorys kann eine konkrete Ausnahme stützen, ersetzt aber nicht dieses Betriebssystem aus Verantwortlichkeit, Behebung und Nachweis.

Kurzfassung

GDS sagt, Teams im öffentlichen Sektor sollten Code standardmäßig offen halten, Ausnahmen bewusst prüfen und sich auf die praktischen Faktoren konzentrieren, die das reale Risiko verändern.¹ Diese Antwort ist besser als eine Panikreaktion rund um private Repositorys, denn öffentlicher Code kann bereits in Forks, Spiegelungen, Caches, Paketartefakten, Container-Images, Screenshots, generierten Clients und früheren Klonen existieren. Wichtiger noch: Öffentlicher Code ermöglicht mehr Menschen, ihn zu prüfen, wiederzuverwenden, Probleme zu melden und ihn zu verbessern.¹³

Die richtige Reaktion auf KI-gestützte Schwachstellensuche lautet nicht: „Alles privat machen.“ Sie lautet: Geheimnisse entfernen, sensiblen Code klassifizieren, klare Ausnahmen veröffentlichen, Abhängigkeits- und Geheimnisscans ausführen, einen Meldeweg für Schwachstellen pflegen, schnell patchen und Belege dafür aufbewahren, dass der offene Code eine verantwortliche Stelle hat.¹⁴⁵

Wichtigste Erkenntnisse

• Für Engineering-Führungskräfte: Vertraulichkeit kann in engen Fällen die Sichtbarkeit verringern, ersetzt aber keine Verantwortlichkeit, Bestandsaufnahme, Patches und Offenlegung.
• Für Teams im öffentlichen Sektor: Standardmäßig offen funktioniert weiterhin, wenn Teams ausdrückliche Ausnahmen für Geheimnisse, Betrugskontrollen, sensible Architektur und unveröffentlichte Richtlinien vorsehen.
• Für Sicherheitsteams: KI erhöht den Wert von Reaktionsfähigkeit. Ein privates Repository ohne Triage-Pfad scheitert trotzdem.
• Für Agententeams: Codesichtbarkeit ist nur eine Angriffsfläche. Tool-Berechtigungen, Zustandsgrenzen, Kontrollen für ausgehenden Datenverkehr und Freigabeschwellen sind wichtiger als die Frage, ob ein Repository privat aussieht.
• Für Maintainer: Veröffentlichen Sie weniger Rätsel. Gute Dokumentation, klare Sicherheitskontakte und kleine, gut verantwortete Dienste reduzieren Risiken stärker als eine Wand aus privaten Repositorys.

Die Panik verwechselt Sichtbarkeit mit Verwundbarkeit

KI-Schwachstellenscanner verändern die Wirtschaftlichkeit der Codeprüfung. Früher brauchte eine Person Zeit, Können und Geduld, um eine Codebasis zu durchsuchen. Ein leistungsfähiges Modell kann mehr Code schneller prüfen, Hinweise über Dateien hinweg verbinden und mehr potenzielle Befunde erzeugen. Dieser Wandel erhöht den Druck auf Teams, die ohnehin brüchigen Code, unklare Zuständigkeiten und langsame Patchwege hatten.

Repository-Sichtbarkeit ist trotzdem nicht dasselbe wie Verwundbarkeit. Öffentlicher Code kann einen Fehler sichtbar machen. Privater Code kann denselben Fehler enthalten. Angreifer können Verhalten oft aus Binärdateien, API-Traffic, Client-Bundles, Paketinhalten, Container-Layern, Logs, Dokumentation, Abhängigkeitsmetadaten oder einem alten Klon ableiten. GDS macht denselben praktischen Punkt: Ein zuvor öffentliches Repository privat zu stellen, entfernt für fähige Gegner nicht zwangsläufig den Zugriff, weil populäre Projekte oft Forks oder Spiegelungen haben und selbst wenig bekannte Repositorys bereits bei Forschern oder Angreifern gelandet sein können.¹

Diese Einschränkung ist wichtig, weil „zumachen“ wie Handeln wirkt. Die Maßnahme kann öffentliche Rechenschaft verringern, während die technische Schwäche bestehen bleibt. Teams verlieren externe Prüfung, gemeinsame Korrekturen und Wiederverwendung, gewinnen aber wenig Schutz gegen alle, die den Code bereits kopiert haben.

Open Source schafft außerdem eine Prüfspur. Öffentliche Historie zeigt, wer was geändert hat, wann eine Korrektur gelandet ist, wie Maintainer auf eine Meldung reagiert haben und ob ein Projekt noch aktiv betreut wird. Privater Code verbirgt diese Signale vor Peer-Teams, Lieferanten, Forschern und anderen öffentlichen Stellen, die die Arbeit vielleicht wiederverwenden oder verbessern könnten.

Standardmäßig offen ist nicht naiv

GDS behauptet nicht, dass jede Codezeile ins öffentliche Internet gehört. Die ältere Open-Source-Leitlinie von GOV.UK nennt bereits legitime Gründe, Code geschlossen zu halten, darunter Schlüssel, Zugangsdaten, Betrugserkennungsalgorithmen und unveröffentlichte Richtlinien.³ Auch der Technology Code of Practice verbindet Offenheit mit Sicherheits- und Datenschutzpflichten, nicht mit deren Gegenteil.⁴

Die stärkere Regel lautet: standardmäßig offen, mit konkreten Ausnahmen. Diese Form zwingt ein Team, das Risiko zu benennen, statt „Sicherheit“ als Sammelkategorie zu verwenden. Ein Geheimnis gehört nicht in ein Repository. Ein Betrugssignal kann eingeschränkte Sichtbarkeit brauchen. Ein Dienst für unveröffentlichte Richtlinien kann eine befristete Sperre brauchen. Eine Codebasis, die lediglich peinlich wirkt, qualifiziert sich nicht.

Das Playbook des britischen öffentlichen Sektors weist in dieselbe Richtung. Es beschreibt die Erwartung, dass Regierungssoftware und Code standardmäßig Open Source sein, offen entwickelt und, wo angemessen, unter einer genehmigten Lizenz veröffentlicht werden sollten.⁵ Die Open-Source-Codeveröffentlichungsrichtlinie des DWP folgt demselben Muster: Veröffentlichung unter offenen Lizenzen fördern und zugleich sensiblen Quellcode durch definierte Kontrollen schützen.⁶

Diese Unterscheidung schützt Qualität. Teams, die offen entwickeln, schreiben tendenziell bessere READMEs, sauberere Setup-Anleitungen, klarere Issue-Historien und ausdrücklichere Datengrenzen, weil Außenstehende die Arbeit lesen können. Die GOV.UK-Leitlinie sagt, dass veröffentlichter Code Dokumentation, Wartbarkeit, Datenklarheit und Sicherheitsfeedback verbessern kann.³ Diese Vorteile verschwinden, wenn ein Team auf KI-Druck reagiert, indem es alles vergräbt.

Die eigentliche Kontrolle ist Behebungsgeschwindigkeit

KI verändert die Uhr. Auffindbarkeit wird schneller. Das Meldevolumen steigt. Falsch positive Befunde nehmen ebenfalls zu. Über denselben Fähigkeitsdruck habe ich in Wenn Ihr Agent eine Schwachstelle findet geschrieben: Auffindbarkeit bedeutet wenig ohne Prüfung und Reparatur. Teams brauchen Triage, Weiterleitung an Verantwortliche, Patching, Offenlegung und Freigabebelege. Die Vertraulichkeit eines Repositorys liefert nichts davon.

Die Vulnerability Disclosure Policy Platform von CISA existiert aus genau diesem Grund. Sie gibt zivilen Bundesbehörden einen Kanal, um Schwachstellen entgegenzunehmen, zu triagieren und weiterzuleiten, die öffentliche Sicherheitsforscher melden.⁷ Das koordinierte Schwachstellenoffenlegungsprogramm von CISA deckt außerdem Schwachstellen in kritischer Infrastruktur ab, einschließlich Open-Source-Software und KI-Systemen, und betont die Koordination von Minderungsmaßnahmen vor öffentlicher Offenlegung.⁸

NCSC gibt britischen Organisationen denselben operativen Rahmen durch Leitlinien zu Schwachstellenmeldung und Offenlegung, einschließlich eines Toolkits und eines fertigen Wegs für Regierungsabteilungen.⁹ Der gemeinsame Kern ist einfach: Akzeptieren Sie, dass Außenstehende Fehler finden werden, und sorgen Sie dann dafür, dass Meldung und Behebung funktionieren.

So wird KI-gestützte Schwachstellensuche vom Grund zum Verstecken zum Grund, die Reaktionsschleife zu verbessern. Wenn ein Modell in Ihrem öffentlichen Code einen Fehler finden kann, sollte das Team 5 Fragen stellen:

Diese Antworten senken das Risiko, egal ob der Code offen oder geschlossen ist. Das Repository zu verbergen ändert nur, wer den Quellcode heute sehen kann. Es schafft keinen Verantwortlichen, keinen Patch und keinen Offenlegungsweg.

Eine bessere Entscheidungsregel

Teams brauchen eine Entscheidungsregel, die Peinlichkeit, Sichtbarkeit und echte Sensibilität trennt.

Die Regel verhindert auch ein häufiges Scheitern: alles zu schließen, weil das Team nichts klassifizieren kann. Eine Repository-Bestandsaufnahme sollte beantworten, was der Dienst tut, welche Daten er berührt, wer ihn verantwortet, welche Geheimnisscanner laufen, welche Abhängigkeiten wichtig sind und wie Meldungen die Maintainer erreichen. Fehlen diese Antworten, hat das Team eine operative Lücke. Eine Änderung der Repository-Sichtbarkeit kann diese Lücke vor der Öffentlichkeit verbergen, aber sie bleibt bestehen.

Agenten vergrößern das Grenzproblem

KI-Coding-Agenten schärfen dieselbe Lehre. Eine Repository-Grenze hindert einen Agenten nicht daran, innerhalb erlaubter Berechtigungen eine unsichere Entscheidung zu treffen. Über dieses Muster habe ich in Agenten-Sandbox-Sicherheit ist nur ein Vorschlag geschrieben: Die gefährlichen Aktionen passieren oft innerhalb der Berechtigungsmenge, nicht außerhalb. Dasselbe Zusammensetzungsproblem treibt Software-Lieferkettenangriffe, bei denen einzeln vernünftige Teile zusammen einen schädlichen Pfad ergeben.

Das Problem des unsichtbaren Agenten gilt auch für Open-Source-Richtlinien. Teams können nicht steuern, was sie nicht sehen: Tool-Pfade, generierte Artefakte, Caches, Freigabestatus, Offenlegungswarteschlangen und Übergaben zwischen Verantwortlichen zählen alle.

Open-Source-Richtlinien sollten von Agentensicherheit lernen. Die nützlichen Grenzen liegen auf der Handlungs- und Reaktionsebene:

• nicht vertrauenswürdige Eingaben klassifizieren, bevor Tools sie berühren;
• Geheimnisse aus Code, Historie, Logs, Paketen und generierten Assets entfernen;
• Build-Caches und Release-Artefakte nach Vertrauensstufe trennen;
• ausgehende Netzwerkpfade für automatisierte Arbeitsabläufe einschränken;
• Belege verlangen, bevor veröffentlicht, bereitgestellt oder eine Korrektur als abgeschlossen erklärt wird;
• externen Forschern einen sicheren, dokumentierten Meldeweg geben.

Diese Kontrollen hängen nicht von Quellcode-Geheimhaltung ab. Sie hängen davon ab, dass Teams wissen, wo sensibles Material liegt und welche Aktionen Schaden verursachen können. Wenn ein Repository ein echtes Geheimnis enthält, löst Privatisierung nach der Offenlegung das falsche Problem. Rotieren Sie das Geheimnis, entfernen Sie es nach Möglichkeit aus der Historie, invalidieren Sie alte Artefakte und dokumentieren Sie den Vorfallpfad. Die Veröffentlichungsgrenze ist wichtig, weil externe Ausgaben eine stärkere Schwelle brauchen als lokale Analyse.

Deshalb wirkt die GDS-Leitlinie richtig. Sie bestreitet nicht, dass KI die Schwachstellensuche verändert. Sie verweigert nur den oberflächlichen Schluss. KI macht schwache Systeme leichter prüfbar, also sollte die Antwort Systeme leichter verantwortbar, prüfbar, meldbar und reparierbar machen.

Was ich heute tun würde

Ein Team, das wegen KI-getriebener Repository-Panik unter Druck steht, sollte vor einer Änderung der Standards eine 48-stündige Prüfung offenen Codes durchführen:

1. Öffentliche Repositorys inventarisieren und jedem eine verantwortliche Stelle zuordnen.
2. Geheimnisscans gegen den aktuellen Stand und die Git-Historie ausführen.
3. Prüfen, ob jedes Repository einen Sicherheitskontakt oder eine Offenlegungsrichtlinie hat.
4. Ausnahmen für Betrug, Missbrauch, Live-Architektur und unveröffentlichte Richtlinien identifizieren.
5. Wege für Abhängigkeitsupdates, Patch-Releases und Rollbacks bestätigen.
6. Nur die konkreten Repositorys schließen oder verzögern, die zu einer benannten Ausnahme passen.
7. Die Entscheidungsregel veröffentlichen, damit künftige Teams die Panik nicht wiederholen.

Dieser Plan gibt Führungskräften eine echte Kontrollfläche. Außerdem erzeugt er Belege. Ein späterer Prüfer kann sehen, warum ein Repository offen blieb, warum ein anderes privat wurde und welche Arbeit das tatsächliche Risiko reduziert hat.

FAQ

Macht KI öffentlichen Code gefährlicher?

KI kann öffentlichen Code leichter prüfbar machen. Teams sollten deshalb mit mehr Schwachstellenmeldungen und mehr automatisierter Sondierung rechnen. Die Gefahr entsteht durch nicht behobene Schwachstellen, offengelegte Geheimnisse und schwache Reaktionsschleifen. Öffentliche Sichtbarkeit kann Auffindbarkeit erhöhen, aber Vertraulichkeit entfernt den zugrunde liegenden Fehler nicht.¹

Sollten Teams Repositorys jemals privat machen?

Ja. Teams sollten Code einschränken, der Geheimnisse, Betrugskontrollen, sensible Live-Architektur, unveröffentlichte Richtlinien oder andere konkrete Schäden enthält oder offenlegt. Sie sollten die Ausnahme dokumentieren und sie erneut prüfen, wenn der Grund abläuft.³⁶

Warum nicht alles schließen, bis das Team eine Prüfung abgeschlossen hat?

Pauschales Schließen tauscht reale öffentliche Vorteile gegen unsicheren Schutz. GDS warnt, dass zuvor öffentlicher Code bereits in Spiegelungen, Forks oder geklonten Kopien existieren kann.¹ Eine kurze, gezielte Prüfung ist besser als ein unbefristeter Standard, der Zuständigkeitsprobleme versteckt.

Was sollte ein öffentliches Repository enthalten, bevor ein Team es als sicher genug bezeichnet?

Mindestens: keine Geheimnisse, eine verantwortliche Stelle, eine Lizenz, klare Setup-Hinweise, eine Praxis für Abhängigkeitsupdates, einen Sicherheitskontakt oder Meldeweg für Schwachstellen und einen Release-Prozess, der Korrekturen schnell ausliefern kann.

Wie hängt das mit KI-Coding-Agenten zusammen?

Agenten erweitern dasselbe Grenzproblem. Das Risiko sitzt selten in einer einzigen sichtbaren Datei. Es liegt in Berechtigungen, generierten Artefakten, Caches, ausgehenden Anfragen, Build-Zustand und Release-Befugnissen. Gute Agentensicherheit und gute Open-Source-Richtlinien brauchen beide Belege an diesen Grenzen.

Referenzen