CISA versucht, ein Datenleck einzudämmen

• Ein CISA-Auftragnehmer stellte Dutzende Klartext-Zugangsdaten interner Systeme in das öffentliche GitHub-Profil „Private-CISA“ und hinterließ zudem Spuren dafür, dass GitHub-Schutzfunktionen deaktiviert worden waren
• CISA räumte das Leck ein, beantwortete aber nicht, wie lange die Daten offengelegt waren; das Repository wurde im November 2025 erstellt und zeigte Nutzungsmuster wie ein persönliches Scratchpad
• Abgeordnete wie Maggie Hassan und Bennie Thompson stellten angesichts wachsender Bedrohungen für kritische Infrastrukturen Fragen zu CISA-internen Sicherheitsrichtlinien, dem Management von Auftragnehmern und der Sicherheitskultur
• Selbst eine Woche nach der Benachrichtigung durch GitGuardian lief der Austausch einiger Schlüssel noch; Dylan Ayrey von TruffleHog sagte, dass am 20. Mai noch ein RSA-Privatschlüssel aktiv gewesen sei
• Da sich der öffentliche GitHub-Event-Feed sowohl von Verteidigern als auch von Angreifern überwachen lässt, bleibt das Risiko bestehen, dass zusätzliche sensible Geheimnisse, die Ende April 2026 hinzugefügt wurden, bereits missbraucht wurden

---

CISA-Leak und Fragen aus dem Kongress

• Ein CISA-Auftragnehmer erstellte mit Administratorrechten für die Code-Entwicklungsplattform der Behörde ein öffentliches GitHub-Profil namens „Private-CISA“, das Dutzende Klartext-Zugangsdaten interner CISA-Systeme enthielt
• In den Commit-Logs fanden sich Spuren dafür, dass die integrierten GitHub-Schutzfunktionen, die das Veröffentlichen sensibler Zugangsdaten in öffentlichen Repositories verhindern sollen, deaktiviert worden waren
• CISA bestätigte das Leck, beantwortete aber nicht, wie lange die Daten offengelegt waren
• Experten, die ein Archiv des inzwischen verschwundenen Private-CISA überprüften, kamen zu dem Schluss, dass das Repository erstmals im November 2025 angelegt wurde und eher wie ein persönliches Arbeits-Scratchpad oder Synchronisierungsmittel als wie ein ordentlich gepflegtes Projekt-Repository genutzt wurde
• CISA erklärte in einer schriftlichen Stellungnahme: „Es gibt keine Hinweise darauf, dass infolge dieses Vorfalls sensible Daten kompromittiert wurden.“

Sorgen der Abgeordneten über die Sicherheitskultur

• Sen. Maggie Hassan erklärte in einem Schreiben vom 19. Mai an CISA Acting Director Nick Andersen, dass dieser Sicherheitsfehler bei einer Behörde, die helfen soll, Cyberangriffe zu verhindern, ernsthafte Fragen aufwerfe
• Hassan wies darauf hin, dass die Sorgen über CISA-interne Richtlinien und Verfahren gerade in einer Phase zunehmen, in der erhebliche Cyberbedrohungen gegen die kritische Infrastruktur der USA andauern
• Der Vorfall ereignete sich inmitten massiver interner Unruhe bei CISA; die Behörde verlor mehr als ein Drittel ihrer Belegschaft und fast alle Spitzenkräfte, nachdem die Trump-Regierung mehrere Stellen zu Frühverrentung, Buyouts und Kündigungen gedrängt hatte
• Rep. Bennie Thompson schrieb in einem Brief vom 19. Mai, der Vorfall könne auf eine geschwächte Sicherheitskultur oder mangelnde Fähigkeiten von CISA beim Management vertraglicher Unterstützung hindeuten
• Thompson und die Mitunterzeichnerin Rep. Delia Ramirez sehen in den Dateien des Private-CISA-Repositories Informationsquellen, Zugriffsmöglichkeiten und Roadmaps für feindliche Akteure wie China, Russland und Iran, die versuchen, Zugang zu Bundesnetzwerken zu erlangen und dort dauerhaft präsent zu bleiben

Die Zugangsdaten sind noch nicht vollständig ungültig gemacht

• Mehr als eine Woche nachdem das Sicherheitsunternehmen GitGuardian CISA erstmals über das Datenleck informiert hatte, war CISA noch immer dabei, zahlreiche offengelegte Schlüssel und Geheimnisse ungültig zu machen und auszutauschen
• Dylan Ayrey, Gründer von TruffleHog, erklärte, dass ein im Private-CISA-Repository offengelegter RSA-Privatschlüssel am 20. Mai noch nicht ungültig gemacht worden war
• Dieser RSA-Privatschlüssel gewährte Zugriff auf eine GitHub-App, die einem CISA-Enterprise-Konto gehörte und in der GitHub-Organisation CISA-IT installiert war; sie hatte vollständigen Zugriff auf sämtliche Code-Repositories
• Laut Ayrey hätte ein Angreifer mit diesem Schlüssel den Quellcode aller Repositories der CISA-IT-Organisation einschließlich privater Repositories lesen sowie einen bösartigen selbst gehosteten Runner registrieren können, um die CI/CD-Pipeline zu kapern und auf Repository-Geheimnisse zuzugreifen
• Ein Angreifer hätte außerdem Administrator-Einstellungen des Repositories einschließlich Branch-Protection-Regeln, Webhooks und Deploy Keys ändern können
• Nachdem KrebsOnSecurity CISA am 20. Mai über Ayreys Entdeckung informiert hatte, scheint CISA den betreffenden RSA-Privatschlüssel ungültig gemacht zu haben
• Ayrey sagte, CISA habe andere offengelegte Zugangsdaten, die mit weiteren zentralen Sicherheitstechnologien im gesamten Technologieportfolio der Behörde verknüpft seien, noch nicht ersetzt
• CISA antwortete: „Wir arbeiten aktiv mit den relevanten Parteien und Anbietern zusammen und koordinieren uns mit ihnen, um sicherzustellen, dass identifizierte offengelegte Zugangsdaten ersetzt und ungültig gemacht werden, und wir werden weiterhin geeignete Maßnahmen zum Schutz der Systemsicherheit ergreifen.“

Die zwei Seiten des öffentlichen GitHub-Event-Feeds

• Truffle Security überwacht offengelegte Schlüssel auf GitHub und verschiedenen anderen Code-Plattformen und versucht, betroffene Konten über sensible Datenoffenlegungen zu informieren
• GitHub stellt einen Echtzeit-Feed bereit, der alle Commits und Änderungsverläufe in öffentlichen Code-Repositories umfasst; diese Struktur macht die Erkennung von Offenlegungen möglich
• Ayrey sagte, dass auch Cyberkriminelle diesen öffentlichen Feed überwachen und schnell auf API-Schlüssel oder SSH-Schlüssel zielen, die versehentlich in Code-Commits veröffentlicht werden
• Im Private-CISA-GitHub-Repository waren Dutzende Klartext-Zugangsdaten für wichtige CISA-GovCloud-Ressourcen offengelegt
• Ayrey erklärte, es sei sehr wahrscheinlich, dass auch Cybercrime-Gruppen oder ausländische Gegner die Veröffentlichung von CISA-Geheimnissen gesehen hätten, und die schwerwiegendsten Offenlegungen scheinen Ende April 2026 erfolgt zu sein
• Das zentrale Restrisiko bleibt, dass „jeder, der GitHub-Events überwacht, über diese Informationen verfügen könnte“

Grenzen technischer Kontrollen

• James Wilson vom Sicherheits-Podcast Risky Business meinte, dass Organisationen, die Code-Projekte über GitHub verwalten, übergeordnete Richtlinien festlegen können, damit Mitarbeitende Schutzfunktionen gegen das Veröffentlichen geheimer Schlüssel und Zugangsdaten nicht deaktivieren können
• Co-Moderator Adam Boileau sagte, es sei unklar, welche Technik verhindern könne, dass Mitarbeitende persönliche GitHub-Konten eröffnen, um dort sensible und proprietäre Informationen zu speichern
• Boileau bezeichnete den Vorfall als ein menschliches Problem, das sich schwer allein durch technische Kontrollen lösen lasse
• Falls der Auftragnehmer GitHub genutzt habe, um Inhalte zwischen einem Arbeitsgerät und einem privaten Gerät zu synchronisieren, zeige sich die Grenze darin, dass CISA solches Verhalten außerhalb des eigenen Verwaltungs- und Sichtbarkeitsbereichs nur schwer verhindern könne
• In einem Update des Artikels wurde eine CISA-Stellungnahme ergänzt und ein Datumsfehler korrigiert: Truffle Security stellte klar, dass einige der sensibelsten Geheimnisse im Repository nicht 2025, sondern Ende April 2026 hinzugefügt wurden

[GN⁺]

Hacker-News-Kommentare

• Das ist wirklich ein absurder Fehler. „Das entspricht eher einem Muster, bei dem ein Repository als persönliches Arbeitsnotizbuch oder Synchronisierungsmittel genutzt wurde, als einem verwalteten Projektrepository“ — ist nicht eine der absoluten Git-Grundregeln, keine Zugangsdaten hineinzulegen? Ich habe keine Ahnung, welchem Muster das bitte entsprechen soll.

  • Diese Formulierung verteidigt es nicht als etablierte Arbeitsweise oder Best Practice.
    „Zeigt ein Muster, das mit ~ übereinstimmt“ beschreibt einfach nur, wie das Repository offenbar genutzt wurde. Also: kein internes Regierungsquellcode-Paket für ein Projekt und auch kein Hinweis darauf, dass ein massenhafter Datenabfluss beabsichtigt war.
  • Welchem Muster diese Nutzung entspricht, steht bereits klar da: Es wurde wie eine Art persönliches Arbeitsnotizbuch verwendet.
    Du liest in den Satz mehr hinein, als tatsächlich dort steht. Er beschreibt einfach nur eine Beobachtung.
  • Überhaupt kein Fehler. Die US-Regierung ist von ausländischen Geheimdiensten komplett unterwandert, und ich halte diesen „Vorfall“ für völlig beabsichtigt.
  • Wenn ich für jeden in ein öffentliches Repository eingecheckten geheimen Wert 1 Dollar bekommen hätte, könnte ich vermutlich in Rente gehen. Das entschuldigt es natürlich nicht. Aber so zu tun, als bestünde auch die US-Regierung nicht am Ende aus Leuten wie wir, ist ziemlich komisch.

• Mit kompetenteren technischen Kontrollen hätte man schon verhindern müssen, dass irgendein Contractor ein Passwort aus Mitte 2025 auf seinen Heimcomputer kopieren kann und dass dieses Passwort 5 Tage später — geschweige denn 30 — immer noch funktioniert.

  • Ja. Ehrlich gesagt dachte ich, der Staat würde schon seit Langem ziemlich ernsthaft Smartcards und HSMs für alles Mögliche einsetzen. Ich verstehe nicht, warum man überhaupt jemandem exportierbare Zugangsdaten gibt, statt einfach Hardware auszugeben, aus der sich die Credentials nicht herausziehen lassen.
    In manchen Organisationen wären die Zusatzkosten ein Thema, aber hier wohl kaum. Oder es ist ein weiteres Symptom des Verfalls, der entstand, nachdem die Republikaner im letzten Jahr genau die Projekte und Standards beschädigt haben, um die sich CISA eigentlich kümmern sollte. So oder so: Die Technik kann solche Vorfälle eindeutig reduzieren; das ist keine unvermeidbare Naturkatastrophe.
  • Ich arbeite zwar nicht mit Staatsgeheimnissen, habe aber Zugriff auf sensible oder wertvolle Kundendaten. Schon die Vorstellung, irgendetwas direkt auf mein Gerät herunterzuladen, ist für mich unverständlich.
    Selbst das Herunterladen von Logdateien mit "aws s3 cp s3://client/file - | less" finde ich nicht besonders gut. Ich würde viel lieber eine günstige Instanz hochfahren und die Daten innerhalb der VPC des Kunden anschauen.

• Wenn man eine Fachorganisation zusammenstreicht, ist es doch nur logisch, dass viele Fähigkeiten schwinden, darunter auch operative Sicherheitskompetenz.
  2020 widersprach Chris Krebs den Behauptungen über eine gestohlene Wahl. 2025 entließ Trump Krebs und entzog ihm die Sicherheitsfreigabe, sodass CISA ohne Leitung dastand. https://en.wikipedia.org/wiki/Chris_Krebs
  Im März 2025 begannen die Kürzungen. https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
  Auch 2026 gab es immer noch keine Leitung, und die Behörde operierte praktisch am Limit. https://techcrunch.com/2026/02/25/us-cybersecurity-agency-ci...
  Dieses Vorgehen passt dazu, die Verteidigung eines Landes absichtlich von innen heraus zu schwächen und Chaos zu stiften.

  • Wenn feindliche ausländische Akteure verantwortlich wären, würden wir überhaupt einen Unterschied bemerken?
  • Ehrlich gesagt passt das unmittelbarer zu aggressiver Inkompetenz und Einstellungen bzw. Entlassungen nach Loyalitätskriterien. Ich räume ein, dass die Frage, wie solche Idioten überhaupt Einstellungs- und Entlassungsbefugnisse bekommen haben, komplizierter ist.
  • Krebs wurde nicht 2025, sondern 2020 entlassen.

• CISA verlor mehr als ein Drittel ihrer Belegschaft und den Großteil ihrer Führungskräfte, nachdem die Trump-Regierung behördenübergreifend Frühruhestand, Buyouts und Rücktritte vorangetrieben hatte.

• Offenbar haben Senatoren CISA gefragt, warum die Behörde ihre Bemühungen zur Wahlsicherheit zurückfährt[1]. Auch der Zeitpunkt von Tulsis Rücktritt heute wirkt seltsam abgestimmt auf den Moment, in dem diese Sache öffentlich wurde.
  [1]https://www.padilla.senate.gov/newsroom/press-releases/padil...

  • Ich verstehe nicht, warum die US-Senatoren hier so ein Theater machen. Trump hat bei Vorlage seines Budgets sehr klar gesagt, dass er das CISA-Budget massiv kürzen will, und CISA auch direkt angewiesen, das Büro für Wahlsicherheit zu schließen.
    Das ist das „Who killed Hannibal“-Meme. Wenn Padilla und Warner das nicht wussten, sind sie selbst inkompetent. Zumal sie das letztes Jahr bereits in einer Pressemitteilung thematisiert hatten:
    https://www.padilla.senate.gov/newsroom/news-coverage/cnn-tr...
    Padilla, warum hast du vergessen, warum das passiert ist?

• Das erinnert mich an die Enshittification des öffentlichen Nahverkehrs. Wenn man die Budgets kürzt, sinkt das Serviceniveau, und danach folgt die negative öffentliche Wahrnehmung.
  Am Ende kann so ein Weg zu mehr Privatisierung über Sicherheits-Contractors führen.

  • Es war ja gerade ein Sicherheits-Contractor, der die Zugangsdaten geleakt hat. Insofern sind wir offenbar bereits in der Endphase ausgeweiteter Privatisierung angekommen.

• Ich erinnere mich noch an den Vorfall mit 1 Million SF-86-Formularen, die geleakt wurden. Diese Formulare, in die man Unmengen höchst persönlicher Informationen einträgt, damit beurteilt werden kann, ob man mit sensiblen Daten betraut werden sollte.

  • Das war kein Leak, sondern ein Einbruch. Verantwortlich war ein chinesischer staatlicher Sicherheitsdienst.
  • War das nicht eher OPM und nicht CISA?

• Die Abgeordneten wollen Antworten, liefern selbst aber keine. Wer überwacht eigentlich die Überwacher? Korruption von Abgeordneten geschieht in großem Maßstab, aber wenn ein Key öffentlich wird, rollt gleich ein Kopf? Selbst sehr kluge Leute veröffentlichen Keys ständig versehentlich.
  Hast du noch nie rm -rf * ausgeführt? Noch nie eine Produktionsdatenbank gelöscht? Noch nie dem falschen Server den Strom abgedreht? Das ist jedem schon passiert.

  • Ihre Aufsicht dient nicht der Fürsorge, sondern der Kontrolle. Sie ist auf subtile Weise feindselig, und „Fürsorge“ ist nur der Vorwand, nicht die Realität.

• Wenn selbst diese Leute, die eigentlich Expertinnen und Experten sein sollten, sich im Internet nicht ordentlich absichern können, wie soll dann irgendjemand sonst im Internet sicher sein?

  • Das ist nach Doge. Doge hat seine Arbeit gut gemacht. Traurigerweise haben viele andere einfach Doges Lügen nachgesprochen.

• Der eigentliche Knackpunkt ist nicht nur der geleakte AWS-GovCloud-Key, sondern dass der Contractor den Geheimnisscan-Schutz von GitHub manuell abgeschaltet hat.