Die Containerplattform Docker warnt vor Sicherheitsrisiken, die sich durch die Nutzung von MCP-Quellen ergeben und Angreifern leichten Zugriff auf Dateien, Datenbanken, Netzwerk und Secrets eröffnen. Außerdem können die Täter weitreichend Befehle absetzen und schädlichen Code einschleusen.

Der Blogbeitrag kritisiert das von Anthropic letztes Jahr eingeführte und inzwischen weitverbreitete Model Context Protokol (MCP) als auf Komfort und nicht auf Sicherheit angelegt. „Es ist zu einem Sicherheitsalptraum geworden, der Unternehmen dem Risiko von Datenverlust, Kompromittierung der Systeme und Angriffen auf die Lieferkette aussetzt.“ Dabei betont der Text, dass diese Annahmen nicht auf Spekulation beruhen, sondern auf der „Analyse tausender MCP-Server, die systematische Schwachstellen in sechs kritischen Angriffsvektoren aufgedeckt hat“. Als Schutz empfiehlt Docker unter anderem den hauseigenen Katalog gehärteter MCP-Images.

Schadcode über OAuth

Tatsächlich untermauert der Blogeintrag seine Annahmen mit vielen Hinweisen auf Studien von Sicherheitsfirmen, die MCP untersucht haben. Als erstes Problem nennt Docker schadhafte OAuth-Prozesse, die bösartigen Code in Clients einschleusen können. Laut der zitierten Studie sind 43 Prozent der analysierten Server davon betroffen. Ein Beispiel war ein inzwischen behobenes Problem im viel genutzten Paket mcp-remote, mit dem sich Clients bei entfernten MCP-Servern anmelden können.

Als weitere Probleme nennt Docker das Einschleusen und Ausführen von Befehlen, uneingeschränkter Netzzugriff, Zugriff auf das Dateisystem, den Missbrauch von Tools sowie das Aufdecken von Secrets. Diese finden sich unter Umständen in unsauber implementierten Umgebungsvariablen, Logfiles oder Prozesslisten.

Anwenderinnen und Anwender sollten MCP-Quellen immer genau prüfen und auch im Betrieb überwachen, welche Rechte sie einfordern und auf welche Ressourcen sie zugreifen. Bei offenen Quellen lässt sich beispielsweise nach Stichwörtern wie eval() oder exec() suchen. Die Server sollten ferner keine Credentials als Umgebungsvariablen benötigen.

Der Autor des Blogbeitrags hat angekündigt, weitere Artikel zum Thema zu veröffentlichen.

(who)

Vielleicht kommt Ihnen das bekannt vor: Sie starten ein neues Projekt – voller Motivation und mit dem guten Gefühl, alles von Anfang an sauber umzusetzen. Also wählen Sie die klassische Architektur, die man überall kennt: oben die Nutzeroberfläche, unten die Datenbank, dazwischen ein wenig API. Das sieht ordentlich aus, fühlt sich professionell an, und man denkt sich: So baut man gute Software. Schließlich steht es ja so auch in den Lehrbüchern und in sämtlichen Framework-Tutorials. Und am Anfang funktioniert das auch wunderbar. Die ersten Funktionen entstehen fast von selbst. Sie klicken sich durch die Oberfläche, speichern Daten in der Datenbank, und alles wirkt kontrollierbar und aufgeräumt. Jede Schicht scheint genau das zu tun, wofür sie gedacht ist.

Und dann vergehen ein paar Monate – und die ersten Probleme beginnen sich langsam zu zeigen. Plötzlich benötigen Sie die Datenbank, um Ihre Tests überhaupt starten zu können. Ein kleines neues Feature zwingt Sie dazu, Änderungen an drei oder vier Stellen gleichzeitig vorzunehmen. Und irgendwie ist Ihre Geschäftslogik in die Controller gerutscht oder steckt direkt in der Datenbank. Fachlichkeit und Technik beginnen, sich immer stärker zu vermischen.

Dann kommt irgendwann der Tag, an dem Sie etwas Größeres anfassen müssen. Vielleicht müssen Sie das Framework aktualisieren, weil das alte nicht mehr unterstützt wird. Vielleicht möchten Sie die Datenbank austauschen oder eine völlig neue Nutzeroberfläche aufsetzen. Und genau in diesem Moment merken Sie, dass Sie gefangen sind, gefangen in Ihrer eigenen Architektur. Was am Anfang noch so ordentlich aussah, entpuppt sich in Wirklichkeit als Falle.

Das Problem mit klassischen Architekturen

Wenn wir uns einmal etwas genauer anschauen, warum klassische Architekturen langfristig häufig so viele Probleme verursachen, dann ist das zunächst gar nicht offensichtlich. Auf dem Papier wirken sie nämlich sauber. Wir haben unsere Schichten: ganz oben die Nutzeroberfläche, in der Mitte die API oder vielleicht ein paar Services, und ganz unten die Datenbank. Alle wissen, wo ihr Code jeweils hingehört, und anfangs entsteht das gute Gefühl, dass man eine saubere, gut strukturierte Anwendung entwickelt.

Doch sobald die Software wächst, zeigt sich die Realität. Fachlichkeit und Technik lassen sich in der Praxis fast nie sauber trennen. Ein neues Feature kommt, und plötzlich verteilt sich die Geschäftslogik: Ein Teil landet im Controller, ein anderer Teil in den Datenbank-Entities und ein weiterer Teil in irgendeinem Service. Denn natürlich ist es bequem, von irgendwo schnell einmal auf ein Framework-Feature zuzugreifen oder direkt eine Datenbank-Annotation zu verwenden, statt eine saubere Schnittstelle zu definieren. Und mit jedem dieser kleinen Schritte wird Ihre Software ein Stück enger mit der Technik verflochten.

Am Anfang merken Sie das kaum. Doch nach ein paar Monaten wird es plötzlich unmöglich, Ihre Geschäftslogik ohne die Datenbank oder das Framework zu starten. Wenn Sie testen möchten, benötigen Sie zunächst eine laufende Datenbank. Wenn Sie refaktorisieren wollen, müssen Sie darauf achten, keine versteckte Magie des Frameworks unbeabsichtigt zu beschädigen.

Fachlichkeit und Technik vermischen sich

Das führt dazu, dass Ihre Software zunehmend unbeweglich wird. Jede Änderung wird riskant. Ein simples neues Feature zieht sich durch mehrere Schichten, und selbst kleinste Anpassungen können Nebenwirkungen haben, die Sie erst bemerken, wenn etwas ganz anderes nicht mehr funktioniert. Und je länger das Projekt läuft, desto größer wird die Unsicherheit vor Änderungen. Notwendige Refactorings werden häufiger verschoben. Irgendwann kommt dann der Moment, an dem Sie etwas wirklich Grundlegendes ändern müssen. Vielleicht benötigen Sie ein Framework-Upgrade, weil Sicherheitslücken bekannt geworden sind. Vielleicht müssen Sie die Datenbank wechseln, weil Ihr Produkt skalieren soll. Oder Sie möchten eine neue Nutzeroberfläche entwickeln, weil Ihre Anwendung auf einer anderen Plattform laufen soll.

Und genau in diesem Moment stellen Sie fest, dass Sie in Ihrer Architektur gefangen sind. Die Geschäftslogik ist inzwischen so eng mit der Technik verknüpft, dass sie kaum noch zu entkoppeln ist. Genau das ist die große, unsichtbare Falle der klassischen Drei-Schichten-Architektur. Sie vermittelt anfänglich ein Gefühl von Ordnung – doch je größer Ihr System wird, desto höher fällt der Preis für diese scheinbare Ordnung aus. Es fehlen allzu oft klare Grenzen zwischen dem, was fachlicher Kern ist, und dem, was lediglich technische Infrastruktur sein sollte. Und ebendiese fehlenden Grenzen machen Ihre Software langfristig teuer, unflexibel und fehleranfällig.

Wenn diese strukturelle Falle erst einmal erkannt ist, stellt sich unmittelbar die Frage: Wie kann man ihr entkommen? Die Antwort darauf ist überraschend einfach – und gleichzeitig radikal. Die Geschäftslogik muss so gestaltet werden, dass sie vollständig unabhängig von Datenbanken, Frameworks und Benutzeroberflächen funktioniert. Genau das ist die Grundidee der hexagonalen Architektur.

Was ist hexagonale Architektur?

Hexagonal bedeutet in diesem Zusammenhang nicht, dass künftig alle Komponenten in Form von Sechsecken dargestellt werden müssten. Es geht vielmehr darum, dass Ihre Anwendung einen stabilen Kern erhält, und alles, was sich außen herum befindet, austauschbar wird. Dieser Kern ist die sogenannte Domain – also die Geschäftslogik, die das eigentliche Kerngeschäft abbildet. Alles andere – sei es Benutzeroberfläche, Datenbank, API, Messaging-System oder Cloud-Service – ist lediglich ein Adapter, also gewissermaßen ein Plug-in, das sich an diesen Kern andockt.

Um das Bild greifbar zu machen: Stellen Sie sich Ihre Anwendung als Insel vor. Im Zentrum dieser Insel befindet sich Ihre Geschäftslogik. Das ist jener Teil, der Ihr Produkt ausmacht, der Ihr Unternehmen besonders macht und für den Kundinnen und Kunden letztlich bezahlen, weil hier die eigentliche Wertschöpfung erfolgt. Außen herumliegt das Wasser, und auf der gegenüberliegenden Seite liegt die große weite Welt: Benutzeroberflächen, Datenbanken, externe Systeme, Frameworks und mehr. Um diese Welt nun mit Ihrer Geschäftslogik zu verbinden, bauen Sie Brücken – genau diese sind die Adapter. Wenn Sie dann eine dieser Brücken austauschen, bleibt die Insel selbst davon völlig unberührt.

Viele Teams betonen zwar, dass sie Domain-Driven Design (DDD) anwenden – tatsächlich enthalten die Objekte jedoch häufig nur Daten, während sämtliche Entscheidungen in Services ausgelagert werden. Eine echte hexagonale Architektur entfaltet ihre Stärken jedoch erst dann, wenn die Domain tatsächlich Verhalten enthält: also Regeln, Invarianten und Entscheidungen. Wenn die Objekte hingegen keine eigene Logik mitbringen, entsteht erneut Spaghetti-Code. Auch das schönste Hexagon kann daran nichts ändern. Solche Datenmodelle, die keine eigene Logik tragen, werden deshalb auch als anämisch – also gewissermaßen blutarm – bezeichnet.

Onion Architecture, Clean Architecture & Co.

Vielleicht sind Ihnen in diesem Zusammenhang auch schon die Begriffe „Onion Architecture“ oder „Clean Architecture“ begegnet. Im Kern handelt es sich dabei jeweils um denselben Ansatz wie bei hexagonaler Architektur. Alle drei Architekturmodelle verfolgen nämlich das gleiche Ziel: Die Geschäftslogik soll ins Zentrum rücken, die Technik nach außen treten. Unterschiede bestehen hauptsächlich in der Darstellung und in einzelnen Details. Die Onion Architecture verwendet das Bild konzentrischer Ringe, die Clean Architecture ergänzt Begriffe wie Entities, Use Cases und Interfaces, und die hexagonale Architektur spricht stattdessen von Ports und Adaptern – häufig in der Darstellung eines Sechsecks. In der praktischen Umsetzung sind diese Begriffe jedoch vor allem unterschiedliche Perspektiven auf eine gemeinsame Grundidee. Wer das Prinzip der hexagonalen Architektur verstanden hat, besitzt damit zugleich das Fundament für Onion und Clean Architecture.

Häufig wird moderne Architektur auch unmittelbar mit Microservices in Verbindung gebracht – jedoch bedeutet die Verwendung hexagonaler Architektur nicht automatisch, dass Microservices eingesetzt werden müssen. Auch ein modularer Monolith – gelegentlich auch als „Modulith“ bezeichnet – kann problemlos auf Basis einer hexagonalen Struktur aufgebaut werden. Und wenn später ein Wechsel hin zu Microservices ansteht, gelingt dieser deutlich einfacher, weil durch die fachlichen Grenzen bereits alle strukturellen Voraussetzungen erfüllt sind. Microservices bieten jedoch den Vorteil, dass sie diese Struktur oft noch konsequenter erzwingen. Meiner persönlichen praktischen Erfahrung nach funktioniert der fachliche Ansatz daher in Verbindung mit Microservices häufig besonders gut.

Abhängigkeiten von außen nach innen

Der zentrale Mechanismus der hexagonalen Architektur besteht – wie bereits erwähnt – aus Ports und Adaptern. Ein Port ist dabei eine Schnittstelle, die Ihre Geschäftslogik entweder anbietet oder von außen erwartet. Ihr Fachmodell könnte etwa formulieren:

„Um ein Buch auszuleihen, benötige ich ein Repository, das mir Bücher liefert und Speichervorgänge entgegennimmt.“

Es legt aber nicht fest, wie dieses Repository konkret implementiert ist. Es definiert lediglich den Vertrag – genau das ist der Port. Der Adapter, also die Brücke in unserem Bild, ist die konkrete Umsetzung. Er weiß, wie er diese Schnittstelle erfüllt: Vielleicht verwendet er eine PostgreSQL-Datenbank, vielleicht eine EventSourcingDB, vielleicht ein einfaches In-Memory-Array für Tests – oder etwas ganz anderes. Für Ihre Geschäftslogik spielt das keine Rolle. Sie kennt ausschließlich die Schnittstelle, nicht aber die dahinterliegende technische Umsetzung.

Entscheidend dabei ist die Richtung der Abhängigkeiten. In einer klassischen Schichtenarchitektur hängt der Fachcode fast immer von der Technik ab: Die Nutzeroberfläche ruft Services auf, Services greifen auf Repositories zu, und diese sind direkt mit der Datenbank verbunden. In der hexagonalen Architektur hingegen ist es genau umgekehrt: Die Technik hängt an der Geschäftslogik, aber die Geschäftslogik weiß nichts von der Technik. Dadurch erzielen Sie drei wesentliche Vorteile:

• Erstens wird Ihre Software testbar, weil Sie die Geschäftslogik isoliert prüfen können.
• Zweitens wird sie anpassbar, weil Sie Datenbanken, Benutzeroberflächen und Frameworks austauschen können, ohne die Geschäftslogik ändern zu müssen.
• Und drittens wird sie langlebig, weil der fachliche Kern Ihrer Software vollständig unabhängig bleibt von Technologien, die in wenigen Jahren bereits veraltet sein könnten.

Damit die Geschäftslogik auch tatsächlich unabhängig bleibt, werden die Adapter – wie beschrieben – von außen bereitgestellt. Dies erfolgt typischerweise über Dependency Injection. Die Domain kennt somit nur die Ports – wer die jeweilige Implementierung liefert, entscheidet die Außenwelt zur Laufzeit. Das ist kein exklusives Merkmal der hexagonalen Architektur, sondern schlicht saubere Entkopplung.

„Wir sind aber nicht Netflix!“

Vielfach wird angenommen, dass eine so strukturierte Architektur nur bei besonders großen Systemen erforderlich sei. Häufig fällt dann der Satz:

„Wir sind aber nicht Netflix!“

Das jedoch greift zu kurz. Natürlich handelt es sich bei den meisten Systemen nicht um Plattformen dieser Größenordnung. Dennoch gilt: Jede Software, die überhaupt einen Zweck erfüllt, enthält auch Fachlichkeit – also auch Ihre Software. Denn niemand entwickelt Software ausschließlich aus technischer Neugier, sondern fast immer, weil ein fachliches Problem gelöst werden soll. Und genau deshalb gehört die Fachlichkeit immer in den Mittelpunkt. Möglicherweise benötigen Sie nicht in jedem Projekt CQRS oder Event Sourcing. Aber ein klares Verständnis davon, welche fachlichen Begriffe und Regeln Ihre Software prägen, benötigen Sie immer. Wenn Sie diese Fachlichkeit konsequent ins Zentrum stellen, ergibt sich die Technik darum herum nahezu von selbst. Genau darum geht es.

Wenn Sie Ihre Software also so gestalten, dass die Geschäftslogik im Zentrum steht und die Technik nur außen angedockt ist, verändert sich die Arbeit damit grundlegend. Denn plötzlich fühlt sich Softwareentwicklung wieder leicht an – selbst in sehr großen Projekten. Der erste große Vorteil ist die Testbarkeit. Sie können Ihre Geschäftslogik vollständig isoliert prüfen – ohne laufende Datenbank, ohne gestartetes Framework, ohne Abhängigkeit von der Außenwelt. Sie schreiben einen Test, instanziieren die Geschäftslogik, geben ihr die benötigten Daten – und prüfen, ob sie das richtige Verhalten zeigt. Das spart Zeit und schafft vor allem Sicherheit: Sie wissen, dass Ihr Kerngeschäft funktioniert – unabhängig davon, was außerhalb geschieht.

Der zweite Vorteil ist die Flexibilität. Wenn Ihre Geschäftslogik keine Kenntnis von Datenbanken, Frameworks oder technischen Details hat, können Sie diese jederzeit austauschen. Heute arbeiten Sie vielleicht mit PostgreSQL, morgen mit einer EventSourcingDB oder MongoDB. Sie könnten Ihre Nutzeroberfläche von einer klassischen Webanwendung auf eine mobile App oder eine reine API-Variante umstellen. Ihre Geschäftslogik bleibt unverändert – ein enormer Vorteil für die langfristige Wartbarkeit.

Der dritte Vorteil ist die Langlebigkeit Ihrer Software. Technologien kommen und gehen. Frameworks und Werkzeuge werden abgelöst. Die Geschäftslogik jedoch bleibt in vielen Fällen über Jahre im Einsatz. Wenn sie von Anfang an unabhängig gehalten wird, schützen Sie damit den wertvollsten Teil Ihrer Software: das eigentliche Kerngeschäft. Refactorings verlieren ihren Schrecken, weil klar ist: Die Technik ist austauschbar – aber die Logik bleibt stabil. Viele Teams erkennen diese Falle erst spät und müssen dann aufwendig umbauen. Wer früh mit hexagonaler Architektur beginnt, erspart sich diesen Schritt. Doch auch ein späterer, schrittweiser Umbau ist möglich: Zunächst die Grenzen ziehen, dann Adapter definieren, anschließend die Technik entkoppeln. Architektur ist in den meisten Fällen ein evolutiver Prozess – kein Big Bang.

Zugang zu modernen Architekturmustern

Hexagonale Architektur ist übrigens nicht nur für sich genommen interessant – sie eröffnet auch den Zugang zu modernen Architekturmustern wie Event Sourcing und CQRS. Vielleicht haben Sie bereits von CQRS gehört – falls nicht: Es lohnt sich, sich damit einmal näher zu beschäftigen. Das Akronym CQRS steht dabei für Command Query Responsibility Segregation und bedeutet, dass Lese- und Schreiboperationen in der Anwendung konsequent getrennt werden: Commands verändern den Zustand, Queries lesen ihn aus. Event Sourcing geht sogar noch einen Schritt weiter: Anstelle des aktuellen Zustands werden sämtliche Änderungen, die im Laufe der Zeit stattfinden, als Events gespeichert. So entsteht ein wertvoller Datenschatz, der sich analysieren, auswerten und zur Verbesserung der Fachlichkeit nutzen lässt. Und als zusätzlicher Vorteil: Sie schreiben Ihre Geschäftslogik mit konsequentem Fokus auf die Fachlichkeit – nicht auf die Technik. Als Einstieg in die Thematik sei die Website cqrs.com empfohlen.

Gerade hier zeigt sich übrigens sehr gut, wie perfekt die hexagonale Architektur ins Gesamtbild passt: Commands und Queries sind in dieser Architektur nämlich einfach Ports – also Schnittstellen, über die die Geschäftslogik angesprochen wird. Ob ein Command nun über eine HTTP-API, eine Message-Queue oder einen Testfall hereinkommt, spielt für die Geschäftslogik keine Rolle. Auch die Anbindung des Event-Stores ist lediglich ein Adapter, der die Ports bedient. Das bedeutet: Wenn Sie später auf CQRS oder Event Sourcing umsteigen möchten, müssen Sie nicht bei null beginnen. Ihre Anwendung ist bereits vorbereitet – durch die klare Trennung von Fachlogik und Technik.

In einer zunehmend verteilten Welt, in der Themen wie Streaming, Real-Time-Processing und Cloud-native-Architekturen an Bedeutung gewinnen, ist das ein erheblicher Vorteil. Sie bauen heute eine robuste, langlebige Anwendung – und halten sich zugleich die Tür für zukünftige Technologien offen.

Heute schon an morgen denken

Klassische Architekturen wirken zu Beginn sehr sauber, entwickeln sich jedoch im Laufe der Zeit zur Falle. Fachlogik und Technik vermischen sich, Änderungen werden riskant, und plötzlich hängt Ihre gesamte Anwendung an Frameworks und Datenbanken, die eigentlich nur Hilfsmittel sein sollten. Die hexagonale Architektur kehrt dieses Verhältnis um. Sie stellt die Fachlogik in den Mittelpunkt und macht die Technik austauschbar.

Das Ergebnis: testbare, flexible und langlebige Software. Sie schaffen sich die Freiheit, auf neue Anforderungen und Technologien zu reagieren, ohne das Kerngeschäft Ihrer Anwendung ständig neu aufbauen zu müssen. Wer Software auf diese Weise gestaltet, schützt damit das Wertvollste, was ein Team besitzt: das eigene Fachwissen. Denn alles andere ist nur Infrastruktur – und diese kann jederzeit ersetzt werden.

(rme)

OpenAI hat am Dienstagabend mit gpt-oss-120B und gpt-oss-20B zwei Open-Weight-Reasoning-Modelle veröffentlicht. Bereits im März hatte OpenAI-Chef Sam Altman die ersten Open-Weight-Modelle seit GPT-2 in Aussicht gestellt. Im Juli wurde die Veröffentlichung dann aus Sicherheitsbedenken aber um unbestimmte Zeit verschoben. Anders als geschlossene Modelle wie GPT-4 oder o4-mini enthalten offene Modelle auch die trainierten Parameter, was Dritten den Betrieb auf eigener Infrastruktur ermöglicht.

Nach Angaben von OpenAI erreicht gpt-oss-120B in zentralen Benchmarks die Leistung von OpenAIs Reasoning-Modell o4-mini, laufe dabei aber auf nur einer einzigen 80 -GB-GPU. gpt-oss-20B liefere indessen starke Reasoning-Fähigkeiten auf einem 16 GB-Edge-Gerät. Reasoning-Modelle sind speziell darauf trainiert, komplexe logische Schlussfolgerungen zu ziehen, mehrstufige Probleme zu lösen und ihre Denkprozesse explizit darzulegen.

Neues Sicherheitsprotokoll entwickelt

Offene Modelle sind auch für den Einsatz in Hochsicherheitsumgebungen interessant, da sie lokal betrieben werden können. Allerdings sind auch bei den Modellen selbst die Sicherheitsanforderungen höher, da diese nach Freigabe – anders als geschlossen betriebene Modelle – nicht zurückgenommen werden können. OpenAI-Chef Sam Altman hatte im Juli offenbar noch Bedenken und erklärte, es seien zusätzliche Sicherheitstests notwendig. Im Zuge der jetzigen Veröffentlichung erklärte das Unternehmen, dass die Modelle mit einem neuen Sicherheitsstandard entwickelt worden seien.

Dieses “Worst-Case-Fine-Tuning”-Protokoll simuliere böswillige Nutzung in den Bereichen Biologie und Cybersicherheit, dürfte also darauf abzielen, zu verhindern, dass das Modell für den Waffenbau oder Cyberattacken missbraucht wird. Externe Experten hätten die Methodik überprüft und OpenAI macht zudem Evaluierungscode, Prompts und Bewertungsrichtlinien öffentlich.

“Geprägt von demokratischen Werten”

Zusammen mit der Veröffentlichung der neuen Modelle wurden auch Entwicklungshandbücher und Tools bereitgestellt, um die Modelle für die eigenen Bedürfnisse anzupassen und Schutzmechanismen zu implementieren. Sie werden unter der Apache-2.0-Lizenz veröffentlicht und können unter anderem in Hugging Face, vLLM, Ollama und llamaa.cpp integriert werden.

OpenAI-Chef Altman erklärte anlässlich der Veröffentlichung, dass die Welt “künftig auf einem offenen KI-Stack aufbauen kann – entwickelt in den USA, geprägt von demokratischen Werten, kostenlos zugänglich und zum breiten Nutzen aller.” Die Aussage kann als Anspielung auf chinesische Open-Weight-Modelle verstanden werden, die sich nach ihrer Veröffentlichung großer Beliebtheit erfreuten, aber zugleich Kritiker auf den Plan riefen. So sei das Trainingsmaterial darauf abgestimmt, Fragen im Sinne der chinesischen Regierung zu beantworten. Historische Ereignisse wie auf dem Tian’anmen-Platz verschweige die KI.

(mki)