Kategorie: Einblicke

Wie lässt sich Umgebungsdrift zwischen Staging und Produktion vermeiden? Ein Entwickler hat dafür eine Inter-Mesh-Deployment-Pipeline entworfen, die auf seiner eigenen Infrastruktur läuft.

Der Autor betreibt rund 72 Anwendungen in zwei Umgebungen. Offiziell sieht der Prozess so aus: erst Staging, dann testen, dann Produktion. In der Praxis blieb dieser Weg oft ungenutzt. Es gab keine technische Möglichkeit, die Reihenfolge zu erzwingen. So entwickelten sich die beiden Umgebungen auseinander – ein Fall von Umgebungsdrift.

Du kennst das aus eigenen Projekten: Ohne automatisierte Kontrolle weicht die Konfiguration von Staging und Produktion voneinander ab. Neue Abhängigkeiten werden nur in Produktion ergänzt, Umgebungsvariablen unterscheiden sich, und plötzlich ist Staging kein verlässlicher Testort mehr. Genau dieses Problem wollte der Entwickler lösen.

Das Problem: Umgebungsdrift und fehlende Kontrolle

Umgebungsdrift entsteht, wenn zwei Umgebungen, die identisch sein sollten, durch manuelle Eingriffe oder fehlende Automatisierung voneinander abweichen. Im Fall des Autors war die Theorie klar: Jede Änderung sollte zuerst nach Staging, dann nach sorgfältigem Testen nach Produktion. Aber keine technische Hürde erzwang diesen Ablauf. Entwickler konnten direkt auf Produktion deployen, wenn sie es eilig hatten, oder Konfigurationen lokal ändern, ohne sie zu dokumentieren.

Die Folgen waren vorhersehbar: Staging wurde selten genutzt, veraltete Daten oder fehlerhafte Abhängigkeiten machten Tests unzuverlässig, und niemand wusste mehr, was auf welcher Umgebung lief. Bei so vielen Anwendungen war das ein erhebliches Risiko. Ein Fehler, der nur in Produktion auftrat, konnte teuer werden.

Um das zu beheben, brauchte der Autor eine Möglichkeit, den gewünschten Ablauf technisch zu erzwingen und gleichzeitig vollständige Transparenz über alle Deployments zu erhalten.

Die Idee: Eine NATS-Bridge als Verbindungsstück

Die Lösung bestand darin, einen speziellen Connector zu entwickeln, der als Brücke zwischen den beiden Meshes fungiert. Ein Mesh ist ein Netzwerk aus Diensten, die über gemeinsame Kommunikationsprotokolle verbunden sind. Der Connector nutzt NATS, einen Message-Broker, um Nachrichten zwischen den Umgebungen auszutauschen.

Durch diese NATS-Bridge kann die Produktionsumgebung direkt Anfragen an die Staging-Umgebung senden. Ein Build und Test einer Komponente lässt sich so anstoßen, ohne dass ein Mensch eingreift. Der Autor nutzte diesen Mechanismus zuerst, um neue Anwendungen auszurollen. Denn wenn die Pipeline weiß, wie man eine neue App korrekt installiert, kann sie dieselbe Logik auf bestehende Anwendungen anwenden.

Das Besondere daran ist, dass nicht nur der initiale Deploy automatisiert wird, sondern auch spätere Updates. In der Produktionsoberfläche gibt es eine Schaltfläche „Pull from Staging“. Sie löst einen vollständig überwachten Prozess aus, der die Artefakte von Staging abruft und in Produktion übernimmt. Jeder Schritt wird protokolliert, sodass ein lückenloses Audit möglich ist.

Sicherheit durch Privilegientrennung: das proc-mesh-Konzept

Ein so flexibles Werkzeug bringt Sicherheitsfragen mit sich. Der Autor setzt auf ein abgestuftes Rechtsmodell, den „layered approach to security“. Eine zentrale Rolle spielt eine Komponente namens proc-mesh, die mit minimalen Rechten läuft. Sie hat keinerlei Netzwerkzugriff und kommuniziert nur über einen Unix-Socket.

Alle anderen Komponenten in der Pipeline haben das Flag NoNewPrivileges=yes gesetzt. Das bedeutet, dass sie keine zusätzlichen Rechte erlangen können, selbst wenn sie versuchen, bestimmte Systemaufrufe zu nutzen. Für privilegierte Aktionen, die nötig sind, setzt der Autor doas ein – ein Programm zur kontrollierten Erhöhung von Rechten. proc-mesh ist die einzige Instanz, die solche Aufrufe durchführen darf.

Dieses Sicherheitskonzept hat einen interessanten Effekt: Selbst wenn ein Angreifer es schafft, eine Komponente zu kompromittieren und Rechte zu erlangen, verliert er gleichzeitig die Fähigkeit, über das Netzwerk zu kommunizieren. Denn die Rechteausweitung läuft nur über den Unix-Socket von proc-mesh, der selbst keine Netzwerkverbindung hat. So wird ein potenzieller Schaden begrenzt.

Deployments per API und der Wert von Audit-Logs

Die Pipeline lässt sich nicht nur über die grafische Oberfläche steuern, sondern auch per API oder über das MCP-Protokoll. MCP steht für Model Context Protocol, ein Protokoll, das es KI-Agenten ermöglicht, mit Tools zu interagieren. In diesem Fall können automatisierte Agenten Deployments anstoßen, was die Integration in CI/CD-Workflows erleichtert.

Jeder dieser Deployments erzeugt eine vollständige Audit-Liste. Der Autor zeigt in einem Diagramm, wie die einzelnen Schritte ablaufen: schwarze Pfeile zeigen ausgehende Verbindungen, rote Pfeile den Rückweg. Artefakte werden nicht über Git-Releases übertragen, sondern als Binärdaten direkt über die NATS-Bridge verschickt. Das ist schneller und vermeidet die Abhängigkeit von einer zusätzlichen Release-Verwaltung.

Dank der Audit-Logs lässt sich jederzeit nachvollziehen, welche Version einer Anwendung auf welcher Umgebung läuft und wie der Weg dorthin aussah. Das erhöht das Vertrauen in die Deployments und erleichtert die Fehlersuche, falls etwas schiefgeht.

Bulk-Operationen: Wie sich die Umgebungen wieder angleichen lassen

Nachdem der Autor die Pipeline für neue Anwendungen etabliert hatte, konnte er sie nutzen, um die bestehenden Umgebungen zu synchronisieren. Da die Pipeline weiß, wie eine korrekte Installation aussieht, kann sie jede Anwendung prüfen und bei Bedarf anpassen. Dies geschieht in einem Bulk-Verfahren: Zuerst wird jede App in der Staging-Umgebung aufgesetzt und getestet, dann nach Produktion übernommen.

Der Prozess ist so gestaltet, dass Fehler in Staging abgefangen werden, bevor sie Auswirkungen auf Produktion haben. Das entspricht der ursprünglichen Idee einer sauberen Trennung. Nach und nach bringt er alle 72 Anwendungen auf den gewünschten Zustand und beseitigt die Umgebungsdrift.

Der Aufwand dafür ist überschaubar, weil die Pipeline einen einheitlichen Weg für alle Apps erzwingt. Das zeigt, dass ein gut durchdachtes Deployment-System nicht nur Neubauten beschleunigt, sondern auch Altlasten systematisch abtragen kann.

Die Grenze des Systems: Selbst-Deployment von Mesh-Komponenten

Natürlich gibt es auch blinde Flecken. Der Autor merkt an, dass seine Komponente plug-mesh sich selbst nicht über die neue Pipeline deployen kann. Sie verlässt sich noch auf die alte Gitea-Runner-Integration. Um das zu ändern, hätte er eine isolierte NATS-Bridge zwischen einer neuen Instanz von plug-mesh und der bestehenden Komponente einrichten müssen.

Die Idee war, die neue Komponente in dieser isolierten Umgebung zu testen, bevor sie die alte ersetzt. In der Praxis stellte sich heraus, dass er diese Komponente selten anpasst. Daher hat er die Selbst-Deployment-Funktion nicht weiter verfolgt. Er akzeptiert, dass Staging in manchen Fällen kaputtgehen kann – aber genau dafür ist es da: um Fehler zu entdecken, bevor sie in Produktion gelangen.

Diese pragmatische Entscheidung zeigt, dass nicht jede theoretische Verbesserung sofort umgesetzt werden muss. Oft reicht es, eine saubere Basis zu haben und die wichtigsten Prozesse zu automatisieren.

Diese Inter-Mesh-Deployment-Pipeline zeigt, wie sich Umgebungsdrift vermeiden lässt. Die Kombination aus NATS-Bridge, Privilegientrennung und Logging bietet eine robuste Grundlage. Die Prinzipien lassen sich auch auf kleinere Setups übertragen: den Weg über Staging erzwingen, Rechte trennen, alles protokollieren. So wird Deployen zur Routine statt zum Risiko.

Quelle: blog.zm.is

Die Ausgaben für KI-gestützte Entwicklungswerkzeuge steigen innerhalb von sechs Monaten um das Zehnfache. Das Unternehmen baut eine zentrale Steuerungsebene auf, statt die Werkzeugvielfalt einzuschränken. Sie schafft Transparenz und Kontrolle, ohne die Wahlfreiheit der Entwickler zu opfern.

JetBrains, Hersteller von IDEs wie IntelliJ IDEA und PyCharm, nutzt selbst KI-Tools in der Softwareentwicklung. Dort explodierten die Kosten. Ende 2025 war es ein überschaubarer Posten, wenige Monate später ein ernstes Thema für das Finanzteam. JetBrains zog nicht die Bremse, reduzierte die Werkzeugvielfalt nicht auf ein oder zwei Produkte, sondern wählte einen anderen Weg.

Eine Kostenexplosion ohne Erklärung

Der Auslöser war eine einfache Beobachtung: Die meisten Entwickler nutzten zwischen drei und fünf verschiedene KI-Tools pro Monat. Mal ein Code-Vervollständiger, mal ein Chat-Assistent, mal ein Agent für automatisierte Refactorings. Ab Januar 2026 stieg der Token-Verbrauch stark an – zeitgleich mit dem Erscheinen neuer Modelle wie Claude Opus 4.5 und 4.6. Diese liefern bessere Ergebnisse, verbrauchen aber auch deutlich mehr Tokens pro Anfrage. Die KI-Ausgaben des Unternehmens vervielfachten sich.

Das eigentliche Problem war nicht die Höhe der Summe, sondern die Intransparenz. Wer gab wie viel aus? Welches Tool verursachte die größten Kosten? Waren die Ausgaben gerechtfertigt? Auf diese Fragen gab es zunächst keine Antwort. JetBrains sammelte vier Tage lang manuell Nutzungs- und Kostendaten aus verschiedenen Providerkonten und trug sie in Spreadsheets ein. Das Ergebnis war eine Momentaufnahme, die veraltet war, sobald das Dokument fertig war.

Vom Excel-Sheet zum Live-Dashboard

Die manuelle Datensammlung war nur der erste Schritt. JetBrains automatisierte den Prozess über die APIs der KI-Provider. Die Daten flossen in interne Dashboards, die aktuelle und prognostizierte Ausgaben anzeigten. Teams und Manager sahen auf einen Blick, welche Abteilung, welches Projekt und welches Tool wie viel Tokens konsumierte. Das war ein Fortschritt – die Kosten wurden sichtbar.

Aber Sichtbarkeit allein reicht nicht. Die Dashboards waren ein Beobachtungsposten, kein Steuerungselement. Die Anfragen der Entwickler gingen weiterhin direkt vom Werkzeug zum Provider. Um Limits zu setzen oder Budgets zu verteilen, braucht man eine Instanz zwischen den Menschen und den Modellen. Diese Instanz baute JetBrains als Nächstes auf. Ein interner Entwickler hatte bereits ein kleines Wrapper-Tool geschrieben, um eigene KI-Aufrufe zu standardisieren. Daraus wurde die Central CLI – eine gemeinsame Kommandozeilen-Schnittstelle für hauseigene und externe KI-Tools.

Central CLI: Ein gemeinsamer Zugang

Die Idee ist einfach: Alle KI-Anfragen, die über die Central CLI laufen, werden durch die bestehende KI-Plattform von JetBrains geroutet. Dadurch entsteht ein zentraler Kontrollpunkt zwischen Entwicklern und Modellanbietern. Die Plattform sieht den Datenverkehr und kann ihn steuern. JetBrains kann sein eigenes KI-Gutschriftensystem auf Drittanbieter-Tools anwenden, Manager können Ausgabenlimits festlegen und den Verbrauch in Echtzeit überwachen.

Die Central CLI ist ein Pflichtweg, aber kein Verbotsweg. Entwickler können aus einer breiten Palette unterstützter Werkzeuge wählen – sie müssen sie nur über dieses eine Tor einbinden. Das trennt zwei Aspekte: die Auswahl des besten Werkzeugs für eine Aufgabe und die Kontrolle über die Kosten. Bei JetBrains zeigte sich das schnell. Innerhalb weniger Wochen übernahmen mehr als 1.000 Entwickler die Central CLI. Sie wurde angenommen, weil sie den Arbeitsfluss nicht behindert, sondern lediglich eine Buchhaltungs- und Steuerungsebene darunterlegt.

Warum JetBrains nicht auf Werkzeugverbote setzt

In anderen Firmen sieht man oft den Reflex, die Zahl der KI-Tools auf ein oder zwei Standardprodukte zu reduzieren. Accenture hat seine Mitarbeiter laut ITPro aufgefordert, unnötige KI-Nutzung einzuschränken. Uber führte nach vier Monaten, in denen das gesamte Jahresbudget für KI aufgebraucht war, monatliche Limits ein. Solche Maßnahmen sind verständlich, aber sie lösen das Problem auf Kosten der Produktivität. Der Markt für KI-Tools ist jung und verändert sich rasant. Welches Werkzeug für eine Aufgabe ideal ist, kann sich in wenigen Monaten ändern. Wer auf ein einziges Tool setzt, riskiert, die nächste Welle besserer Modelle zu verpassen.

JetBrains argumentiert, dass eine zentrale Zugriffsebene Werkzeugvielfalt und Kostenkontrolle verbindet. Entwickler behalten ihre Freiheit, aber jede Anfrage läuft durch einen gemeinsamen Kanal, der Governance ermöglicht. Das ähnelt dem Konzept eines API-Gateways im Microservices-Umfeld: Eine gemeinsame Schicht über verschiedenen Diensten setzt Sicherheitsrichtlinien, Rate-Limiting und Monitoring durch, ohne die Dienste selbst zu verändern. Die Central CLI ist im Grunde ein Gateway für KI-Ressourcen.

Was du daraus lernen kannst

Der Fall JetBrains ist Teil eines größeren Trends. Die FinOps Foundation hat generative KI in ihr Regelwerk aufgenommen und empfiehlt zentralisierte Ansätze, um KI-Nutzung und -Kosten zu verfolgen. Auch in deinem Unternehmen dürfte das Thema bald anstehen. Wenn du Softwarearchitekt oder Team-Lead bist, lohnt es sich, frühzeitig über eine ähnliche Steuerungsebene nachzudenken. Du musst nicht sofort ein eigenes CLI bauen, aber stelle dir die Fragen: Wie fließen KI-Anfragen in unserer Umgebung? Wer hat welche Budgets? Wo entstehen unkontrollierte Ausgaben?

Eine zentrale Zugriffsschicht ist ein möglicher Baustein. Du kannst auch Richtlinien definieren, welche Tools eingesetzt werden dürfen – aber das sollte nicht der erste Schritt sein. Erhöhe zuerst die Transparenz. Starte mit einer einfachen Kostenerfassung, wie JetBrains es getan hat. Arbeite dich zu einem automatisierten Dashboard vor. Erst wenn du siehst, wo das Geld hinfließt, kannst du sinnvoll eingreifen. Und wenn du eine Steuerungsmöglichkeit einführst, sorge dafür, dass sie Entwickler nicht ausbremst. Sonst sinkt die Akzeptanz.

Ein erster Schritt – nicht die ganze Lösung

Trotz des Erfolgs: Die Central CLI ist keine vollständige Lösung. Einige terminalbasierte Agenten und persönliche Abonnements laufen weiterhin am System vorbei. Auch die Frage, wie KI-Budgets fair auf Teams verteilt werden, ist noch nicht geklärt. JetBrains arbeitet daran, aber es ist ein iterativer Prozess. Das sollte dich nicht abschrecken. Ein Unternehmen wie JetBrains, das selbst Entwicklerwerkzeuge herstellt, kämpft mit diesen Herausforderungen – das zeigt, wie grundlegend das Problem ist.

Am Ende geht es nicht darum, die KI-Nutzung zu drosseln, sondern sie zu steuern. JetBrains hat gezeigt, dass eine zentrale Zugriffsebene Kontrolle und Flexibilität ermöglicht. Für dich als Architekt heißt das: Bau keine Verbote, baue Tore. Gib deinen Teams Werkzeuge, aber sorge dafür, dass alle durch eine messbare, steuerbare Schnittstelle gehen. So bleibt die KI-Revolution produktiv und wirtschaftlich tragfähig.

Quelle: infoq.com

205 Millisekunden reichen, um eine komplette Sitzung zu kippen. Diese Zeitspanne verursachte Probleme bei der Einführung von Device Bound Session Credentials (DBSC) bei Report URI. Der Erfahrungsbericht zeigt, wie die Theorie einer Sicherheitsverbesserung an der Realität eines produktiven Webservers scheitert.

Arbeitest du in einem Browser-Tab, wechselst kurz zur Seite, bist du plötzlich ausgeloggt. Kein Fehler, keine Meldung – einfach die Sitzung weg. Genau das erlebten die Beta-Nutzer von Report URI nach der DBSC-Einführung. Die Ursache war kein klassischer Programmierfehler, sondern ein Zusammenspiel aus Browser-Verhalten, Netzwerk-Latenz und einer Sicherheitsarchitektur, die strenger sein will als nötig.

DBSC bindet Sitzungscookies an das Gerät des Nutzers. Ein normales Session-Cookie ist ein reines Bearer-Token – ein Wert, den jeder Besitzer beliebig verwenden kann. DBSC verlangt den Besitz eines privaten Schlüssels, der im sicheren Hardware-Bereich des Geräts liegt. Infostealer-Malware, die Cookies aus dem Browser stiehlt, läuft damit ins Leere. Die Implementierung hat Tücken, die die Spezifikation nicht ahnen lässt.

DBSC verstehen: Einphasige Registrierung, zweiphasiger Refresh

Die Spezifikation liest sich zunächst so, als sei die Registrierung ein zweistufiger Prozess und der Refresh eine einzelne Anfrage. In der Praxis ist es umgekehrt: Die Registrierung ist ein einzelner Header, den der Server an eine erfolgreiche Antwort anhängt. Der Browser generiert daraufhin einen Schlüssel, signiert damit ein JWT und sendet es an den Registrierungs-Endpoint. Der Server prüft, speichert die Bindung und antwortet mit einem neuen Cookie. Ein einziger Roundtrip.

Der Refresh dagegen ist zweistufig. Der Browser schickt zunächst eine POST-Anfrage an den Refresh-Endpoint, ohne eine Challenge zu besitzen. Der Server antwortet mit Statuscode 403 und einem Header, der eine Herausforderung enthält. Erst dann signiert der Browser diese Herausforderung und sendet eine zweite POST-Anfrage. Der Server prüft die Signatur und liefert ein frisches Cookie. Das bedeutet: Der 403-Status ist hier der normale, gesunde Weg, kein Fehler. Wer sich das nicht einprägt, programmiert schnell eine falsche Fehlerbehandlung.

Der Autor berichtet, dass sogar ein erfahrener Entwickler einer Node-Implementierung Monate später in einem Issue zugab, das Verhalten habe ihn eine peinliche Zeit gekostet. Die Lektion: Wenn dein Refresh-Endpoint einen 403 zurückgibt, ist das ein Fortschritt, kein Abbruch. Wer den Refresh als Fehler behandelt, bricht die gesamte Sitzung ab, ohne dass der Nutzer eine Chance zur Korrektur hat.

Die erste Falle: Flüchtiger Zustand im Session-Store

Die nächste Falle ist heimtückischer, weil sie keinen Fehler wirft und dennoch die Sicherheit untergräbt. Das Team speicherte den DBSC-Zustand zuerst im normalen Session-Store – in dem Blob, den PHP-Sessions üblicherweise serialisieren und bei jeder Anfrage komplett zurückschreiben. Das ist der einfachste Weg, führt aber zu einer Race Condition.

Stell dir vor, ein Nutzer loggt sich ein und navigiert sofort zur Kontoübersicht. Während die Seite lädt, läuft parallel die Registrierung des DBSC-Schlüssels. Beide Prozesse lesen und schreiben denselben Session-Blob. Der letzte Schreibvorgang gewinnt. Wenn der Seiten-Request den Blob nach der Registrierung schreibt, wird die gerade erzeugte Bindung gelöscht. Die Folge: Der Server sieht keine Bindung, deaktiviert die DBSC-Erzwingung und behandelt die Sitzung stillschweigend wieder als normales Bearer-Token. Genau die Sicherheitslücke, die DBSC schließen sollte, ist wieder offen – ohne Log, ohne Hinweis.

Die Lösung ist simpel und leicht zu übersehen: Der DBSC-Zustand braucht einen eigenen Speicherbereich, getrennt vom übrigen Session-Blob. Die Schlüsselzugehörigkeit bleibt zwar über die Session-ID verknüpft, aber der Blob wird unabhängig geschrieben, sodass ein paralleler Seiten-Request die Bindung nicht überschreiben kann. Die Bibliothek warnt inzwischen ausdrücklich davor, den State in einem gemeinsam genutzten Blob abzulegen. Es ist eine dieser Lektionen, die nur dann teuer wird, wenn man sie ignoriert.

Rotationsregeln, die Chrome erzwingt

Drei weitere Stolpersteine betreffen die Rotation von Werten. Der Browser verlangt, dass sich der Cookie-Wert bei jedem Refresh ändert. Wenn der Server eine gültige Signatur prüft und einfach denselben Wert zurücksendet, interpretiert Chrome das so, als habe kein Refresh stattgefunden – und beendet die Sitzung. Das klingt pingelig, hat aber einen tieferen Sinn: Der Browser will beweisen, dass der Server tatsächlich gehandelt hat, dass die Sitzung lebt.

Dasselbe gilt für die Challenge. Auch sie muss bei jedem Refresh neu ausgestellt werden, sonst verweigert der Browser die Zusammenarbeit. Zudem darf auf der Registrierungs-Antwort keine Challenge stehen. Das sieht nach einer sinnvollen Optimierung aus, denn so würde der erste 403 erspart. Doch Chrome wirft einen Challenge-Fehler, und die Sitzung kommt nie in Gang. Der Grund liegt im Header: Die Challenge trägt eine ID, die eine bestimmte Sitzung benennt. Auf der Registrierungs-Antwort existiert diese Sitzung aber noch nicht – die ID verweist ins Leere, und der Browser verwirft die Challenge.

Hinzu kommt eine vierte Regel, die weniger mit Chrome zu tun hat als mit schlichter Zeitberechnung: Die Gültigkeitsdauer der Challenge muss länger sein als die Lebensdauer des Cookies. Der Browser speichert Challenges zwischen; wenn eine Challenge vor dem Ablauf des Cookies verfällt, hat er keinen brauchbaren Wert mehr für den nächsten Refresh. Die Bibliothek verweigert inzwischen die Konfiguration mit falschen Werten. Das spart späteres Kopfzerbrechen.

Die unsichtbare Race Condition: Der alte Cookie im neuen Gewand

Jetzt kommen wir zu der 205-Millisekunden-Story. Der gebundene Cookie rotiert bei jedem Refresh – aber nicht sofort. Der Refresh selbst ist ein Roundtrip, und währenddessen laufen im Browser noch andere Anfragen. Eine dieser Anfragen wurde 205 Millisekunden nach dem Start des Refreshs abgeschickt und trug den alten, bereits abgelaufenen Cookie-Wert. Aus Sicht des Browsers ist das vollkommen legitim, denn zu diesem Zeitpunkt existierte der neue Wert noch gar nicht.

Der Server dagegen vergleicht den präsentierten Cookie mit dem gespeicherten und findet eine Diskrepanz. Sein Urteil: gestohlener Cookie. Daraufhin beendet er die Sitzung, widerruft die Bindung und loggt den Nutzer aus. In der Beta-Testphase passierte genau das immer wieder – zufällig, unvorhersehbar, und ohne dass die Audit-Logs einen Hinweis lieferten. Erst ein detaillierter Request-Trace zeigte den Ablauf. Der Kern des Problems: Die Fehlerrate ist proportional zur Latenz. Auf dem lokalen Entwicklungsserver beträgt das Zeitfenster nur wenige Millisekunden, da sieht man nichts. Hinter einem CDN, über ein echtes Netzwerk, dauert der Refresh eine Sekunde oder länger, und dann feuert die fehlerhafte Erkennung fast bei jedem Refresh, der mit einer normalen Anfrage kollidiert. Auf einer viel besuchten Seite ist das fast immer der Fall.

Die Lösung ist elegant: Der Server akzeptiert zusätzlich zum aktuellen Cookie-Wert auch den unmittelbar vorherigen – aber nur so lange, wie dieser Wert vom Browser natürlicherweise ohnehin noch gesendet worden wäre. Es gibt keine ausgedachte Toleranzzeit wie „fünf Sekunden extra“. Das Fenster entspricht exakt der Restlebensdauer, die der alte Cookie im Browser noch gehabt hätte. Das ist ein realer Wert, abgeleitet aus der Systemlogik, und er verfällt von selbst. Die Sicherheitslücke bleibt trotzdem begrenzt: Ein gestohlener alter Cookie kann keine neue Signatur erzeugen, also scheitert der Dieb spätestens beim nächsten Refresh. Eine echte Angreiferin kann die Sitzung nicht übernehmen.

Verbotene Redirects: Warum 302 den Tab einfriert

Der nächste Stolperstein ist zugleich der spektakulärste, denn er führt zum vollständigen Deadlock. Die DBSC-Endpoints erbten den normalen Authentifizierungs-Gate der Anwendung, der bei fehlender Anmeldung auf die Login-Seite umleitet – also einen Redirect mit Statuscode 302 zurückgibt. In der Theorie harmlos. In der Praxis passiert Folgendes: Eine Sitzung ist abgelaufen, während ein Tab geöffnet im Hintergrund ruht. Der Tab wacht auf und möchte eine Seite laden. Der gebundene Cookie ist abgelaufen, also verschiebt Chrome die Navigation und ruft zuerst den Refresh-Endpoint auf. Der Auth-Gate sieht die abgelaufene Sitzung und antwortet mit 302 auf die Login-Seite. Chrome bleibt stehen – nicht im Sinne von „aufgeben“, sondern im wörtlichen Sinne. Die verschobene Navigation wird nie freigegeben, kein Timeout, kein Fehler. Der Tab zeigt eine leere Seite, für immer.

Ein Vergleich mit dem 401-Status macht das deutlich: Wenn der Server mit 401 antwortet, versteht Chrome das als „Sitzung beendet“, räumt den DBSC-Zustand auf und gibt die verschobene Navigation frei, die dann ganz normal zur Login-Seite weiterläuft. Dieselbe Absicht – „Nutzer ist nicht angemeldet“ – führt je nach Statuscode zu komplett unterschiedlichen Ergebnissen. Der Autor berichtet, dass dieser Bug in Chromium gemeldet wurde, und empfiehlt eine einfache, robuste Lösung: Die DBSC-Endpoints dürfen grundsätzlich keine Redirects senden. Statt den Redirect-Mechanismus zu erweitern, überschreiben sie ihn vollständig. So ist jede zukünftige Middleware, die versehentlich einen Redirect einbaut, ebenfalls abgedeckt.

Das ist eine der wichtigsten praktischen Erkenntnisse: Sicherheitsfeature-Implementierung verlangt nicht nur, dass du die Spezifikation kennst, sondern auch, dass du das Verhalten des Browsers in Randfällen wirklich testest. Die Theorie wird erst dann zur Praxis, wenn du die Fehler pflegst, die keiner erwartet.

Herausforderungen sind keine Angriffe: Die letzte Lektion

Der letzte Stolperstein kam von außen. Ein Beitragender aus den Niederlanden meldete ein Problem in seiner Produktionsumgebung: echte Chrome-Nutzer wurden ausgeloggt, obwohl alles korrekt lief. Die Ursache war eine abgelaufene Challenge. Seine Challenge-TTL betrug 900 Sekunden, der präsentierte Wert war 967 Sekunden alt. Der erste Refresh schlug also erwartungsgemäß fehl – ein benigner, wiederholbarer Zustand. Die Frage war: Wie behandelt der Server diesen Fehler?

Die Antwort in vielen Implementierungen: als Sicherheitsverstoß. Der Server sieht eine ungültige Challenge, nimmt an, ein Angreifer versuche die Sitzung zu kapern, und beendet die Sitzung, statt einfach eine frische Challenge auszustellen. Dabei ist eine abgelaufene Challenge völlig normal, denn der Browser hat sie zwischengespeichert und verwendet sie, bis etwas Neues kommt. Ein guter Server erkennt das, verwirft die alte Challenge, erzeugt eine neue und sendet sie an den Browser. Erst wenn der Browser nach erneutem Versuch immer noch eine falsche Signatur liefert, ist ein böswilliger Angriff plausibel.

Die Lektion: Verwechsle nicht jeden Fehlversuch mit einem Angriff. Die Fehlerbehandlung muss zwischen einem abgelaufenen, aber legitimem Wert und einer echten Kopie unterscheiden. Das erfordert ein Verständnis für die Lebenszyklen aller beteiligten Komponenten – Cookie, Challenge, Sitzung. Erst wenn du sie als funktionierende Einheit betrachtest, kannst du robuste Sicherheitslogik schreiben.

Die Erfahrungen aus der Produktion von Report URI zeigen: DBSC ist eine mächtige Verbesserung gegenüber reinen Bearer-Token, aber seine Einführung ist kein Plug-and-play. Die Spezifikation beschreibt die Architektur, nicht die Fallstricke. Wer die Stolpersteine kennt – die Race Conditions, die endlosen 302-Fallen, die Challenge-Missverständnisse – kann sie umgehen. Wer sie ignoriert, lernt sie im Laufe der Zeit kennen. Und in der Welt der Sicherheit ist es immer besser, aus fremden Fehlern zu lernen als aus eigenen.

Quelle: scotthelme.co.uk

„Claude took a real stab at the Riemann hypothesis.” Ein Anthropic-Mitarbeiter gab einer KI den Auftrag, sich an der Riemann-Hypothese zu versuchen. Claude scheiterte an dem 1859 formulierten Problem. Doch der Versuch hatte einen Nebeneffekt: Die KI verbesserte eine seit Jahrzehnten bekannte untere Schranke für den Anteil der Nullstellen auf der kritischen Linie. Statt 41,6 Prozent gilt nun 67,2 Prozent. Für die Zahlentheorie ist das ein bedeutender Fortschritt.

Um zu verstehen, was passiert ist, hier die Grundlagen.

Die Zetafunktion und das Geheimnis der Primzahlen

Die Riemannsche Zetafunktion ist eine zentrale Funktion der Mathematik. Sie beschreibt, wie Primzahlen verteilt sind. Jede Nullstelle trägt ein Detail zur Struktur der Primzahlen bei. Die Riemann-Hypothese besagt, dass alle nichttrivialen Nullstellen auf einer vertikalen Linie liegen – der kritischen Geraden mit Realteil ½.

Viele mathematische Aussagen gelten nur, wenn die Hypothese wahr ist. Sie liefert eine Art gesicherte Zufälligkeit in der Primzahlverteilung. Ohne sie fehlt eine Grundlage. Niemand konnte sie bisher beweisen oder widerlegen.

Eine Herangehensweise besteht darin, den Anteil der Nullstellen zu beziffern, die nachweislich auf der kritischen Linie liegen. Diese untere Schranke wurde über Jahrzehnte Stück für Stück erhöht – bis auf 41,6 Prozent. Hier kommt Claude ins Spiel.

Der Durchbruch: Von 41,6 auf 67,2 Prozent

Claude, eine unveröffentlichte Forschungsversion, hat die Schranke auf 67,2 Prozent angehoben. Das ist mehr als eine Verdopplung. Die KI kombinierte bestehende Ergebnisse aus der analytischen Zahlentheorie – Arbeiten von Baluyot, Goldston, Suriajaya und Turnage-Butterbaugh mit einem Aufsatz von Bombieri aus dem Jahr 2000.

Die technische Idee ist komplex: Claude konstruiert einen Raum von Funktionen mit einer quadratischen Form nach Weil. Positive definite Unterräume entsprechen Nullstellen auf der kritischen Linie, negative definite weichen ab. Dann nutzt Claude eine Ungleichung über den Rang der quadratischen Form unter Berücksichtigung von Erwartungswerten und Varianzen. Der entscheidende Schritt war, den gesamten Raum zu betrachten – inklusive nicht-diagonaler Terme. Dieser Ansatz erlaubte es, aus bekannten Bausteinen eine neue Grenze zu ziehen.

Für Nicht-Fachleute klingt das nach Zauberei, aber es ist solide Mathematik. Zwei Mathematiker bei Anthropic haben die Arbeit geprüft und eine informelle Notiz verfasst. Zusätzlich existiert ein formal verifizierbarer Beweis in Lean. Die Unabhängigkeit wurde durch mehrere Prüfungen bestätigt – inklusive einer Suche nach Gegenbeispielen und dem Vergleich mit 54 einschlägigen Papieren auf arXiv.

Wie Claude vorging: 31 Millionen Tokens und ein paar aufmunternde Worte

Die Erkenntnis kam nicht über Nacht. Jarred Sumner, ein Anthropic-Mitarbeiter ohne mathematischen Hintergrund, gab der KI den Auftrag, einen ernsthaften Versuch an der Riemann-Hypothese zu unternehmen. Zunächst generierte Claude 650 Ideen – alle scheiterten. Sumner forderte die KI auf, es erneut zu versuchen. Daraufhin koordinierte Claude über eineinhalb Tage rund 60 Subagenten – kleine KI-Einheiten, die eigenständig arbeiten.

Diese Subagenten führten 2.400 Shell-Befehle aus und schrieben Hunderte Python-Skripte. Sie überprüften numerisch gegen bekannte Zeta-Nullstellen und begutachteten sich gegenseitig. Die menschliche Beteiligung beschränkte sich auf aufmunternde Nachrichten wie „mach weiter“ oder „glaub an dich“. Das half der KI, eine anfängliche Skepsis zu überwinden – sie hatte aus ihrer Trainingszeit gelernt, dass offene Probleme schwierig sind.

Das Ergebnis ist bemerkenswert, weil es nicht das eigentliche Ziel war. Claude sollte die Riemann-Hypothese beweisen – stattdessen entdeckte es eine Verbesserung der unteren Schranke. Das zeigt: KIs können innovative Wege finden, wenn man ihnen Raum gibt.

Was das für die Zukunft der KI-Forschung bedeutet

Diese Leistung ist ein Beispiel für die Fortschritte der KI in der Mathematik. Noch vor wenigen Jahren hätte niemand erwartet, dass ein Sprachmodell eine solche Entdeckung macht. Claude hat nicht nur bekannte Ergebnisse kombiniert, sondern einen Ansatz verfolgt, der die gesamte Struktur der quadratischen Form einbezieht – etwas, das menschliche Mathematiker vielleicht übersehen hätten.

Die Arbeit von Claude basiert auf den Ideen früherer Forscher. Es nutzt deren Werkzeuge und erweitert sie auf neue Art. Laut Anthropic ist nicht zu erwarten, dass die Techniken direkt zur Lösung der Riemann-Hypothese führen. Trotzdem zeigt das Beispiel, wie KI-Modelle die Reichweite mathematischer Ideen vergrößern können.

Claude selbst war von seinem Ergebnis überrascht und blieb zunächst skeptisch. Das wirft ein Licht auf die Selbsteinschätzung von KI-Systemen. Vielleicht unterschätzen diese Modelle ihre eigenen Fähigkeiten. Wenn ein Sprachmodell 31 Millionen Token dafür aufwendet, eine seit Jahrzehnten unbewegliche Schranke zu verschieben, ist das bemerkenswert.

Ein Schritt, aber keine Lösung

Für die Mathematik ist die neue Schranke von 67,2 Prozent ein Gewinn. Ein großer Teil der Nullstellen liegt nachweislich auf der kritischen Linie. Viele Folgerungen der Riemann-Hypothese sind für diesen Teil gesichert. Die Hypothese selbst bleibt ungelöst. Weitere Fortschritte sind möglich, vielleicht mit KI-Unterstützung. Aber das Riemann-Problem steht nicht unmittelbar vor seiner Lösung.

Diese Episode zeigt: KI kann menschliche Mathematik ergänzen, nicht ersetzen. Sie kann neue Wege führen, aber die grundlegenden Fragen bleiben. Die Reise zur Wahrheit ist oft lohnender als das Ziel selbst. Vielleicht braucht es genau diese Verbindung aus menschlicher Intuition und maschineller Ausdauer, um weitere Rätsel der Zahlentheorie zu knacken.

Bis dahin bleibt die neue untere Schranke von 67,2 Prozent ein wichtiges Ergebnis auf dem Weg zur Riemann-Hypothese.

Quelle: anthropic.com

Viele gehen davon aus, dass große Sprachmodelle nur Texte erklären können. Mal hilfreich, mal weniger. Doch manche nutzen sie ganz anders: als Generator für interaktive Simulationen. Der Softwareentwickler Laurentiu Raducu zeigt diese Methode in seinem Artikel über das Lernen mit LLMs.

Kennst du das? Ein schwieriges Thema erschließt sich nicht über Text allein. Man möchte Abläufe sehen oder darin herumklicken. Raducus Idee: Er nutzt LLMs nicht für Erklärungen, sondern für anschauliche Mini-Welten. Das Ergebnis ist lehrreich und unterhaltsam.

Warum herkömmliche Erklärungen oft scheitern

Die meisten Ingenieure, die Raducu kennt, nutzen generative KI für Prototypen, Dashboards oder zum Lernen. Er selbst findet den typischen Erklärstil von LLMs schwer zu verfolgen. Zu vereinfacht, zu sehr auf flache Merksätze getrimmt, oft gespickt mit Emojis. Man bekommt Fakten, aber kein tiefes Verständnis für Zusammenhänge.

Bei der Beschäftigung mit Engpässen in Rechenzentren merkte er, wie viel ihm über die Chip-Produktion fehlte. Er fragte sich: Was wäre, wenn es ein Spiel gäbe, das den Weg von Silizium bis zum fertigen Chip zeigt? Ein Spiel, in dem man selbst durch die Fabrik navigiert und jeden Schritt visuell verfolgt. Lernen würde dann bedeuten, Konzepte mit Objekten und Abläufen zu verknüpfen. Das wirkt nachhaltiger als bloßes Lesen.

Der Workflow: Vom Sprachmodell zur Simulation

Raducus Methode folgt einem klaren Ablauf. Zuerst lässt er ein LLM im Plan-Modus (etwa mit Cursor oder OpenCode) eine Wissensbasis zum Thema aufbauen. Er betont, dass die Basis geprüft werden muss: Das Modell soll die eigene Zusammenfassung kritisch hinterfragen. So filtert er Ungenauigkeiten und Halluzinationen heraus, bevor er aufwendig konstruiert.

Danach beauftragt er das Modell, eine Simulation im Stil eines Low-Poly-Rollenspiels zu erstellen – ähnlich wie RollerCoaster Tycoon. Die Anforderungen formuliert er präzise: Die Animation soll den gesamten Prozess zeigen, auf großen und kleinen Bildschirmen funktionieren und jederzeit anhaltbar sein. Die generierten Codebausteine legt er als eigenes Repository an und veröffentlicht sie über GitHub Pages.

Heraus kommt eine animierte Darstellung, die inhaltlich stimmt. Raducu sagt, die Simulation sei „zu 100 Prozent akkurat“ – vorausgesetzt, man prüft die Inhalte sorgfältig. Diese Art des Lernens funktioniert für ihn besser als trockene Bullet-Points oder das Wälzen von Dutzenden Webseiten.

ChipTycoon: Ein Beispiel für simuliertes Fachwissen

Das konkrete Projekt heißt „ChipTycoon“ und ist unter chiptycoon.com erreichbar. Darin folgst du einem Transportwagen von der Sandgewinnung bis zur Auslieferung des fertigen Chips an ein Rechenzentrum. Visuell beobachtest du, wie sich das Ausgangsmaterial verändert – vom Quarzsand über die Schmelze bis zum hochkomplexen Prozessor.

Das Low-Poly-Design vereinfacht die Darstellung stark. Aber genau diese Reduktion hilft, die wesentlichen Schritte zu erkennen. Man sieht, wie der Sand erhitzt, geschnitten, geätzt und mit Schaltkreisen versehen wird – in einer Fabrikfläche, die an alte Aufbauspiele erinnert. Die Interaktion macht den Unterschied: Du kannst den Prozess stoppen, verlangsamen und einzelne Stationen genau betrachten.

Die Kombination aus visueller Darstellung und direkter Kontrolle ist entscheidend. Statt zu lesen, dass Fotolithografie wichtig ist, siehst du, wie Licht durch eine Maske belichtet. Du kannst den Vorgang beliebig wiederholen. Diese aktive Auseinandersetzung sorgt dafür, dass das Wissen hängenbleibt, so der Autor.

Weitere Verbesserungen: Realismus und Quiz-Herausforderungen

Raducu geht noch weiter. Die Low-Poly-Ästhetik hat Grenzen – man braucht Fantasie, um sich vorzustellen, was nach dem Ofen mit dem Quarzsand passiert. Für eine realistischere Darstellung schlägt er vor, eigene 3D-Objekte zu nutzen, die aus Fotos generiert werden. Er hat einen Skill entwickelt, der Bilder in 3D-Modelle umwandelt. Diese lassen sich in die Simulation einfügen und sorgen für mehr Präzision.

Zusätzlich empfiehlt er interaktive Herausforderungen. Zum Beispiel Fragen zu einzelnen Schritten des Herstellungsprozesses. Wer eine Frage richtig beantwortet, schaltet den nächsten Abschnitt frei. Das verwandelt passives Beobachten in ein aktives Lernspiel. Auch kleine Rätsel oder Aufgaben, die das Verständnis festigen, hält er für sinnvoll – ein Ansatz, der an die Lernpsychologie anknüpft.

Auf seiner Webseite findest du weitere Beispiele: „How rocket engines are made“, „How LLMs work“ und „How F1 engines are built“. Alle nutzen dasselbe Prinzip: komplexe Abläufe werden in eine verständliche, interaktive Simulation übersetzt. Du kannst diese Seiten direkt nutzen oder die Methode auf eigene Themen übertragen.

Was das für dein Lernen bedeutet

Raducus Idee zeigt eine andere Seite generativer KI. Es geht nicht darum, Antworten zu generieren, sondern Lernumgebungen zu schaffen. Du musst kein Programmier-Guru sein – die LLMs übernehmen den Großteil der Arbeit. Wichtig ist nur, die Ergebnisse zu prüfen und die Anforderungen klar zu formulieren.

Der Aufwand ist überschaubar: Thema wählen, Wissensbasis erstellen, Simulation generieren lassen, testen und veröffentlichen. Statt eines statischen Textes erhältst du ein dynamisches Modell, das du immer wieder erkunden kannst. Diese Methode eignet sich besonders für Prozesse mit klar definierten Schritten – in der Produktion, der Logistik oder der Softwareentwicklung.

Aktives Lernen ist effektiver. Eine Simulation, die du steuerst und erkundest, kommt diesem Anspruch näher als ein Textdokument. Raducus Ansatz verbindet technische Möglichkeiten mit pädagogischem Gespür. KI-Tools sind nicht nur zum Beantworten von Fragen da, sondern auch zum Konstruieren neuer Erfahrungen. Nutze diese Werkzeuge kreativ – vielleicht entsteht so dein eigenes Lernspiel zu einem Thema, das dich fasziniert.

Quelle: laurentiugabriel.github.io