Codecov: Bash-Uploader-Vertrauen als CI-Geheimnis-Verantwortlichkeitstest

Zusammenfassung

• Der Codecov Bash-Uploader-Kompromiss von 2021 wurde zu einem Test für die Verantwortlichkeit bei CI-Geheimnissen, da Codecovs eigenes Sicherheitsupdate besagte, dass ein Dritter den Bash-Uploader modifiziert hatte und möglicherweise Umgebungsvariablen und Git-Remote-Informationen aus den CI-Umgebungen der Kunden exportieren konnte.
• Codecovs Postmortem gab später an, dass der Angreifer einen HMAC-Schlüssel für ein Google Cloud Storage-Dienstkonto aus einer Zwischenschicht eines öffentlichen selbst gehosteten Docker-Images extrahiert und diesen Schlüssel verwendet hatte, um den Bash-Uploader zu modifizieren, der an Endbenutzer ausgeliefert wurde.
• Das verantwortliche Problem ist nicht nur, dass Benutzer Prüfsummen hätten verifizieren sollen. Codecov kontrollierte den Uploader-Verteilungspfad, den Build-Prozess des öffentlichen Docker-Images, die Überwachung des gehosteten Skripts, die Benachrichtigung der Kunden und den Migrationsplan weg vom Curl-to-Shell-Vertrauensmuster.
• Kunden kontrollierten, welche Geheimnisse für CI-Jobs verfügbar waren, welche Upload-Methode sie verwendeten, ob die Prüfsummenvalidierung erzwungen wurde und wie schnell sie nach der Benachrichtigung Anmeldedaten rotieren konnten. Diese Kundenkontrollen hoben die Verantwortung des Anbieters für die Skriptintegrität nicht auf.
• Dieser Artikel behandelt Codecovs Sicherheitsupdate und Postmortem als Primärquellen, Kundenreaktionen auf den Vorfall als nachgelagerte Beweise und NIST-, CISA-, SLSA-, Sigstore- und CI-Dokumentation als technisches Kontrollvokabular. Er erhebt keinen Anspruch auf Zugang zu Strafverfolgungsakten, privaten Kundenlisten oder vollständigen Angreifer-Infrastrukturprotokollen.

Warum dieser Fall in eine Risiko- und Rechenschaftsakte gehört

Codecov gehört in eine Risiko- und Rechenschaftsakte, weil der Bash-Uploader-Kompromiss von 2021 einen routinemäßigen Coverage-Upload-Schritt in einen möglichen CI-Geheimnis-Offenlegungspfad verwandelte. Codecovs Sicherheitsupdate vom 15. April 2021 unterhttps://about.codecov.io/security-update/besagte, dass Codecov am 1. April erfuhr, dass jemand unbefugten Zugriff auf das Bash-Uploader-Skript erhalten und es ohne Erlaubnis modifiziert hatte. Das Unternehmen erklärte, dass der Angreifer aufgrund eines Fehlers im Erstellungsprozess des Docker-Images von Codecov Zugriff erhalten hatte, der die Extraktion eines zur Modifikation des Uploaders erforderlichen Anmeldedatums ermöglichte. Codecov gab an, dass es ab dem 31. Januar 2021 wiederholt unbefugte Änderungen gab, die möglicherweise in den kontinuierlichen Integrationsumgebungen der Kunden gespeicherte Informationen an einen Drittserver außerhalb der Infrastruktur von Codecov exportieren konnten.

Dieser öffentliche Bericht macht den Fall größer als ein kompromittiertes Anbieterskript. Der Bash-Uploader lief in den CI-Jobs der Kunden, oft nachdem Tests abgeschlossen waren und bevor Coveragedaten hochgeladen wurden. CI-Jobs können Repository-URLs, Build-Metadaten, Bereitstellungs-Tokens, Paketveröffentlichungs-Anmeldedaten, Cloud-Anmeldedaten, Signierschlüssel, Datenbank-URLs, Webhook-Geheimnisse, persönliche Zugriffstoken und Umgebungsvariablen enthalten, die von Test- und Release-Automatisierung verwendet werden.

Eine kleine bösartige Ergänzung eines Uploaders kann zu einem Sammelpunkt für Anmeldedaten werden, da Kunden absichtlich Vertrauen und Geheimnisse in CI setzen.

Codecovs Postmortem unterhttps://about.codecov.io/apr-2021-post-mortem/schärfte die Kontrollgeschichte. Es besagte, dass der Bedrohungsakteur den Bash-Uploader ins Visier nahm und ihn nutzte, um eine schädliche Nutzlast an Benutzer zu liefern, die den Bash-Uploader, die Codecov GitHub Action, den Codecov CircleCI Orb und den Codecov Bitrise Step verwendeten. Es hieß, der Angreifer extrahierte einen HMAC-Schlüssel für ein Google Cloud Storage-Dienstkonto aus einer Zwischenschicht eines öffentlichen, selbst gehosteten Docker-Images von Codecov und verwendete diesen Schlüssel, um den Bash-Uploader in Google Cloud Storage zu modifizieren. Es hieß auch, ein Kunde entdeckte den Vorfall, nachdem er eine SHASUM-Prüfung durchgeführt hatte und eine Diskrepanz zwischen dem auf GitHub gemeldeten Hash und dem berechneten Hash des heruntergeladenen Uploaders feststellte.

Diese Fakten ordnen die Verantwortlichkeit in ein gemeinsames, aber ungleiches System ein. Codecov kontrollierte den gehosteten Uploader, den Google Cloud Storage-Schreibpfad, den Build-Prozess des selbst gehosteten Docker-Images, die Schlüsselrotation nach dem Vorfall, die Benachrichtigung der Kunden und die Umstellung auf einen neuen Uploader. Kunden kontrollierten, welche CI-Variablen vorhanden waren, als der Uploader ausgeführt wurde, ob sie das Skript live abrufen, ob eine Prüfsummenvalidierung durchgeführt wurde und wie schnell sie exponierte Geheimnisse rotieren konnten.

CI-Anbieter kontrollierten Teile der Geheimnismaskierung, Job-Isolation und Protokollierung. Nachgelagerte Benutzer trugen Risiken, wenn exponierte Anmeldedaten späteren Zugriff auf Systeme oder Code ermöglichten. Die praktische Frage ist, ob jede Partei genügend Beweise hatte, um rechtzeitig zu handeln.

Das Ereignis passt in die Ökonomie von Entwickler-Tools, da Codecovs Wertversprechen eine reibungslose Coverage-Berichterstattung über viele CI-Systeme hinweg war. Das archivierte Codecov Bash-Uploader-Repository unterhttps://github.com/codecov/codecov-bashzeigt das Bequemlichkeitsmuster direkt: Kunden konnten ein Remote-Skript abrufen und ausführen, denselben Uploader über viele CI-Anbieter hinweg verwenden und optional SHASUMs verifizieren. Bequemlichkeit war der Motor der Einführung. Aber als das vertrauenswürdige Remote-Skript von einem angreifergesteuerten Pfad aus änderbar wurde, erschienen die versteckten Kosten als Notfall-Inventarisierung von Anmeldedaten, Rotation, Repository-Überprüfung, Kundenbenachrichtigung und Reaktion auf Vorfälle.

Der Bash-Uploader schuf eine Vertrauensumkehrung innerhalb der CI

Coverage-Uploader werden leicht unterschätzt. Sie erscheinen am Ende eines Test-Jobs, nachdem der Hauptanwendungscode bereits ausgeführt wurde. Diese Platzierung kann sie als weniger riskant erscheinen lassen als Build-Tools, Bereitstellungsbefehle oder Paketveröffentlichungsschritte. In Wirklichkeit kann ein Coverage-Uploader dieselbe Umgebung sehen wie der Job, der ihn aufruft, sofern die Pipeline ihn nicht bewusst isoliert. Wenn der Job Cloud-Anmeldedaten, API-Tokens, Repository-Zugriff, Paketregistrierungsgeheimnisse oder Dienstschlüssel enthält, kann der Uploader-Prozess diese möglicherweise lesen.

Codecovs eigene Bash-Uploader-Dokumentation unterhttps://docs.codecov.com/docs/about-the-codecov-bash-uploaderund die Anweisungen im archivierten Repository zeigen, warum dies wichtig war. Der Uploader wurde entwickelt, um CI-Einstellungen zu erkennen, Berichte zu sammeln und Coveragedaten zu übermitteln. Dasselbe Repository dokumentierte einen Verifizierungsprozess unter Verwendung von SHASUM-Dateien, aber Codecovs Postmortem räumte ein, dass der Prozess vor dem Vorfall nicht vollständig oder ordnungsgemäß dokumentiert worden war. Das Sicherheitsupdate sagte auch, dass Kunden, die vor der Verwendung des Bash-Uploaders einen Prüfsummenvergleich durchgeführt hatten, möglicherweise nicht betroffen waren. Das ist eine aufschlussreiche Grenze: Die Integritätsprüfung war eine gültige Verteidigung, aber sie war durch das Verteilungsmodell nicht unvermeidbar gemacht worden.

Die Vertrauensumkehrung war einfach. Kunden vertrauten dem Skript von Codecov, weil das Skript eine Abhängigkeit in einem Workflow war, der die Testabdeckung maß. Das Skript lief dann in einer kundenkontrollierten CI-Umgebung, die weit mehr Berechtigungen enthalten konnte, als Codecov benötigte, um einen Coverage-Bericht zu erhalten. Im Effekt gab der Kunde einem Berichtswerkzeug eine Position, von der aus es Bereitstellungsgeheimnisse beobachten oder exportieren konnte, wenn das Werkzeug verändert wurde. Das bedeutet nicht, dass jeder Kunde kritische Geheimnisse preisgab.

Es bedeutet, dass der Explosionsradius von der Gestaltung der CI-Umgebung jedes Kunden abhing, nicht nur von der Dienstgrenze von Codecov.

Die offizielle Codecov-Mitteilung listete Anmeldedaten, Tokens, Schlüssel, Dienste, Datenspeicher, Anwendungscode und Git-Remote-Informationen als Klassen auf, die potenziell betroffen sein könnten, wenn sie bei der Ausführung des geänderten Uploaders zugänglich waren. Diese Aussage sollte sorgfältig gelesen werden. Sie bewies nicht, dass jeder Kunde jedes Geheimnis verlor. Sie beschrieb das Expositionspotenzial basierend darauf, wo das Skript ausgeführt wurde.

Kunden mussten dann feststellen, welche Geheimnisse in ihren eigenen Jobs vorhanden waren, ob diese Geheimnisse sensibel waren, welche Systeme sie entsperrten und ob ein späterer Missbrauch in Protokollen sichtbar war.

Moderne CI-Dokumentation unterstreicht dieses gemeinsame Risikomodell. Die GitHub Actions-Härtungsanleitung unterhttps://docs.github.com/en/actions/security-guides/security-hardening-for-github-actionsbehandelt Geheimnisse, Token-Berechtigungen, Drittanbieteraktionen und Skriptinjektionsrisiken. Die GitLab-CI/CD-Variablendokumentation unterhttps://docs.gitlab.com/ci/variables/und die CircleCI-Umgebungsvariablendokumentation unterhttps://circleci.com/docs/env-vars/zeigen, wie CI-Systeme Geheimnisse absichtlich unter kontrollierten Bedingungen für Jobs verfügbar machen. Diese Dokumente sind keine Vorfallserkenntnisse über Codecov. Sie definieren die Umgebung, in der der Codecov-Kompromiss ernst wurde: CI-Jobs sind privilegierte Automatisierungsräume, keine neutralen Terminals.

Der Erkennungszeitpunkt ließ Kunden mit Unsicherheit zurück

Der Erkennungszeitpunkt ist ein zentrales Rechenschaftsproblem, da Kunden den Umfang nicht sofort kennen konnten. Codecov gab an, am 1. April 2021 von dem Problem erfahren zu haben, nachdem ein Kunde, der eine SHASUM-Validierung durchführte, eine Diskrepanz meldete. Die öffentliche Offenlegung am 15. April erfolgte nach Untersuchung, Forensik und Koordination. Das Sicherheitsupdate gab an, dass das relevante Fenster am 31. Januar begann und dass betroffene Benutzer per E-Mail und In-App-Benachrichtigungen kontaktiert wurden. Das Update vom 29.

April fügte weitere Informationen über Umgebungsvariablen hinzu, die möglicherweise unbefugt erlangt wurden, und über betroffene Organisationen und Repositorys.

Es gibt zwei Fairness-Punkte, die zusammengehalten werden müssen. Erstens erfordert die Reaktion auf Vorfälle tatsächlich eine Untersuchung. Ein Anbieter, der offenlegt, bevor er die grundlegenden Fakten versteht, kann Kunden in die Irre führen und die falsche Abhilfe verursachen. Codecovs Postmortem sagte, das Unternehmen habe während der Untersuchung mit Bundesstrafverfolgungsbehörden und Cybersicherheitsbehörden koordiniert. Zweitens haben Kunden mit offengelegten CI-Geheimnissen ihre eigene Uhr.

Wenn eine Cloud-Anmeldedaten, ein Paket-Token, ein Repository-Bereitstellungsschlüssel oder ein Signierschlüssel im Februar für einen Job verfügbar war, muss ein Kunde ihn möglicherweise sofort rotieren, Prüfprotokolle überprüfen und die nachgelagerte Exposition bewerten. Je länger die Unsicherheit andauert, desto schwieriger ist es zu wissen, ob die Anmeldedaten verwendet wurden.

Die Rechenschaftsakte sollte daher fragen, was Kunden am 1., 15. und 29. April wussten. Wussten sie, welche Repositorys betroffene Uploader verwendeten? Wussten sie, ob sie den Uploader während der kompromittierten Fenster live abgerufen hatten? Wussten sie, welche Umgebungsvariablen möglicherweise erlangt wurden? Wussten sie, welche genauen Geheimnisse in diesen Jobs vorhanden waren? Wussten sie, ob eine Prüfsummenvalidierung durchgeführt wurde? Hatten sie Protokolle, die lang genug aufbewahrt wurden, um einen möglichen Missbrauch zu untersuchen? Diese Fragen bestimmen, ob die Benachrichtigung umsetzbar war.

Die CISA-Warnseite für Codecov unterhttps://www.cisa.gov/news-events/alerts/2021/04/22/codecov-releases-security-updatebehandelte die Anbieterbenachrichtigung als wichtig genug, um sie zu verstärken. Dies ist ein nützlicher öffentlicher Beweis dafür, dass der Vorfall eine Angelegenheit der Software-Lieferkette und der Kundenabhilfe war, nicht nur ein internes Codecov-Ereignis. Das NIST Secure Software Development Framework unterhttps://csrc.nist.gov/pubs/sp/800/218/finalist auch hier nützlich, da es Komponenten von Drittanbietern, Build-Umgebungen und Schwachstellenreaktion als Lebenszykluskontrollen einrahmt. Der Codecov-Kompromiss lag an der Grenze aller drei.

Die Erkennungsgeschichte zeigt auch den Wert und die Schwäche der kundenseitigen Verifizierung. Ein Kunde entdeckte die Diskrepanz, weil er den heruntergeladenen Bash-Uploader gegen die erwartete SHASUM prüfte. Das ist ein starkes Signal, dass die Verifizierung funktioniert. Es ist auch eine schwache Kontrolle, wenn nur ungewöhnlich sorgfältige Kunden sie durchführen. Das stärkere Design besteht darin, die Ausführung ohne Signatur oder Verifizierung zur Ausnahme und nicht zur Standardeinstellung zu machen. Codecovs Postmortem sagte, der neue Uploader werde als signierte und SHASUM-verifizierbare Binärdatei ausgeliefert und die Einstellung des Bash-Uploaders sei Teil der Korrekturmaßnahme. Die Ankündigung des neuen Uploaders unterhttps://about.codecov.io/blog/introducing-codecovs-new-uploader/gehört aus diesem Grund in die Reparaturakte.

Die Schlüsselrotation war die eigentliche Arbeitslast für die Kunden

Sobald der Kompromiss öffentlich war, verlagerte sich die Betriebslast schnell auf die Kunden. Codecov riet betroffenen Benutzern, die in den CI-Umgebungen vorhandenen Schlüssel und Tokens zu identifizieren, sensible Anmeldedaten zu ungültig zu machen, Ersatz zu generieren und die Token-Nutzung zu prüfen. Das klingt einfach, bis es auf eine reale Softwareorganisation angewendet wird.

Ein einzelner CI-Job kann Paketregistrierungs-Tokens, Cloud-Anbieter-Anmeldedaten, Bereitstellungsschlüssel, Artefakt-Repository-Geheimnisse, Datenbank-URLs für Integrationstests, Testkontopasswörter, Slack- oder PagerDuty-Webhooks, Docker-Registry-Passwörter, Terraform-Status-Anmeldedaten, Signiermaterial oder persönliche Zugriffstoken enthalten. Diese Geheimnisse können über Repositorys hinweg wiederverwendet oder von organisationsweiten CI-Einstellungen geerbt werden.

Die Herausforderung auf Kundenseite war nicht nur die Rotation. Es war die Kartierung. Welche Repositorys verwendeten den betroffenen Uploader? Welche Jobs liefen während der betroffenen Fenster? Welche Umgebungsvariablen waren in diesen Jobs vorhanden? Waren Geheimnisse in Protokollen maskiert, aber für den Prozess dennoch lesbar? Welche Cloud-Konten, Paketregistrierungen, Code-Hosts und internen Dienste akzeptierten diese Anmeldedaten? Welche Systeme hatten Prüfprotokolle? Wie lange wurden Protokolle aufbewahrt? Konnte die Organisation keinen Missbrauch nachweisen oder nur defensiv rotieren?

Die Kosten des Vorfalls wurden daher ebenso in Arbeitszeit für die Reaktion auf Vorfälle gemessen wie in bestätigtem Missbrauch.

Kundenreaktionen aus erster Hand zeigen, warum dies wichtig ist. Die öffentliche Sicherheitsmitteilung von HashiCorp unterhttps://discuss.hashicorp.com/t/hcsec-2021-12-codecov-security-event-and-hashicorp-gpg-key-exposure/23512beschrieb die Offenlegung eines GPG-privaten Schlüssels, der zum Signieren von Releases verwendet wurde, sowie einen Prozess für Widerruf und Ersatz. Die Antwort von Twilio unterhttps://www.twilio.com/en-us/blog/company/communications/response-to-the-codecov-vulnerabilitybeschrieb deren Untersuchung und Bewertung der Kundenauswirkungen. Die Antwort von Rapid7 unterhttps://www.rapid7.com/blog/post/2021/05/13/rapid7s-response-to-codecov-incident/beschrieb deren eigene Überprüfung und Abhilfe. Der Vorfallbericht von Mercari unterhttps://about.mercari.com/en/press/news/articles/20210521_incident_report/beschrieb die Offenlegung von Kunden- und Mitarbeiterdaten im Zusammenhang mit dem Codecov-Vorfall. Dies ist kein Beweis dafür, dass jeder Codecov-Kunde das gleiche Ergebnis hatte. Es sind nachgelagerte Beweise dafür, dass die Kundenabhilfe real, vielfältig und folgenreich war.

Das HashiCorp-Beispiel ist besonders lehrreich, da Signierschlüssel keine gewöhnlichen API-Tokens sind. Ein Signierschlüssel kann die Softwareauthentizität beeinträchtigen. Sein Ersatz erfordert Widerruf, neue Vertrauensverteilung, Kommunikation mit Kunden und Zeit. Das bedeutet nicht, dass Codecov jedes signierte Artefakt direkt kompromittiert hat. Es bedeutet, dass die Offenlegung von CI-Geheimnissen die Software-Lieferkette erreichen kann, wenn das offengelegte Material Schlüssel umfasst, die zum Beglaubigen oder Verteilen von Software verwendet werden.

Der Explosionsradius hängt vom Geheimnistyp, der Nutzung, der Lebensdauer und den Widerrufsnachweisen ab.

Das Mercari-Beispiel veranschaulicht eine weitere Grenze. Der Codecov-Vorfall war eine Kompromittierung eines Anbietertools, aber die Offenlegung von Kundendaten kann in der eigenen Umgebung des Kunden sichtbar werden, abhängig von den Geheimnissen und Systemen, die für die betroffenen CI-Jobs verfügbar waren. Deshalb können die Verantwortlichkeit des Anbieters und die Verantwortlichkeit des Kunden nicht in getrennte Schubladen gesteckt werden. Codecov musste die Uploader-Integrität reparieren und den Kunden mitteilen, was passiert war. Kunden mussten feststellen, welche Geheimnisse vorhanden waren und was diese Geheimnisse erreichen konnten.

Die Verteilungsintegrität war der zentrale Reparaturanspruch

Der zentrale Reparaturanspruch nach dem Codecov-Vorfall war die Verteilungsintegrität. Das Bash-Uploader-Muster ermutigte Kunden, ausführbaren Code zur Laufzeit des Jobs abzurufen. Dieses Muster machte Updates einfach und die Sprachunterstützung breit, aber es machte das gehostete Skript auch zu einem hochwertigen Ziel. Wenn ein Angreifer das Skript im Speicher modifizieren könnte, könnte jeder unverifizierte nachgelagerte Abruf die bösartige Änderung übernehmen. Der Anbieter musste daher zeigen, dass sich die Änderungsrechte, die Signierung, die Prüfsummen, die Überwachung, die Image-Builds und die Release-Verfahren geändert hatten.

Codecovs Postmortem listete mehrere Korrekturmaßnahmen auf: Widerruf des gestohlenen Schlüssels, Prüfung und Rotation von Produktionsschlüsseln, Aktualisierung öffentlicher Docker-Images auf Squash- oder Multistage-Builds, Einführung eines neuen Uploaders, Überwachung relevanter Google Cloud Storage-Assets, Verbesserung der Dokumentation für Signatur- und SHASUM-Validierung, Änderung der Richtlinie zur Schlüsselgenerierung und -rotation, Verbesserung der Reaktion auf Vorfälle und Besetzung einer dedizierten Sicherheitsfunktion. Jede Maßnahme adressierte ein anderes Glied der Kette.

Die Docker-Image-Korrektur adressierte das Durchsickern von Geheimnissen durch Image-Schichten. Die Schlüsselrotation adressierte den unmittelbaren Anmeldedatenpfad. Die Überwachung adressierte zukünftige unbefugte Modifikationen. Der neue Uploader adressierte das Verteilungs- und Validierungsdesign.

Docker-Image-Schichten sind ein wichtiger Beweispunkt. Codecov gab an, dass der Angreifer einen HMAC-Schlüssel aus einer Zwischenschicht eines öffentlichen, selbst gehosteten Docker-Images extrahierte. Die Docker-Dokumentation zu Multi-Stage-Builds unterhttps://docs.docker.com/build/building/multi-stage/erklärt, warum Build-Artefakte und Zwischenmaterial aus endgültigen Images ferngehalten werden müssen. Die Korrekturmaßnahme im Codecov-Postmortem, Squash- oder Multistage-Builds zu verwenden, stand daher in direktem Zusammenhang mit der Ursachenklasse. Ein Geheimnis in einer Image-Schicht ist nicht allein dadurch geschützt, dass der endgültige Container sauber aussieht.

Das breitere Vokabular der Software-Lieferkette hilft ebenfalls. Das SLSA-Framework unterhttps://slsa.dev/und Sigstore unterhttps://www.sigstore.dev/befassen sich beide mit Integrität, Herkunft, Signierung und Verifizierbarkeit von Software-Artefakten. Sie sind keine rückwirkenden Compliance-Tests für Codecovs Uploader von 2021. Sie definieren, warum ein veränderbares gehostetes Skript ein schwächeres Verteilungsmodell ist als ein signiertes, versioniertes, verifizierbares Artefakt mit Herkunftsnachweis. Der OpenSSF Scorecard unterhttps://scorecard.dev/stellt Abhängigkeits- und Repository-Hygiene als messbare Lieferkettenkontrollen dar. Der wichtige Punkt ist nicht, dass ein Framework jeden Teil des Vorfalls verhindert hätte. Der Punkt ist, dass die Artefaktintegrität so konzipiert sein muss, dass von Kunden nicht erwartet wird, Manipulationen manuell zu entdecken.

Die aktuelle Codecov-Uploader-Dokumentation unterhttps://docs.codecov.com/docs/codecov-uploaderund das Uploader-Repository unterhttps://github.com/codecov/uploaderzeigen die Migrationsrichtung weg vom älteren reinen Bash-Modell. Das Codecov GitHub Action-Repository unterhttps://github.com/codecov/codecov-actionbleibt relevant, da viele Benutzer Codecov über Plattformintegrationen statt direkter Bash-Aufrufe nutzten. Der Vorfall zeigte, dass Wrapper, Orbs und Schritte die Vertrauensgrenze eines gemeinsam genutzten zugrunde liegenden Uploaders erben können. Kunden denken vielleicht, sie verwenden eine CI-native Integration, aber das Risiko kann dennoch durch dasselbe Remote-Skript oder dieselbe Binärdatei fließen.

CI-Anbieter und Kunden mussten den Explosionsradius dennoch reduzieren

Die Reparatur durch den Anbieter war notwendig, aber die Reduzierung des Explosionsradius auf Kundenseite blieb wesentlich. Eine CI-Umgebung sollte keine Geheimnisse preisgeben, die ein Job nicht benötigt. Ein Coverage-Upload-Schritt benötigt im Allgemeinen genügend Berechtigungen, um Coverage-Dateien zu lesen und sich bei Codecov zu authentifizieren. Er sollte keine breiten Cloud-Bereitstellungsanmeldedaten, Produktionsdatenbankzugriff, Paketveröffentlichungsberechtigungen oder langlebige persönliche Tokens benötigen, es sei denn, derselbe Job kombiniert nicht zusammenhängende Verantwortlichkeiten.

Das Prinzip der minimalen Rechte in CI ist nicht abstrakt. Es bestimmt, ob eine kompromittierte Drittanbieteraktion oder ein kompromittiertes Skript ein harmloses Upload-Token oder eine umfassende Anmeldedaten für das gesamte Unternehmen sieht.

GitHub Actions, GitLab CI, CircleCI, Buildkite, Jenkins und andere CI-Systeme bieten Organisationen Möglichkeiten, Variablen zu begrenzen, Jobs zu trennen, Geheimnisse zu maskieren, Branch-Zugriff einzuschränken, geschützte Umgebungen zu erfordern und Token-Berechtigungen zu beschränken. Aber diese Kontrollen sind nur nützlich, wenn die Pipeline-Design sie verwendet. Ein monolithischer Job, der Tests ausführt, Artefakte erstellt, Infrastruktur bereitstellt, Releases signiert, Pakete veröffentlicht und Coverage hochlädt, erzeugt eine gleichartige Exposition.

Wenn der letzte Coverage-Schritt jede Umgebungsvariable lesen kann, die von früheren Schritten verwendet wird, wird der Explosionsradius durch Bequemlichkeit und nicht durch Notwendigkeit definiert.

Das Codecov-Ereignis gehört daher sowohl zur Sicherheitsautomatisierung als auch zur Ökonomie von Entwickler-Tools. Automatisierung soll manuelle Risiken reduzieren. Aber Automatisierung kann auch Vertrauensannahmen verbergen. Eine YAML-Datei wurde vielleicht Jahre zuvor kopiert. Ein Uploader-Befehl wird möglicherweise in Dutzenden von Repositorys ausgeführt. Ein organisationsweites Geheimnis wird möglicherweise in jeden Job injiziert, weil es einfacher war, als es pro Projekt zu begrenzen. Ein rotierter Token kann Pipelines zum Stillstand bringen, wenn die Eigentumsverhältnisse unklar sind.

Der Vorfall zwang Teams dazu, die Automatisierung zu prüfen, die zur Hintergrundinfrastruktur geworden war.

Zu den Kundenevidenz sollten ein CI-Geheimnisinventar, eine Überprüfung der Job-Berechtigungen, ein Token-Rotationsprotokoll, eine Prüfprotokollüberprüfung und eine Abhängigkeitskarte für Aktionen oder Skripte von Drittanbietern gehören. Wenn eine Organisation nicht beantworten kann, welche Repositorys einen bestimmten Uploader während eines bestimmten Fensters verwendet haben, kann sie die Exposition nicht sicher eingrenzen. Wenn sie nicht beantworten kann, welche Geheimnisse vorhanden waren, kann sie nicht intelligent rotieren.

Wenn sie nicht sagen kann, ob ein Token nach der Exposition verwendet wurde, kann sie bestätigten Missbrauch nicht von vorsorglicher Rotation unterscheiden.

Deshalb variierten die öffentlichen Kundenmitteilungen. Einige Organisationen berichteten nach der Untersuchung von keinen Anzeichen unbefugten Zugriffs. Andere rotierten Schlüssel oder legten konkretere Expositionen offen. Diese Variation ist nicht widersprüchlich. Sie spiegelt die Tatsache wider, dass der kompromittierte Uploader von Codecov einen potenziellen Exfiltrationsmechanismus schuf, während die nachgelagerte Konsequenz von jeder CI-Umgebung abhing. Die Rechenschaftsakte muss potenzielle Exposition, bestätigten Geheimniszugriff, bestätigten Missbrauch und Auswirkungen auf Kundendaten in getrennten Kategorien halten.

Beweisgrenzen und keine Überbeanspruchung von Behauptungen

Die öffentlichen Beweise stützen eine starke Schlussfolgerung, aber keine unbegrenzten Behauptungen. Sie stützen, dass Codecovs Bash-Uploader ohne Autorisierung modifiziert wurde, dass die Modifikation Umgebungsvariablen und Git-Remote-Informationen aus CI-Umgebungen exportieren konnte, dass das relevante Fenster am 31. Januar begann und mit der Abhilfe am 1.

April 2021 endete, dass eine kundenseitige Prüfsummendiskrepanz half, das Problem zu erkennen, dass eine öffentliche Docker-Image-Schicht ein Anmeldedatum preisgab, das zur Modifikation des Uploaders verwendet wurde, und dass Codecov eine Schlüsselrotation für betroffene Benutzer empfahl. Sie stützen, dass einige Kunden ihre eigene Abhilfe oder Exposition öffentlich offenlegten.

Die öffentlichen Beweise stützen nicht die Behauptung, dass jeder Codecov-Kunde sensible Geheimnisse preisgab, dass jedes exponierte Geheimnis verwendet wurde, dass jeder nachgelagerte Vorfall durch Codecov verursacht wurde oder dass Codecov die vollständigen Auswirkungen vor seiner Offenlegung kannte. Sie geben keinen vollständigen Kundenkreis, keine vollständigen Protokolle der Angreiferinfrastruktur, keine Ergebnisse der Strafverfolgung, keine forensischen Berichte und keine erlangten Kundenvariablen preis. Eine seriöse Rechenschaftsakte sollte diese Unbekannten benennen, anstatt sie mit Verdacht zu füllen.

Der Unterschied zwischen möglicher Exposition und bestätigtem Missbrauch ist wichtig für Kunden und nachgelagerte Benutzer. Codecovs Sicherheitsupdate sprach in Bezug auf Anmeldedaten, Tokens, Schlüssel, Dienste, Datenspeicher, Anwendungscode und Git-Remote-Informationen, die potenziell betroffen sein könnten, wenn sie für den Uploader verfügbar waren. Diese Möglichkeit war wichtig genug, um eine breite Rotationsanleitung zu rechtfertigen. Aber Möglichkeit ist nicht dasselbe wie ein Beweis für späteren Zugriff.

Kundenmitteilungen zu Vorfällen sind notwendig, da jeder Kunde den allgemeinen Expositionspfad auf seine eigene Umgebung anwenden musste.

Der Offenlegungszeitpunkt ist eine weitere Grenze. Codecov legte am 15. April öffentlich offen, nachdem es das Ereignis am 1. April entdeckt hatte. Das Unternehmen erklärte, es habe mit forensischen Experten untersucht und mit Behörden koordiniert. Kunden können dennoch fragen, ob eine gezieltere frühere Warnung möglich war, ob Kunden mit hohem Expositionsrisiko früher benachrichtigt werden sollten und ob die zusätzlichen Informationen vom 29. April rechtzeitig genug kamen. Das sind legitime Rechenschaftsfragen. Sie sind kein Beweis für Böswilligkeit ohne weitere Beweise.

Der Artikel sollte auch die Prüfsummenvalidierung nicht als vollständige Übertragung der Verantwortung behandeln. Codecov dokumentierte die SHASUM-Validierung, und ein Kunde, der diese Kontrolle nutzte, entdeckte das Problem. Diese Tatsache bedeutet nicht, dass jeder Kunde fahrlässig war, wenn er das optionale Verfahren nicht implementiert hatte. Wenn das übliche Nutzungsmuster des Produkts das Abrufen eines Live-Remote-Skripts war, musste der Anbieter das Risiko tragen, dass viele Kunden den einfachen Weg wählten. Je reibungsloser die Integration, desto mehr Verantwortung hat der Anbieter, Integritätsprüfungen in den Standardpfad einzubauen.

Der dauerhafte Rechenschaftstest ist der Nachweis reparierten Vertrauens

Der dauerhafte Rechenschaftstest ist, ob Codecov und seine Kunden den Vorfall in einen Nachweis reparierten Vertrauens umwandelten. Für Codecov bedeutete der Nachweis: Widerruf des gestohlenen Schlüssels, Rotation interner Anmeldedaten, Entfernung exponierter Image-Schicht-Geheimnisse, Änderung der Docker-Image-Build-Prozesse, Überwachung des gehosteten Skriptspeichers, Dokumentation der Validierung, Auslieferung eines signierten und verifizierbaren Ersatz-Uploaders und Verbesserung der Reaktion auf Vorfälle.

Für Kunden bedeutete der Nachweis: Identifizierung betroffener Repositorys, Aufzählung von CI-Geheimnissen, Rotation exponierter Anmeldedaten, Überprüfung nachgelagerter Protokolle, Eingrenzung von Job-Berechtigungen und Einführung einer Verifizierung für Drittanbieter-Tools.

Die zentrale Reparaturfrage ist die Verteilungsvoreinstellung. Wenn Kunden immer noch häufig veränderbaren Code ohne integrierte Verifizierung abrufen und ausführen, bleibt dieselbe Risikoklasse bestehen. Wenn Uploader signiert, versioniert, fixiert, mit Prüfsummen versehen und überwacht sind, wird das Risiko reduziert. Wenn CI-Jobs den Coverage-Upload von der Bereitstellungsautorisierung isolieren, hat ein zukünftiger Uploader-Kompromiss weniger zu stehlen. Wenn Geheimnisverwalter kurzlebige Anmeldedaten anstelle von langlebigen Tokens ausstellen, wird die Notfallrotation einfacher.

Wenn Prüfprotokolle lang genug aufbewahrt werden, können Kunden Vorsichtsmaßnahmen von bestätigtem Missbrauch unterscheiden.

Auch Beschaffungs- und Governance-Teams sollten aus diesem Fall lernen. Ein Entwickler-Tool, das in CI läuft, ist kein harmloses Observability-Add-on. Es ist eine Codeausführung in einer Automatisierungsumgebung, die hochwertige Geheimnisse enthalten kann. Anbieterbewertungen sollten fragen, wie Uploader und Aktionen verteilt werden, ob Artefakte signiert sind, wie ein Kompromiss erkannt wird, wie Kunden benachrichtigt werden, welche Telemetrie der Anbieter bereitstellen kann, um betroffene Repositorys zu identifizieren, und wie der Anbieter vermeidet, Signierschlüssel in öffentlichen Build-Artefakten zu speichern oder offenzulegen.

Der Vorfall änderte auch die Bedeutung von „Sicherheitsautomatisierung“. Automatisierung ist nicht sicher, weil sie automatisiert ist. Sie ist sicher, wenn die Automatisierung begrenzte Autorität, verifizierbare Eingaben, reproduzierbare Artefakte, prüfbare Protokolle und schnelle Widerrufsmöglichkeiten hat. Der Codecov-Bash-Uploader-Kompromiss zeigte, dass ein kleiner Automatisierungsschritt zu einer großen Vertrauensgrenze werden kann, wenn er dort ausgeführt wird, wo Geheimnisse leben.

Die letzte Lektion ist praktisch. Coveragedaten sind wichtig, aber der Coverage-Upload sollte nicht mit jedem Anmeldedatum, das ein Unternehmen besitzt, in einem Raum sein. Ein Entwickler-Telemetrieanbieter muss die Integrität des Codes nachweisen, den er von Kunden auszuführen verlangt. Kunden müssen CI so gestalten, dass Drittanbieter-Tools nur das sehen, was sie benötigen. Wenn eine Seite sich auf Bequemlichkeit ohne Beweise verlässt, kommt die Rechnung als Notfall-Schlüsselrotation, Kundenbenachrichtigung und Lieferkettenunsicherheit. Codecov hat diese Rechnung sichtbar gemacht.

Der Uploader war klein, aber sein Laufzeitkontext war groß

Ein Grund, warum der Codecov-Vorfall wichtig bleibt, ist, dass das kompromittierte Objekt betrieblich klein war. Es war kein vollständiger Quellcode-Host, keine Cloud-Konsole, kein Identitätsanbieter und keine Paketregistrierung. Es war ein Coverage-Uploader. Aber der Laufzeitkontext des Uploaders konnte groß sein, da CI-Jobs häufig Autorität aus vielen Systemen gleichzeitig sammeln.

Ein Test-Job kann ein privates Repository klonen, Abhängigkeiten herunterladen, auf interne Paketspiegel zugreifen, Testanmeldedaten entschlüsseln, Cloud-Dienste starten, Berichte veröffentlichen, sich bei einer Coverage-Plattform authentifizieren und spätere Bereitstellungsschritte auslösen. Wenn dieselben Umgebungsvariablen über den gesamten Job hinweg sichtbar sind, erbt ein abschließendes Berichtsskript Zugriff, der für andere Zwecke geschaffen wurde.

Deshalb müssen minimale Rechte in CI auf Job- und Schritt-Ebene implementiert werden, nicht nur auf Organisationsebene. Ein Geheimnis, das für die Bereitstellung geeignet ist, sollte nicht in einen reinen Coverage-Job injiziert werden. Ein Paketveröffentlichungs-Token sollte während eines Unit-Test-Schritts, der Coverage hochlädt, nicht verfügbar sein. Eine Cloud-Anmeldedaten, die für Integrationstests verwendet wird, sollte kurzlebig und auf Testressourcen beschränkt sein. Repository-Tokens sollten minimale Berechtigungen haben.

Geheimnisse mit geschütztem Branch sollten nicht in nicht vertrauenswürdigen Pull-Request-Kontexten offengelegt werden. Der Codecov-Kompromiss hat diese Regeln nicht erfunden, aber er lieferte einen konkreten Grund, sie durchzusetzen.

Der Vorfall zeigt auch, warum Geheimnismaskierung nicht ausreicht. CI-Plattformen maskieren Geheimnisse oft in Protokollen, was nützlich ist, aber die Maskierung hindert einen Prozess nicht daran, eine Umgebungsvariable zu lesen und anderswohin zu senden. Maskierung schützt menschliche Leser von Protokollen. Sie verwandelt ein Geheimnis mit hoher Autorität nicht in ein Geheimnis mit niedriger Autorität. Wenn ein Drittanbieter-Skript im selben Prozesskontext wie das Geheimnis läuft, ist die Kontrolle bereits von der Geheimhaltung in Protokollen zum Vertrauen in Code übergegangen. Das ist eine viel stärkere Annahme.

Ein stärkeres Design trennt den Coverage-Upload in eine eingeschränkte Stufe. Die Stufe erhält nur die Coverage-Dateien und den Token, der zur Authentifizierung beim Coverage-Dienst erforderlich ist. Sie verwendet eine festgelegte Uploader-Version oder eine signierte verifizierte Binärdatei. Sie hat keine Bereitstellungsanmeldedaten, keine Produktions-Cloud-Schlüssel, keine Paketveröffentlichungs-Tokens, keine langlebigen persönlichen Zugriffstokens und keinen Zugriff auf nicht zusammenhängende Job-Ausgaben. Wenn der Uploader später kompromittiert wird, sieht der Angreifer eine enge Umgebung.

Der Vorfall wird zu einem Anbieterintegritätsproblem und nicht zu einem unternehmensweiten Geheimnisrotationsereignis.

Dieses Design hilft auch bei der Untersuchung. Wenn ein kompromittiertes Drittanbieter-Tool eine enge Umgebung hat, können Responder Expositionsfragen schnell beantworten. Sie wissen, welcher Token vorhanden war, welches System er erreichte, ob er rotiert wurde und welche Protokolle zu prüfen sind. Wenn ein Job viele geerbte Geheimnisse hat, müssen Responder unter Zeitdruck einen breiten Graphen rekonstruieren. Die Betriebskosten des Codecov-Vorfalls kamen teilweise von dieser Unsicherheit. Kunden mussten entdecken, was ihre eigenen CI-Jobs sichtbar gemacht hatten.

Verifizierung sollte Standard, beobachtbar und langweilig sein

Der Codecov-Fall veranschaulicht auch ein breiteres Prinzip: Software-Verifizierung muss Standard, beobachtbar und langweilig sein. Sie sollte nicht von einem ungewöhnlich sorgfältigen Kunden abhängen, der eine Hash-Diskrepanz bemerkt. Der Kunde, der die Diskrepanz fand, leistete einen wichtigen öffentlichen Dienst, aber ein ausgereifter Verteilungskanal sollte Manipulationen für jeden Verbraucher sichtbar machen oder die Ausführung automatisch stoppen.

Das bedeutet festgelegte Versionen, signierte Artefakte, unabhängige Veröffentlichung von Prüfsummen, reproduzierbare oder prüfbare Builds, wo möglich, Überwachung auf unerwartete Objektänderungen und klare Dokumentation, die normale Teams befolgen können, ohne zu Lieferkettenspezialisten zu werden.

Es gibt eine praktische Balance. Entwickler-Tools sind erfolgreich, weil sie leicht zu übernehmen sind. Wenn die Verifizierung zu schwierig ist, werden Teams sie überspringen. Wenn die Verifizierung optional und versteckt ist, werden nur die sicherheitsbewusstesten Teams sie verwenden. Der Anbieter muss daher die Standardintegration so gestalten, dass der sichere Pfad der normale Pfad ist. Eine GitHub Action sollte Versionen und Berechtigungen klar festlegen. Ein binärer Uploader sollte signiert und durch Installationsanweisungen geprüft werden.

Ein CI-Orb oder -Schritt sollte kein veränderbares Remote-Skript stillschweigend umschließen, ohne diese Abhängigkeit sichtbar zu machen. Die Dokumentation sollte Fehlermodi erklären, nicht nur Befehle für den glücklichen Pfad.

Beobachtbarkeit ist auch auf Anbieterseite wichtig. Codecovs Postmortem sagte, es habe die Überwachung für relevante Google Cloud Storage-Assets hinzugefügt. Diese Kontrollkategorie ist wesentlich. Ein gehosteter Skript- oder Binärverteilungs-Bucket sollte Warnungen auslösen, wenn sich der Inhalt unerwartet ändert, wenn Schlüssel aus ungewöhnlichen Kontexten verwendet werden, wenn sich Objektmetadaten ändern oder wenn Release-Pfade von der erwarteten Automatisierung abweichen. Signierung schützt Kunden zur Ausführungszeit. Überwachung schützt den Anbieter zur Verteilungszeit. Beide sind notwendig.

Schließlich sollte der Verifizierungsnachweis einen Vorfall überleben. Nach einem Kompromiss müssen Kunden wissen, welche Artefaktversionen existierten, wann sie sich änderten, welche Signaturen gültig waren, welche Integrationspfade welches Artefakt abriefen und welche Repositorys während des betroffenen Zeitraums liefen. Ein Anbieter, der diese Fragen nicht beantworten kann, überlässt es den Kunden, die Exposition aus möglicherweise unvollständigen Protokollen abzuleiten. Die beste Reparatur nach Codecov ist nicht nur ein sichererer Uploader.

Es ist ein Verteilungsnachweisbuch, das es Kunden ermöglicht, zukünftige Vorfälle schnell einzugrenzen.

Dieses Buch ist die Brücke zwischen Anbieterverantwortung und Kundenhandeln. Codecov kann die Uploader-Integrität verifizierbar machen. Kunden können CI-Geheimnisse eingrenzen und Abhängigkeiten festlegen. CI-Plattformen können Berechtigungsgrenzen, Geheimnisbegrenzung und Prüfprotokolle unterstützen. Keine dieser Kontrollen allein ist ausreichend. Zusammen verwandeln sie einen Coverage-Upload-Schritt von einer versteckten Vertrauensannahme in eine kontrollierte Automatisierungsgrenze.

Die Beschaffung sollte CI-Tools als privilegierten Code behandeln

Die Beschaffungslektion ist direkt: Jedes Tool, das in CI ausgeführt wird, sollte als privilegierter Code bewertet werden, selbst wenn die Geschäftsfunktion beobachtend klingt. Coverage-Berichterstattung, statische Analyse, Abhängigkeitsscanning, Artefakt-Upload, Release-Notes-Generierung, Dokumentationsveröffentlichung und Bereitstellungsbenachrichtigungen können alle in Umgebungen ausgeführt werden, die Geheimnisse enthalten.

Ein Anbieterfragebogen, der nur fragt, ob der Dienst Kundendaten speichert, übersieht die wichtigere Frage: Welchen Code verlangt der Anbieter vom Kunden auszuführen, woher kommt dieser Code, wie wird er verifiziert und welche Autorität kann er während der Ausführung beobachten?

Eine nützliche Überprüfung würde fragen, ob der Anbieter signierte Releases veröffentlicht, ob Kunden unveränderliche Versionen festlegen können, ob gehostete Skripte auf unerwartete Änderungen überwacht werden, ob Verteilungsschlüssel von öffentlichen Build-Artefakten isoliert sind, ob Vorfallsmeldungen betroffene Integrationspfade identifizieren können und ob der Anbieter genügend Telemetrie bereitstellen kann, damit Kunden die Exposition eingrenzen können. Sie würde auch fragen, ob der Kunde CI-Stufen getrennt hat, sodass das Anbieter-Tool nur die Berechtigungen erhält, die es benötigt.

Die Antwort ist teils vertraglich, teils architektonisch und teils betrieblich.

Die Überprüfung sollte auch die Unterstützung bei Vorfällen als Teil des Produkts behandeln. Wenn ein CI-integrierter Anbieter einen Kompromiss offenlegt, benötigen Kunden mehr als einen allgemeinen Blog-Beitrag. Sie benötigen Artefakt-Hashes, betroffene Zeitfenster, Integrationsnamen, Erkennungsmethode, empfohlene Rotationsreihenfolge, bekannte falsche Annahmen und eine Möglichkeit zu fragen, ob ihre eigenen Repositorys oder Tokens beobachtet wurden.

Ein Anbieter kann möglicherweise nicht jedes forensische Detail offenlegen, insbesondere während laufender Strafverfolgungs- oder Kundenuntersuchungen, aber er kann ein Reaktionspaket vorbereiten, das es Kunden ermöglicht, schnell zu handeln. Der Codecov-Vorfall zeigte, dass die betriebliche Last eines kompromittierten Entwickler-Tools in Hunderten oder Tausenden von Kunden-Pipelines landet, nicht nur im Sicherheitsteam des Anbieters.

Dieses Unterstützungspaket sollte vor einem Vorfall getestet werden. Ein Anbieter sollte wissen, welche kundenorientierten Systeme dringende Mitteilungen senden können, welche Dokumentationsseiten Rotationsanleitungen hosten, welche Support-Warteschlangen Hochrisikoumgebungen priorisieren und welche Protokolle Kunden helfen können, festzustellen, ob eine Integration während des betroffenen Fensters ausgeführt wurde. Ohne diese Vorbereitung wird die Offenlegung zu einem zweiten Fehlermodus: Der Anbieter entdeckt möglicherweise den technischen Vorfall, aber Kunden verlieren immer noch Zeit, um die praktische Expositionskarte zu rekonstruieren.

Rechenschaftspflicht umfasst daher nicht nur die Verhinderung von Uploader-Manipulationen, sondern auch die Nutzbarkeit der ersten Stunde der Kundenreaktion.

Dieser Fall ist daher nicht nur eine historische Notiz über ein kompromittiertes Bash-Skript. Er ist eine Vorlage zur Beurteilung von Entwickler-Tools, die in der Automatisierung sitzen. Die sichere Frage ist nicht mehr „Vertrauen wir diesem Anbieter?“ im Abstrakten. Die sichere Frage ist: „Was könnte dieser anbietergesteuerte Code lesen, wenn er sich morgen ändert, und welche Beweise würden es uns schnell zeigen?“ Codecovs Vorfall machte diese Frage für jedes Team sichtbar, das ein Bequemlichkeitsskript neben produktionsrelevanten Geheimnissen hatte laufen lassen.