Vercels Sicherheitslücke und warum wir nicht mit „unsensiblen“ Geheimnissen spielen
Vercel wurde getroffen und der Dreh- und Angelpunkt war ein KI-Tool eines Drittanbieters. Aus diesem Grund hätten die strengen Sicherheitsprotokolle von Sweent für die Sicherheit unserer Kunden gesorgt, während andere panisch die Schlüssel rotierten.
Wir sind mit der Nachricht aufgewacht, dass Vercel getroffen wurde. Wenn Sie in der Welt der Webentwicklung tätig sind, ist das so, als ob der Haupttresor der Bank gerade ausgewählt wurde. Vercel ist kein Amateurunternehmen; sie sind das Rückgrat für Millionen von Websites, einschließlich des Next.js Ökosystems. Aber selbst die Giganten können ins Straucheln geraten, wenn die Bequemlichkeit das Tauziehen gegen die Sicherheit gewinnt.
Die Sicherheitslücke begann nicht mit einem direkten Treffer auf die Server von Vercel. Es begann mit einem KI-Tool eines Drittanbieters namens Context.ai. Ein Vercel-Mitarbeiter hatte es über OAuth mit seinem Google Workspace verbunden. Die Angreifer griffen Context.ai an, übertrugen diese OAuth-Verbindung in das Google-Konto des Mitarbeiters und von dort aus hatten sie eine Karte zum internen Königreich. Es ist ein klassischer Dreh- und Angelpunkt der Lieferkette und es ist chaotisch.
Aber hier ist der Teil, der uns bei Sweent wirklich beschäftigt: Die Angreifer waren in der Lage, Umgebungsvariablen zu lesen, die nicht als „sensibel“ markiert waren. Vercel hat ein System, in dem Entwickler wählen können, ob eine Variable sensibel ist oder nicht. Wenn Sie dieses Kästchen nicht ankreuzen, werden diese Geheimnisse so gespeichert, dass sie lesbar sind, falls ein Angreifer hineinkommt. Bei Sweent schauen wir uns diese Designwahl an und sehen ein massives, unnötiges Risiko. Wir glauben nicht daran, Entwicklern die Möglichkeit zu geben, der Einfachheit halber weniger sicher zu sein.
Der Irrtum des „unsensiblen“ Geheimnisses
Im Vercel-Dashboard wird zwischen sensiblen und nicht sensiblen Umgebungsvariablen unterschieden. Die Idee ist, dass einige Dinge, wie ein öffentlicher API-Schlüssel oder eine unkritische Konfigurationszeichenfolge, nicht die hohe Verschlüsselung benötigen, die ein Datenbankkennwort benötigt. Aber in der Praxis? Entwickler sind beschäftigt. Sie haben den Versandcode um 2:00 Uhr. Sie gehen den Weg des geringsten Widerstands. Wenn die Standardeinstellung nicht „Maximale Sicherheit“ ist, werden Geheimnisse durchgesickert. Die Frage ist nicht ob, sondern wann.
Wir haben das bei Dutzenden von Projekten gesehen, bevor sie zu uns kamen. Ein Entwickler ist der Meinung, dass ein bestimmtes Token ein „geringes Risiko“ darstellt, sodass er sich nicht um die zusätzliche Schutzebene kümmert. Dann kommt es zu einer Sicherheitsverletzung, und dieses Token mit „geringem Risiko“ wird zum Dreh- und Angelpunkt für eine vollständige Systemübernahme.
Bei Sweent ist unser Protokoll einfach: So etwas wie eine unsensible Umgebungsvariable gibt es nicht. Wenn es sich um eine Variable handelt, die sich in einer .env-Datei oder einer CI/CD-Pipeline befindet, wird sie als kritisches Geheimnis behandelt. Zeitraum. Wir bieten keinen praktischen Schalter an, bei dem die Schlüssel nicht sichtbar sind. Durch die Durchsetzung einer strengen Richtlinie, bei der jede einzelne Variable verschlüsselt und eingeschränkt ist, vermeiden wir das menschliche Versagen, das bei dem Vercel-Vorfall zur Exfiltration von Daten geführt hat. Hätte es ein Angreifer während eines ähnlichen Verstoßes geschafft, in eine unserer Umgebungen einzudringen, hätte er eine Wand aus verschlüsselten Daten gefunden, die er nicht lesen konnte, und nicht eine Liste von „unsensiblen“ Schlüsseln, mit denen er seinen Angriff eskalieren könnte.
Bekämpfung von KI-beschleunigten Angreifern mit Protokoll
Der CEO von Vercel erwähnte, dass sich die Angreifer mit „überraschender Geschwindigkeit“ bewegten und wahrscheinlich durch KI beschleunigt wurden. Das ist die neue Realität. Wir verteidigen uns nicht mehr nur gegen einen Typen in einem Hoodie, der manuell Befehle eingibt. Wir schützen uns vor automatisierten Agenten, die eine Systemarchitektur analysieren, Schwachstellen identifizieren und innerhalb von Sekunden einen Exploit ausführen können.
Wenn sich der Gegner mit Maschinengeschwindigkeit bewegt, kann sich Ihre Verteidigung nicht darauf verlassen, dass ein Mensch entscheidet, welches Kästchen angeklickt werden soll. Es muss in die Infrastruktur integriert werden. Aus diesem Grund haben wir unsere internen Workflows so aufgebaut, dass davon ausgegangen wird, dass eine Sicherheitsverletzung immer möglich ist. Wir überwachen nicht nur nach Eindringlingen, sondern reduzieren auch die Angriffsfläche, sodass die KI nichts mehr finden kann, sobald sie durch die Tür gekommen ist.
Eines der größten Probleme beim Vercel-Angriff war die OAuth-Verbindung. OAuth ist unglaublich nützlich, aber es ist eine riesige Sicherheitslücke, wenn es nicht mit äußerster Disziplin verwaltet wird. Sie klicken auf eine Schaltfläche, um ein neues KI-Produktivitätstool auszuprobieren, und plötzlich hat dieses Tool Lesezugriff auf Ihren gesamten Google Workspace. Wenn dieses Tool gehackt wird — wie es Context.ai getan hat — ist Ihr gesamtes Unternehmen gefährdet.
Unser Team bei Sweent setzt eine Zero-Trust-Richtlinie für Integrationen von Drittanbietern durch. Wir lassen nicht zu, dass „glänzende neue Tools“ ohne ein vollständiges Sicherheitsaudit mit unseren Kernsystemen verbunden werden. Und selbst dann beschränken wir den Umfang auf das absolute Minimum. Wenn ein Tool nur einen Kalender lesen muss, erhält es keinen Zugriff auf den gesamten Workspace. Das klingt nach viel Arbeit und ist es auch. Aber es ist der Unterschied zwischen einem kleinen Vorfall und einer Lösegeldforderung von 2 Millionen Dollar von einer Gruppe wie ShinyHunters.
Die geheime 24-Stunden-Rotationsregel
Selbst mit der besten Verteidigung können Dinge schief gehen. Ein professionelles Team zeichnet sich nicht nur dadurch aus, wie es einen Verstoß verhindert, sondern auch, wie es darauf reagiert. Vercel empfahl seinen Kunden, ihre Anmeldeinformationen sofort zu wechseln. Aber „sofort“ ist in der Unternehmenswelt ein vager Begriff. Für einige Unternehmen bedeutet das nächste Woche. Für andere bedeutet es nach dem langen Wochenende.
Bei Sweent haben wir eine harte Regel: Im Falle eines vermuteten Kompromisses wird jedes einzelne Geheimnis, jeder API-Schlüssel und jede Datenbankzeichenfolge innerhalb von 24 Stunden rotiert. Wir warten nicht auf eine vollständige Obduktion. Wir warten nicht ab, ob die Daten „tatsächlich“ exfiltriert wurden. Wir bewegen uns schneller als der Angreifer.
Wenn ein Angreifer merkt, dass er einen Schlüssel hat, ist dieser Schlüssel bereits tot. Wir verwenden automatisierte Skripte und Infrastructure-as-Code, um dies zu handhaben. Hätten wir Vercel während dieses Sicherheitsverstoßes verwendet, wären die Schlüssel unserer Kunden durchsucht und gesichert worden, bevor die Nachricht überhaupt in den großen Tech-Blogs veröffentlicht wurde. Geschwindigkeit ist die einzige Verteidigung gegen einen Angreifer, der sich mit KI-gesteuerter Geschwindigkeit bewegt.
Sicherheit in der Lieferkette und die 7-Tage-Regel
Der Vercel-Verstoß gab auch Anlass zu Bedenken hinsichtlich der NPM-Lieferkette. Da Vercel Next.js besitzt, könnte ein Angreifer mit den richtigen Tokens potenziell eine „vergiftete“ Version an Millionen von Entwicklern versenden. Dies ist die nukleare Option der Cyberkriegsführung. Wenn Sie jedes Mal, wenn eine neue Version veröffentlicht wird, blind Ihre Abhängigkeiten aktualisieren, spielen Sie russisches Roulette mit Ihrer Codebasis.
Wir schützen unsere Kunden, indem wir eine obligatorische Verzögerung für alle unkritischen Abhängigkeitsupdates einführen. In der Regel warten wir mindestens 7 Tage, bevor wir neue Versionen der wichtigsten Bibliotheken herunterladen. Warum? Weil die meisten Angriffe auf die Lieferkette innerhalb dieser ersten Woche identifiziert und neutralisiert werden. Da wir nicht die „Early Adopters“ jedes kleineren Patches sind, stellen wir sicher, dass unsere Kunden nicht die ersten sind, die betroffen sind, wenn ein Paket entführt wird.
Es mag sich so anfühlen, als wären wir zu vorsichtig, aber schauen Sie sich die Alternative an. ShinyHunters verkauft angeblich die interne Datenbank von Vercel für 2 Millionen Dollar. Sie haben 580 Mitarbeiterdatensätze, interne Dashboards und Quellcode. Das ist ein katastrophaler Fehler, der durch strengere interne Protokolle und einen weniger „bequemen“ Ansatz bei der Geheimhaltung hätte abgemildert werden können.
Warum wir die „schwierigen“ Teile nicht überspringen
Sicherheit wird oft als Reibungspunkt angesehen. Sie verlangsamt die Entwicklung. Es macht es schwieriger, neue Tools auszuprobieren. Es fügt dem Bereitstellungsprozess weitere Schritte hinzu. Und genau aus diesem Grund überspringen so viele Startups die schwierigen Teile. Sie wollen schnell handeln und Dinge kaputt machen. Aber wenn das, was Sie kaputt machen, das Vertrauen Ihrer Kunden ist, haben Sie möglicherweise keine Chance, es zu reparieren.
Wir haben Sweent auf der Idee aufgebaut, dass die digitale Transformation nicht auf Kosten der Sicherheit gehen sollte. Wir kümmern uns um die Reibung, damit unsere Kunden das nicht tun müssen. Wir sind diejenigen, die die Sicherheitsaudits der KI-Tools durchführen. Wir sind diejenigen, die die obligatorische Verschlüsselung für jede Umgebungsvariable durchsetzen. Wir sind diejenigen, die auf dem Laufenden bleiben und die Schlüssel innerhalb von 24 Stunden wechseln, während der Rest der Branche immer noch die Schlagzeilen liest.
Wenn Sie gerade auf Vercel sind, sollten Sie wahrscheinlich in Ihrem Dashboard nachschauen. Überprüfe jede einzelne Variable. Markiere sie alle als sensibel. Trennen Sie alle OAuth-Verbindungen, die Sie nicht unbedingt benötigen. Wenn Sie sich jedoch keine Gedanken darüber machen möchten, ob Ihre Entwickler um 2:00 Uhr morgens das richtige Kästchen angekreuzt haben, benötigen Sie einen Partner, der Sicherheit nicht als optionales Feature betrachtet.
Am Ende des Tages wird sich Vercel wahrscheinlich davon erholen. Sie haben Elite-Ingenieure und viel Kapital. Aber für ein kleineres Unternehmen ist ein solcher Verstoß ein Todesurteil. Warten Sie nicht auf die nächste große Schlagzeile, um zu erkennen, dass Ihre „unsensiblen“ Variablen eine Belastung darstellen. Die Angreifer bewegen sich mit Maschinengeschwindigkeit. Bist du das?
Häufig gestellte Fragen
Die Angreifer waren nicht direkt hinter Vercel her. Sie griffen in Context.ai ein, ein KI-Tool eines Drittanbieters, das ein Vercel-Mitarbeiter über OAuth mit seinem Google Workspace verbunden hatte. Von diesem OAuth-Zuschuss aus griffen die Angreifer in das Google-Konto des Mitarbeiters ein und hatten von dort aus eine Karte zu den internen Systemen von Vercel. Es ist ein klassischer Pivot der Lieferkette — Sie sind nur so sicher wie die am wenigsten geprüfte Integration, bei der ein Teammitglied auf „Zulassen“ geklickt hat.
Entwicklern die Möglichkeit zu geben, zwischen „verschlüsselten“ und „lesbaren“ Geheimnissen umzuschalten, ist eine Designentscheidung, bei der jeder Entwickler jedes Mal darauf setzt, dass er unter dem Versanddruck um 2 Uhr morgens die sichere Option auswählt. Das tun sie nicht. Der Vercel-Angriff bestätigte dies: Die Angreifer gingen mit Werten, die technisch als „nicht sensibel“ gekennzeichnet waren, sich aber in Kombination mit anderen Erkenntnissen als sehr empfindlich herausstellten. Unsere Richtlinie: So etwas wie ein unsensibles Geheimnis gibt es nicht — alles in einer.env- oder CI/CD-Pipeline wird auf die gleiche Weise verschlüsselt, ohne Umschalten.
Jede Taste dreht sich innerhalb von 24 Stunden, Punkt. Wir warten nicht auf eine Obduktion, um zu bestätigen, ob Daten tatsächlich exfiltriert wurden — zu dem Zeitpunkt, an dem das geklärt ist, hat der Angreifer das, was er gestohlen hat, bereits verwendet. Infrastructure-as-Code und automatische Rotationsskripte machen das Ganze mechanisch, nicht heroisch. Wenn ein Angreifer merkt, dass er einen Schlüssel hat, ist dieser Schlüssel bereits tot.
Die meisten Supply-Chain-Angriffe im npm-Ökosystem werden innerhalb der ersten Woche nach einer böswilligen Veröffentlichung erkannt und neutralisiert — weil andere Teams, die engere Kanarien verwenden, das Problem finden und die Registry das Paket zieht. 7 Tage zu warten, bevor neue Hauptversionen abgerufen werden, bedeutet, dass unsere Kunden nicht die ersten sind, die betroffen sind, wenn ein beliebtes Paket gekapert wird. Das kostet eine kleine Verzögerung und vermeidet eine Art von Angriffen vollständig.
Behandeln Sie jeden OAuth-Grant als permanente Lücke in Ihrem Umkreis, bis das Gegenteil bewiesen ist. Führen Sie eine Sicherheitsüberprüfung des Tools durch, bevor Sie es verbinden. Beschränken Sie die Bereiche auf das absolute Minimum — wenn ein Tool nur einen Kalender benötigt, wird nicht der gesamte Workspace benötigt. Überprüfe alle aktiven Zuschüsse vierteljährlich und entferne alles, was nachweislich nicht genutzt wird. Dank der praktischen Integration mit nur einem Klick wurde Context.ai zum Dreh- und Angelpunkt von Vercel. Sorgen Sie bewusst dort für Reibung, wo es Sie am wenigsten kostet und am meisten spart.