Ich arbeite im Job mit vielen Vibe Codern zusammen, und das hat mich über Wartung nachdenken lassen. Software muss auch nach dem Launch gepflegt werden, Pakete veralten, Schwachstellen werden entdeckt, und wenn du gerade erst anfängst, mit AI zu bauen, ist es leicht, an all das nicht zu denken.
Dann wurde mir klar, dass ich denselben Gedanken auf meine eigenen Projekte anwenden sollte, also bin ich ihre Git-Historie durchgegangen. Ich habe einiges gefunden, allerdings nicht das, was ich erwartet hatte, und eines davon war an dem Tag, an dem ich nachsah, immer noch offen.
Das ist also kein Beitrag mehr darüber, was andere Leute vergessen. Es geht um mich.
Ein Advisory, drei Apps
Am 14. Oktober veröffentlichte Next.js Fixes für zwei kritische Schwachstellen und eine mit hohem Schweregrad. „Kritisch“ bedeutet hier Remote Code Execution, das heißt: Unter bestimmten Bedingungen könnte ein Fremder aus dem Internet ohne Login seinen eigenen Code auf deinem Server ausführen. Der Fix kam mit Version 16.4.1.
Ich betreibe drei Apps auf Next.js, alle mit AI-Coding-Tools gebaut und alle mit derselben verantwortlichen Person, nämlich mir. Das ist passiert:
| App | Wann der Code auf eine gepatchte Version wechselte | Zeit nach dem Advisory | Live in Produktion |
|---|---|---|---|
| chandlernguyen.com | 18. Oktober | 4 Tage | 18. Oktober |
| DIALØGUE | 29. Oktober | 15 Tage | 29. Oktober |
| Prova | 3. November | 20 Tage | 3. November |
Als ich am 3. November nachsah, war Prova immer noch auf Next.js 16.2.6 festgelegt, die Version, auf der es seit Mai lief, und genau die lief auch in Produktion. pnpm audit --prod listete 5 kritische Advisories auf, alle in Next.js.
Diese Zahl klingt schlimmer als das, was ich gefunden habe, deshalb will ich fair bleiben. Als ich sie mit meinen AI-Tools einzeln durchging, traf der Großteil der kritischen nicht auf Prova zu. Es hat keine use cache-Funktionen, es läuft nicht auf Windows, und ich habe keine vom Angreifer kontrollierbaren Eingaben gefunden, die den next/og-Code erreichen. Die Advisories zur Bildoptimierung treffen auf Vercel wahrscheinlich ebenfalls nicht zu, allerdings ist das eine Schlussfolgerung aus dem Verhalten der Plattform, denn eine Aussage von Vercel dazu konnte ich nicht finden. Was eindeutig zutraf, war ein Denial-of-Service-Problem mit hohem Schweregrad in Server Actions. Jemand hätte die App also stören können, und das blieb bis zum Patch live.
Ich habe die Produktion noch am selben Tag auf Next.js 16.4.5 gebracht. Das Audit ging von 5 kritischen auf 0, und auch die meisten mit hohem Schweregrad verschwanden. Was übrig bleibt, liegt außerhalb von Next.js, und ich muss es noch abarbeiten. Es ist also besser, aber nicht sauber.
Gute Wartung kann ich das alles nicht nennen. Die schlimmsten Advisories haben Prova vor allem wegen seiner zufälligen Bauweise verfehlt, nicht weil jemand geprüft hätte. Das ist Glück, und ich weiß es nur, weil ich endlich nachgesehen habe.
Für die erste Zeile der Tabelle kann ich mir auch nicht viel anrechnen. Der Commit meiner Website vom 18. Oktober war ein allgemeines Toolchain-Upgrade, ausgehend von Next.js 16.1.6, und seine Nachricht erwähnt das Advisory nicht. Vielleicht war es einfach gutes Timing.
Warum es nicht geholfen hat, beschäftigt zu sein
Die einfache Erklärung wäre, dass Prova vernachlässigt wurde, und daran ist etwas Wahres. Im August und September gab es eine Lücke von 41 Tagen zwischen zwei Commits.
Im Oktober bricht diese Erklärung allerdings zusammen. Prova hatte in dem Monat 175 Commits. Ich habe Fixes für iOS, Abrechnung, E-Mail und Übersetzungen ausgeliefert, und die Next.js-Version bewegte sich nicht. Am 30. Oktober habe ich sogar einen Plan für die Wartung der Abhängigkeiten geschrieben. In seiner Statuszeile steht: „geplant; Umsetzung nicht begonnen.“
Aktivität ist also nicht Wartung, und ich glaube, das ist der wichtigste Punkt für alle, die mit AI bauen. Wenn du ein Feature baust, bekommst du sofort Feedback. Du siehst den Button, klickst darauf und schaust zu, wie er funktioniert. Wenn eine Schwachstelle in einem Paket bekannt wird, das du vor fünf Monaten installiert hast, bekommst du gar nichts. Die App liefert weiter Seiten aus, die Tests bleiben grün und der Build läuft durch. Nichts ist kaputt, und genau deshalb schaut niemand hin.
Es ist wie ein Rauchmelder, der nur dann einen Ton von sich gibt, wenn du ihn fragst. AI-Tools machen es viel billiger, das Haus zu bauen. Den Melder installieren sie nicht.
Das ist mir auch früher schon passiert. DIALØGUE hatte zwischen dem 6. Oktober 2025 und dem 11. Januar 2026 keinen einzigen Commit. React2Shell, eine kritische Schwachstelle in Next.js und React, wurde Anfang Dezember öffentlich. Mein Patch-Commit ist vom 11. Januar, mehr als fünf Wochen später, und der älteste Deployment-Eintrag für die Produktion, den ich noch sehen kann, stammt vom 18. Januar. Was im Dezember genau lief, kann ich dir also nicht sagen. Am meisten geholfen hat mir wahrscheinlich etwas, das nichts mit mir zu tun hatte: Vercel sagt, es habe Firewall-Regeln für alle Kunden ausgerollt, und sagt zugleich klar, dass man sich nicht darauf verlassen soll, statt zu patchen.
Eines will ich klarstellen, weil der Ausdruck „Vibe Coder“ wie eine Beleidigung klingen kann. Ich habe Programmieren in strukturierten Kursen gelernt, darunter ein Zertifikat in Cybersicherheit, diese Repos haben Tests und Review-Gates, und trotzdem ist es passiert. Ich halte es also nicht für ein Anfängerproblem. Ich glaube, es ist das, was standardmäßig passiert, wenn Software billig zu erstellen ist und niemand dafür eingeteilt ist, darauf aufzupassen.
Wie der Melder aussieht
Die gute Nachricht ist, dass eine sehr kleine Prüfung hier viel verändert.
Am 27. Oktober habe ich pnpm audit --prod in die CI meiner Website aufgenommen, also in die automatischen Prüfungen, die bei jedem Push laufen. Am 28. Oktober schlug sie fehl, wegen eines Advisorys in einer Bibliothek zum Rendern von E-Mails, die meine Website zwar mitzog, aber nie benutzte, und am 29. Oktober habe ich diese Bibliothek entfernt. Es dauerte zwei Tage, und ich musste nicht daran denken.
Clever war daran nichts. Jemand, oder etwas, muss einfach den Auftrag bekommen hinzusehen.
Paket-Updates hätten mich nicht gerettet
Würde dieser Beitrag hier enden, wäre das eine falsche Beruhigung, denn einige der unangenehmeren Fixes, die ich im Oktober gemacht habe, hatten nichts mit veralteten Paketen zu tun. Es waren Fehler in meinem eigenen Produkt.
Bei DIALØGUE zum Beispiel:
- Privilegierte Datenbankfunktionen ließen sich allein mit dem öffentlichen Schlüssel aufrufen, und ein eingeloggter Nutzer konnte Funktionen erreichen, die nur für mein Backend gedacht waren.
- Ein erstatteter Podcast konnte wieder anlaufen und fertiggestellt werden, ohne dass er erneut abgerechnet wurde, und bei einer kleinen Zahl von Podcasts ist genau das passiert.
Bei Prova hatten öffentliche Datenbankrollen Berechtigungen geerbt, die niemand ausgewählt hatte, zum Beispiel TRUNCATE, weil sie aus einem Plattform-Standard stammten. Kein Pfad in der App nutzte sie, aber sie waren da.
Kein Versions-Upgrade behebt so etwas. Diese Apps liefen mit diesen Problemen, und auch hier ging nichts kaputt. Sie kamen nur ans Licht, weil ein Security-Review gezielt danach suchte, und ich hatte für diese Produkte schon frühere Security-Reviews gemacht, die nicht alles gefunden hatten.
Wurde irgendetwas davon missbraucht? Ich weiß es nicht, und ich kann es auch nicht vollständig herausfinden. Meine Datenbank-Logs reichen nur etwa 90 Tage zurück, und manche dieser Probleme sind älter. In dem Zeitraum, den ich sehen kann, habe ich keine Aufrufe dieser Funktionen von außen gefunden. Das deckt nur ein begrenztes Zeitfenster ab und zeigt nicht, dass nichts passiert ist. Ich kann auch nicht sagen, wer oder was diese erstatteten Podcasts neu gestartet hat, auch wenn ein Retry in meinem eigenen Code meine beste Vermutung ist.
Auch das ist keine vollständige Liste. Ich arbeite noch an anderen Problemen und werde sie nicht beschreiben, solange sie offen sind.
Die Modellfrage ist nicht die, für die ich sie hielt
Ich wollte eigentlich schreiben, dass alte AI-Modelle dich mehr Geld kosten. Belegen kann ich das nicht. Ich habe nachgesehen, und in keinem dieser Repos gibt es einen Kostenvergleich von vorher und nachher, es wäre also nur geraten.
Was ich gefunden habe, ist seltsamer. Die Modelle für Skriptentwurf und Review bei DIALØGUE standen bis zum 12. Oktober auf gemini-3.5-flash. Googles Dokumentation sagt inzwischen, dass dieser Endpoint nicht abgeschaltet wird und Anfragen automatisch an gemini-3.6-flash weiterleitet. Ich weiß nicht, wann diese Weiterleitung begann, also kann ich dir nicht sagen, welches Modell wie lange geantwortet hat. Ein Modellname in deiner Konfiguration friert das Modell nicht ein.
Auch die Preise bewegen sich. Gemini 3.8 Flash, auf das ich Prova und DIALØGUE im Oktober umgestellt habe, kostet laut Preisliste bis zum 31. Dezember $0.75 pro Million Input-Tokens und $3.75 pro Million Output-Tokens. Ab dem 1. Januar 2027 verdoppelt sich das auf $1.50 und $7.50. Ich bin erst letzten Monat umgestiegen und muss noch ausrechnen, was das für meine Kosten bedeutet.
Auch ein Upgrade ist nicht ohne Risiko, und ich will nicht so tun, als wäre es das:
- Kurz nachdem ich Ask Sydney auf DeepSeek Flash umgestellt hatte, schlug in Produktion mindestens eine Frage fehl, weil das Modell mehr Suchrunden wollte, als mein Code erlaubte.
- Als ich die Embeddings von Prova umzog, schlugen die ersten Läufe fehl, nachdem die Knowledge-Base-Tabelle bereits geleert worden war, sodass die Retrieval-Qualität litt, bis ich sie wiederhergestellt hatte.
- Dieselbe Migration brachte eine Produktionseinstellung zum Vorschein, die einen Claude-Modellnamen an Googles API geschickt hätte.
Was die Prova-Migration vertrauenswürdig machte, war langweilig. Ich hatte eine dokumentierte Evaluation von vor der Umstellung, 22 von 24 Sprint-Review-Entscheidungen richtig, und danach bekam ich denselben Wert. Ohne sie hätte ich nur hoffen können.
Solltest du es überhaupt warten?
Die schwierigste Frage ist die, die ich fast weggelassen hätte. Jede App, die du auslieferst, ist ein kleines Abo, das du weiter mit deiner Aufmerksamkeit bezahlen musst, und AI hat es sehr leicht gemacht, noch mehr davon abzuschließen.
Bei STRAŦUM habe ich mich anders entschieden. Ich habe es eingestellt und v1 als Referenzimplementierung veröffentlicht. Im Repository steht, dass es nicht als Produktionsdienst gewartet wird, und seine Sicherheitsdatei listet die mir bekannten Advisories auf, darunter Build-Time-Probleme in Abhängigkeiten ohne verfügbaren Fix, deren praktisches Risiko dort als gering eingestuft wird. Ich halte das für ein völlig ehrliches Ergebnis. Die unehrliche Version ist eine App, die weiter Anmeldungen annimmt, während niemand auf sie aufpasst.
Was ich am Montag tun würde
Wenn du etwas mit AI ausgeliefert hast und Leute es benutzen, würde ich mit dieser Liste anfangen. Nichts davon muss perfekt sein.
- Lass das Audit einmal laufen, heute.
npm audit --omit=devoderpnpm audit --prod, in jedem Repo, das live ist. Frag dann dein AI-Tool, welche Ergebnisse auf die Bauweise deiner App zutreffen, denn das werden nicht alle sein. - Mach die Prüfung automatisch. Nimm sie in die CI auf, damit sie fehlschlagen kann, ohne dass du daran denken musst. Bei einer App, die du selten anfasst, richte zusätzlich einen geplanten Lauf ein, denn eine Prüfung, die nur bei einem Push läuft, hilft in einem ruhigen Monat nicht.
- Lies deine Berechtigungen, nicht nur deine Pakete. Frag dich, was jemand allein mit deinem öffentlichen Schlüssel und ohne Konto tun kann. Teste das dann auf einer lokalen Kopie, statt es anzunehmen.
- Durchsuche deine Historie nach Secrets. Wenn jemals ein echter Schlüssel committet wurde, widerrufe ihn. Die Zeile zu löschen reicht nicht.
- Finde heraus, wie weit deine Logs zurückreichen, bevor du sie brauchst. Davon hängt ab, ob du die Frage, ob etwas missbraucht wurde, jemals beantworten kannst.
- Halte für jedes AI-Feature eine kleine Evaluation bereit. Schon 20 echte Beispiele mit bekannten guten Antworten zeigen dir, ob ein Modellwechsel etwas verschlechtert hat.
- Prüfe regelmäßig die Seiten deines AI-Anbieters zu Abkündigungen und Preisen. Trag es in deinen Kalender ein. Wenn du Gemini 3.8 Flash nutzt, ist der 1. Januar schon ein guter erster Termin.
- Entscheide für jede App: behalten oder einstellen. Wenn du nicht auf sie aufpassen wirst, nimm sie vom Netz oder sag es offen.
Ich finde noch heraus, wie viel davon sich einem Agenten nach Zeitplan überlassen lässt. Ich weiß aber, dass das Schreiben des Plans am 30. Oktober nichts gepatcht hat.
Wenn du mit AI baust: Wann hast du zuletzt etwas geprüft, das du bereits ausgeliefert hast, und was hast du gefunden? Das würde ich wirklich gern wissen, besonders wenn du einen besseren Melder hast als ich.