IT Security Consultant

Principal IT Security Consultant

Im März haben wir bereits einen Blogartikel über [Relative Path Hijacking in Windows](https://www.codecentric.de/wissens-hub/blog/relative-path-dll-hijacking-in-windows-programmen) veröffentlicht. Darin zeigen wir eine offene Schwachstelle in aktuellen Windows-Versionen auf, die es Angreifern ermöglicht, eigenen Code in DLL-Dateien über vertrauenswürdige Windows-Anwendungen auszuführen.

In diesem Blogartikel widmen wir uns dementsprechend fortführend mit potentiellen Erkennungsmöglichkeiten dieser Schwachstelle. 

Disclaimer: Als “Proof of Concept” wurde die Windows-Anwendung calc.exe verwendet, um maliziöse DLLs nachzuladen. Wir können hier von einer Kombination aus “Relative Path Hijacking” und “DLL Side-Loading” sprechen.

### Erkennung von DLL Hijacking unter Windows

Um einen solchen Angriff zu erkennen, gibt es mehrere Möglichkeiten:

1. Sysmon-Logs mithilfe eines SIEM  auswerten: Sysmon kann das Laden von DLLs überwachen und verdächtige Aktivitäten aufzeigen.
2. Prefetch-Dateien untersuchen: Windows speichert Informationen zu 
ausgeführten Programmen und deren geladenen DLLs in Prefetch-Dateien.

### Überprüfung mithilfe eines SIEM in Kombination mit Sysmon

Wir haben in unserem Lab eine Splunk-Instanz aufgesetzt und Sysmon für zusätzliche Sichtbarkeit installiert. Sysmon bietet den Vorteil, dass es bereits Erkennungen mitbringt und diese nur durch Splunk Searches dargestellt werden müssen.

Um [Sysmon](https://learn.microsoft.com/de-de/sysinternals/downloads/sysmon) zu installieren, wird die Anwendung von Microsoft aus den Sysinternals Suite heruntergeladen. Wichtig für die Installation ist eine Konfigurationsdatei. Eine Beispieldatei findet sich ebenfalls auf der [offiziellen Microsoft-Seite](https://learn.microsoft.com/de-de/sysinternals/downloads/sysmon).

Klar zu sehen ist, dass hier DLL Side-Loading erkannt wurde. Beim DLL Sideloading legen Angreifer eine manipulierte DLL in das Verzeichnis einer legitimen, vertrauenswürdigen Anwendung ab und starten diese gezielt (siehe eingangs erwähnten Blogpost). Die Anwendung lädt dann automatisch die schädliche DLL, weil sie diese erwartet. Der Angreifer muss also nicht auf den Start der Anwendung durch das Opfer warten, sondern kann die Payload direkt einbringen. Genau das ist zu Testzwecken passiert.

Sysmon erkennt diesen Ansatz und loggt das entsprechende Event. Zusätzlich wird auch das entsprechende TTP aus dem [MITRE ATT&CK Framework](https://attack.mitre.org/) referenziert. Mit einer simplen Splunk-Suche lässt sich gezielt nach solchen Events suchen und eine Alarmierung auslösen.

![splunk_dllhijacking.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23ueda43tq07um1yd1vxbh)

![splunksearch_dllhijacking.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23y3hm48s007umi4bmfikt)

### Überprüfung mittels Prefetch-Dateien

Liegt ein forensisches Image vor, kann DLL Hijacking ebenfalls durch Prefetch Dateien nachgewiesen werden. Prefetch-Dateien enthalten Informationen zu ausgeführten Programmen und deren geladenen DLLs. Diese befinden sich unter C:\Windows\Prefetch und lassen sich entweder mithilfe eines Textprogramms manuell analysieren oder durch für solche Fälle spezialisierte Tools. Für den hier vorliegenden Fall wurde [PECmd](https://github.com/EricZimmerman/PECmd) von Eric Zimmermann genutzt.

![Prefetch_Dllhijacking.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23yp4r43f508ul35wblg78)

Voraussetzung hierzu ist, dass die entsprechend benutzte Windows-Anwendung bekannt ist.

### Verhinderung des Angriffspfads durch Application Allow Listing

Idealerweise sollte ein solcher Angriff nicht nur erkannt oder im Rahmen forensischer Analysen nachvollzogen, sondern bereits im Vorfeld zuverlässig blockiert werden. Auch wenn es sich wie in diesem Beispiel um eine vertrauenswürdige und signierte Microsoft-Applikationen handelt, kann ein konsequent umgesetztes Application Allow Listing solche Angriffswege effektiv unterbinden. Voraussetzung dafür ist, dass die eingesetzte Sicherheitslösung so konfiguriert ist, dass nicht nur ausführbare Dateien, sondern auch referenzierte DLLs ausschließlich dann geladen werden dürfen, wenn sie aus vertrauenswürdiger Quelle stammen und entsprechend signiert sind.
Eine praxistaugliche Möglichkeit zur Umsetzung dieser Schutzmaßnahme unter Windows bietet das kostenlose Tool Windows Defender Application Control (WDAC). Mit dem [App Control Policy Wizard](https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/wdac-wizard) lassen sich entsprechende Richtlinien schnell und benutzerfreundlich konfigurieren.

![Wizard.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma23z8xb49ym07um6hue3wen)

### Fazit

Die Erkennung von Relative Path DLL Hijacking erfordert eine Kombination aus Log-Analyse, Speicherprüfung und Dateiüberwachung. Mit Tools wie Sysmon, Splunk und Prefetch-Analyse lassen sich verdächtige Aktivitäten effizient aufspüren. Ein regelmäßiges Monitoring, das Absichern der Suchpfade, sowie Application Allow Listing, können helfen, Angriffe zu verhindern.

In diesem Artikel werden verschiedene Erkennungen von DLL Hijacking behandelt sowie Methoden zur Verhinderung.

DLL Hijacking erkennen und verhindern

Wissens-Hub | codecentric AG

codecentric Blog

Im Kern geht es in dieser Blogserie um drei Fragen:

1. Was ist Resilienz?
2. Wie können wir resilient werden?
3. Müssen wir immer das volle Programm durchziehen?

Die zweite Frage leuchtet wahrscheinlich sofort ein, während die erste und dritte Frage dich vielleicht zum Nachdenken bringt. Ist es nicht offensichtlich, was Resilienz ist? Und gibt es eine Alternative dazu, alles Notwendige zu tun, um resilient zu werden? Nach meinen Beobachtungen herrscht in Bezug auf Resilienz große Verwirrung. Fast jeder, mit dem ich spreche, meint etwas anderes, wenn er von Resilienz spricht.

Das führt zur dritten Frage. Oft sind die Menschen nicht wirklich an Resilienz interessiert, wenn sie über Resilienz sprechen (insbesondere im Kontext von IT). Es gibt mehrere prototypische Entwicklungsschritte, die Unternehmen auf ihrem Weg zur Resilienz durchlaufen. Je nach Aufgabenstellung kann es jedoch völlig in Ordnung sein, die Reise bei einem der Zwischenschritte zu beenden. Natürlich ist das, was sie in einer solchen Situation erreicht haben, keine wirkliche Resilienz – aber es kann völlig ausreichend sein, um ihre Aufgabe zu lösen.

Diese Blogserie basiert auf einem [Vortrag](https://speakerdeck.com/ufried/from-here-to-resilience-a-travel-guide), den ich einige Male gehalten habe (siehe z. B. die [Aufzeichnung](https://www.youtube.com/watch?v=LJ5YXm5j6K8) von J On the Beach 2024). Im Kern folgt die Blogserie demselben Handlungsstrang wie die Präsentation. Allerdings taucht sie tiefer in das Thema ein und füllt (hoffentlich) die Lücken, die die Präsentation aus Zeit- und Umfangsgründen lassen musste.

Da dies alles viel zu lang für einen einzigen Blogbeitrag wäre, habe ich es auf mehrere Beiträge aufgeteilt:

1. Was ist Resilienz? (dieser Beitrag)
2. Das Tal der Feature-Vollständigkeit
3. Das Plateau der Stabilität
4. Verfügbarkeit revisited
5. Das Plateau der Robustheit
6. Überraschungen und Antagonisten
7. Das Hochplateau der grundlegenden Resilienz
8. Reagieren auf sich verändernde Bedrohungslandschaften
9. Der Gipfel der fortgeschrittenen Resilienz (Anti-Fragilität)
10. Müssen wir immer das volle Programm durchziehen?

## Die Grenzen des Geschichtenerzählens

Ursprünglich hatte ich geplant, diese Blogserie als Heldenreise zu schreiben. Aber im Laufe der Zeit wurde mir klar, dass diese Reise nicht von einer einzelnen Person gestaltet werden kann. Eine einzelne Person kann als Evangelist und vielleicht als Katalysator fungieren, um Dinge in Gang zu bringen. Sie wird jedoch nie in der Lage sein, die gesamte Reise zu gestalten.

Daher hätte die Person entweder den Staffelstab auf dem Weg weitergeben müssen, und die nächste Person hätte das Gleiche tun müssen und so weiter, was die Identifikation mit der jeweiligen Person erschwert. Oder ich hätte eine größere Gruppe auf dem Weg aufbauen müssen, was seine eigenen Herausforderungen mit sich bringt.

Daher habe ich beschlossen, von der Erzählmethode Abstand zu nehmen, da das vorliegende Thema dies schwierig macht und ich fürchte, dass dies meine persönlichen Erzählfähigkeiten übersteigt.

Folglich werde ich die Reise auf eine eher beschreibende Weise erklären, d. h. ich werde sie nicht aus der Ich-Perspektive erzählen. Stattdessen werde ich aufzeigen, was ein Unternehmen dazu bringt, von einer Stufe zur nächsten zu wechseln, wie man dorthin gelangt, welche Kompromisse die einzelnen Stufen eingehen und welche blinden Flecken sie aufweisen (die wiederum auf die nächste Stufe hinweisen).

Zwar wird die emotionale Bindung einer guten Heldenreise fehlen, aber ich hoffe, dass ich trotzdem die wichtigen Informationen vermitteln kann – wenn auch auf etwas prosaischere Weise.

## Letzte Vorbereitungen

Bevor wir in die Materie einsteigen, möchte ich noch folgende Anmerkungen machen:

- In der Regel ist es besser, die Erklärung eines Themas mit der Beantwortung der Frage „Warum“ zu beginnen, anstatt mit der Frage „Was“. Das „Warum“ gibt einen Sinn. Das „Was“ ohne die Frage nach dem „Warum“ kann im schlimmsten Fall zu Solutioneering führen, dem Gestalten von Lösungen ohne zugehöriges Problem. Ich überspringe das „Warum“ hier, weil ich es bereits in früheren Blogbeiträgen erörtert habe, z. B. in dieser allgemeinen [Einführung](https://www.ufried.com/blog/resilience/), warum wir Resilienz brauchen, oder in jüngerer Zeit als wesentlichen [Baustein](https://www.ufried.com/blog/responsible_it_1/) für eine bessere IT. Wenn du also nach dem „Warum“ suchst, empfehle ich, zuerst die oben genannten Blogbeiträge zu lesen.
- In diesem Blogbeitrag stelle ich eine Reihe von Denkmodellen vor. Auch die Reise selbst ist eine Art Modell, denn sie lässt viele Details aus, die deine tatsächliche Reise beeinflussen können. Wie ich in einem früheren Blogeintrag erörtert habe: „[Alle Modelle sind falsch. Einige sind nützlich!](https://www.ufried.com/blog/power-of-models/)“. Wenn also dein spezieller Weg anders verläuft, wenn du dein aktuelles Resilienzniveau nicht genau bestimmen kannst, weil du Teile von Stufe A und Teile von Stufe B umgesetzt hast, dann ist das völlig in Ordnung. Ich liefere nicht die eine und einzige unumstößliche Wahrheit. Ich versuche, dir ein Denkmodell zur Verfügung zu stellen, eine Vereinfachung der Realität, die dich dabei unterstützt, über deine Situation nachzudenken und zu überlegen, was der nächste sinnvolle Schritt sein könnte. Nicht mehr. Aber auch nicht weniger.

Nachdem das gesagt ist, wollen wir loslegen.

## Was ist Resilienz?

Ich höre viele Leute über Resilienz sprechen. Schließlich ist es in Mode gekommen, „resilient“ zu sein oder zumindest eine „resiliente IT“ zu haben. Ich spreche mit IT-Entscheidungsträgern, die behaupten, sie hätten eine resiliente IT. Ich sehe Anbieter, die die Resilienz ihrer Lösungen anpreisen. Ich spreche mit Entwicklern, die resiliente Software schreiben wollen. Und so weiter.

Die Frage, die mir immer sofort in den Sinn kommt, ist: Reden wir über dasselbe? Ist es wirklich Resilienz, über die du sprichst, oder sprichst du über etwas anderes?

Was also ist Resilienz?

Vielleicht sollten wir vor der Beantwortung dieser Frage zunächst einmal aufzeigen, was Resilienz nicht ist.

Ich war überrascht, als ich feststellte, dass die Menschen dazu neigen, Dinge als resilient zu betrachten, die über einen längeren Zeitraum hinweg funktionieren. Die Argumentation lautet: Es hat bisher funktioniert. Also muss es resilient sein.

Ist es aber nicht!

*Etwas ist nicht resilient, nur weil es über einen längeren Zeitraum hinweg funktioniert.*

Wenn etwas über einen längeren Zeitraum hinweg funktioniert, beweist das nur, dass seine Grundkonstruktion unter den erwarteten Bedingungen funktioniert. Das ist alles. Mehr nicht.

Die Resilienz oder das Fehlen derselben zeigt sich, wenn etwas Unerwartetes, etwas außerhalb der erwarteten Bedingungen geschieht. Denk z. B. an Lieferketten. Viele Menschen waren davon überzeugt, dass die globalen Versorgungsketten sehr resilient sind, weil sie gut funktionieren. Sie funktionierten jedoch nur so lange gut, wie alles wie erwartet innerhalb sehr enger Toleranzgrenzen ablief.

Nun wollen wir etwas Unerwartetes hinzufügen. Hallo, Ever Given! Ein einziges Schiff blockierte den Suezkanal für ein paar Tage, und es dauerte Monate, bis sich die weltweiten Lieferketten davon erholt hatten – auch an Orten, die keine Verbindung zum Suezkanal hatten. So viel zur Resilienz. Die globalen Versorgungsketten sind nicht resilient. Sie funktionieren nur dann wie erwartet, wenn nichts Unerwartetes passiert.

Womit wir wieder bei der Frage wären: *Was ist Resilienz?*

Natürlich gibt es, wie bei vielen anderen Themen auch, im Internet die üblichen Besserwisser, die behaupten, die maßgebliche Wahrheit über Resilienz gepachtet zu haben. Das Problem ist, dass es mehr als eine einzige Person gibt und alle eine andere maßgebliche Wahrheit gepachtet haben, auf der sie bestehen, was die Dinge kompliziert macht.

Deshalb habe ich einen anderen Ansatz versucht. Ich habe Definitionen von Resilienz aus verschiedenen Quellen und Bereichen nachgeschlagen und versucht, auf dieser Grundlage eine vereinigende Quintessenz herauszudestillieren. Dabei besteht immer noch die Gefahr, dass ich beim Herausdestillieren der Quintessenz ein wichtiges Detail übersehen habe. Aber zumindest wird so der Ansatz einer einzigen, überlebensgroßen Autorität vermieden, der von den Anhängern der Autorität oft in eine dogmatische „Entweder Sie unterwerfen sich unserer Definition oder Sie sind unser Feind“-Überzeugung verwandelt wird. (1)

Ich habe also Bereiche wie Psychologie, Ökologie, Lieferkettentheorie, Organisationstheorie, Systemtechnik, IT und mehr durchforstet. Ich habe mir auch die Definitionen angesehen, die einige der führenden Köpfe auf dem Gebiet der Resilienz wie Erik Hollnagel und David Woods entwickelt haben. Insgesamt habe ich mich durch mehr als zwei Dutzend Definitionen gearbeitet (2) und versucht, eine gemeinsame Quintessenz zu destillieren. Dies führte mich zu der folgenden Definition von Resilienz:

*Resilienz ist die Fähigkeit, mit widrigen Ereignissen und Situationen erfolgreich umzugehen, einschließlich*

*1. dem Umgang mit erwarteten widrigen Ereignissen und Situationen (Robustheit)
2. dem Umgang mit unerwarteten widrigen Ereignissen und Situationen (Bewältigung von Überraschungen)
3. der Verbesserung aufgrund widriger Ereignisse und Situationen (Antifragilität)*

Beachte, dass Robustheit allein (der erste Teil der Definition) nicht gleichbedeutend mit Resilienz ist. Man muss auch in der Lage sein, *unerwartete* negative Ereignisse und Situationen erfolgreich zu bewältigen (der zweite Teil der Definition). Ohne die Fähigkeit, auch mit erwarteten Ereignissen und Situationen erfolgreich umgehen zu können, ist die Fähigkeit, mit Überraschungen umzugehen, jedoch von geringem Wert. Man braucht beides, um Resilienz zu realisieren. (3)

Nicht alle Definitionen von Resilienz schließen ausdrücklich die Fähigkeit ein, sich aufgrund von Widrigkeiten zu verbessern (der dritte Teil der Definition). Wenn man jedoch tiefer in das Kleingedruckte der Definitionen eintaucht, beinhalten die meisten Definitionen die Anpassung an Veränderungen oder sogar Transformation. Letztendlich ist es meiner Meinung nach kein Zeichen für echte Resilienz, wenn man immer wieder mit der gleichen Art von Problemen konfrontiert wird (auch wenn sie möglicherweise in verschiedenen Formen auftreten) und nicht darüber nachdenkt, wie man sich so anpassen kann, dass diese Art von Problemen weniger wahrscheinlich wird. Deshalb und weil viele Definitionen von Resilienz dies ausdrücklich einschließen, habe ich auch dieses Konzept in die Definition aufgenommen.

### Beispiele für widrige Ereignisse und Situationen

Da wir nun wissen, was Resilienz ist, sollten wir kurz darüber nachdenken, was solche widrigen Ereignisse und Situationen im Zusammenhang mit der IT umfassen könnten:

- Die meisten Leute, mit denen ich gesprochen habe, denken zuerst an Hardware-Ausfälle und erst in zweiter Linie an Überlast-Situationen.
- Nicht wenige setzen Resilienz mit IT-Sicherheit gleich und somit widrige Ereignisse mit Cyberangriffen.
- Einige denken auch an Situationen, in denen ein zentraler Prozess (zu) langsam antwortet.
- Manche denken auch an Fehler bei den Eingabeparametern, d. h. an Eingaben, die nicht korrekt verarbeitet werden können.
- Nur wenige Menschen denken an Probleme wie einen Firmware-Fehler in einer Infrastrukturkomponente wie z. B. einem Switch.
- Auch an einen kritischen Software-Fehler als potenzielle Fehlerquelle denken nur wenige.
- Nur sehr wenige Menschen denken über tatsächliche Überraschungen nach. Ich hatte z. B. einmal die Situation, dass die dreifach redundante Kühlung unseres (einzigen) Rechenzentrums gleichzeitig ausfiel. Infolgedessen kam es bei allen Produktionsservern zu Notabschaltungen aufgrund von Überhitzung. Niemand (auch ich nicht) hatte erwartet, dass eine solche Situation jemals eintreten könnte.
- Außerdem betrachten nur sehr wenige Menschen die Geschäftsdomäne als Quelle von Überraschungen. Stell dir z. B. vor, dein stärkster Konkurrent bringt ein bahnbrechendes neues Produkt auf den Markt. Wenn du nicht in der Lage bist, sehr schnell zu reagieren, wirst du viele Kunden an deinen Konkurrenten verlieren und im schlimmsten Fall deine Überlebensfähigkeit einbüßen. Aufgrund der [Folgen der laufenden digitalen Transformation](https://www.ufried.com/blog/responsible_it_1/#digital-transformation-is-poorly-understood) betrifft dies deine IT-Organisation in gleicher Weise.

Und so weiter. Und wir haben noch nicht über die wirklich großen Unsicherheitsfaktoren gesprochen, wie eine globale Krise (COVID oder Klimawandel fallen mir als zwei populäre Beispiele ein) oder die grundsätzlich unvorhersehbaren zukünftigen geopolitischen und wirtschaftlichen Entwicklungen. (4)

Wie wir sehen, umfassen widrige Ereignisse und Situationen im Zusammenhang mit der IT viel mehr als nur die üblichen erwarteten technischen Probleme. Allerdings sehe ich nur wenige Menschen, die solche Themen – insbesondere Überraschungen – im Sinn haben, wenn sie über Resilienz sprechen. Wir werden tiefer in diese Diskussion eintauchen, wenn wir die Frage erörtern, wie wir resilient werden können.

### Resilientes Software-Design

Bevor ich diesen ersten Blog Post abschließe, möchte ich noch eine ergänzende Definition hinzufügen: die Definition von resilientem Softwaredesign. Resilient Software Design (RSD) ist ein Thema, über das einige Leute (mich eingeschlossen) oft sprechen. Es ist jedoch wichtig, den Unterschied zwischen Resilienz und RSD zu verstehen.

Meine Definition für RSD:

***Resilientes Softwaredesign** bedeutet, softwarebasierte Systeme so zu entwerfen und zu bauen, dass ihre Zuverlässigkeit (Dependability) verbessert und somit die Resilienz im Sinne der obigen Definition unterstützt wird.*

Wer einen Moment über diese Definition nachdenkt, wird feststellen, dass Softwarelösungen für sich genommen nicht wirklich resilient sind. Sie können robust sein. Es ist jedoch im Grunde unmöglich, Code für den Umgang mit Überraschungen zu implementieren, d. h. mit etwas, das man nicht erwartet, von dem man nicht einmal weiß, dass es überhaupt passieren kann. Wenn du Glück hast, wird dein Code zufällig mit der Überraschung erfolgreich umgehen. Aber das wäre nur Glück. Normalerweise wird dein System im Angesicht einer negativen Überraschung einfach versagen.

Aber selbst wenn ein Softwaresystem nicht von sich aus resilient ist, ist es von großem Wert, wenn es robust ist, d. h. wenn es mit bekannten und erwarteten negativen Ereignissen umgehen kann. Wie oben geschrieben: Ohne diese Fähigkeit ist die Fähigkeit, mit Überraschungen umzugehen, von geringem Wert: „Hey, wir sind perfekt auf Überraschungen vorbereitet. Aber unsere Systeme stürzen unweigerlich ab, wenn irgendein Teil von ihnen zeitweise unerreichbar ist.“

Robustheit ist also ein notwendiger Schritt auf dem Weg zur Resilienz. Bei RSD geht es darum, robuste IT-Lösungen zu schaffen. (5)

### Zusammengefasst

Wir haben unsere Reise in Richtung Resilienz damit begonnen, zu klären, was Resilienz ist. Dies ist eine wichtige Voraussetzung für unsere Reise, denn basierend auf dem, was ich beobachte, meinen die meisten Menschen nicht Resilienz, wenn sie Resilienz sagen. Wir haben auch einige Beispiele für widrige Ereignisse und Situationen angeführt, um zu verdeutlichen, was Resilienz ist. Schließlich haben wir zwischen Resilienz und resilientem Softwaredesign unterschieden.

Nach diesen notwendigen Vorbereitungen, dem Packen des Rucksacks und der Ausrüstung sind wir nun bereit, unsere Reise anzutreten. Im nächsten Beitrag werden wir die Reise mit einem Blick auf den Ort beginnen, an dem viele Unternehmen immer noch leben, und erörtern, warum es keine gute Idee mehr ist, dort zu verweilen. Bleibt dran …

1. Natürlich werden mich all diese Jünger zu einem Feind erklären, weil ich mich ihrem Glauben nicht blindlings unterworfen habe. Aber gut, damit werde ich wohl leben müssen. 
2. Ich werde hier nicht alle Definitionen auflisten, denn das wäre ein eigener Beitrag. Ich schreibe derzeit ein Buch über resilientes Softwaredesign, in dem ich einige der Definitionen, die ich durchgegangen bin, zitiere und diskutiere (ich habe Definitionen weggelassen, die im Grunde nur Wiederholungen der Definitionen waren, die ich aufgelistet habe). Leider weiß ich im Moment nicht, wann ich die Zeit finden werde, das Buch fertigzustellen. Bitte habt also Geduld mit mir.
3. Manchmal hört man Leute aus der Systemtechnik, die darauf beharren, dass Robustheit nicht Teil von Resilienz ist. Ich persönlich denke, dass dies darauf zurückzuführen ist, dass die meisten dieser Leute aus sicherheitskritischen Bereichen kommen. In sicherheitskritischen Bereichen können (und werden) Menschen sterben, wenn das System ausfällt. Daher werden all diese Systeme mit Blick auf Robustheit gebaut, d. h. Robustheit ist in diesen Bereichen im Grunde eine Selbstverständlichkeit. Die Herausforderung für diese Menschen besteht nicht darin, die Systeme robust zu machen (denn das sind sie bereits), sondern sich auf Überraschungen vorzubereiten. Daher vermute ich, dass diese Leute durch die Eigenschaften ihrer Domäne ein wenig in die Irre geführt werden, wenn es um Resilienz geht. In der IT, insbesondere in der Unternehmens-IT, sind wir jedoch weit davon entfernt, robuste Systeme zu bauen. Daher halte ich es für wichtig, auch die Bedeutung der Robustheit als notwendige Voraussetzung für die Entwicklung von Resilienz zu betonen.
4. Ich werde diese globalen Unsicherheitsfaktoren (und damit verbundenen Überraschungen) in dieser Beitragsserie nur am Rande streifen, da diese Themen für die meisten von uns „jenseits unserer Gehaltsklasse“ liegen. Es ist jedoch wichtig, sich vor Augen zu halten, dass ein völliges Ignorieren dieser Themen leicht zu einem lebensbedrohlichen Risiko für ein Unternehmen werden kann.
5. In dieser Blogserie lasse ich wirklich unangenehme Fehlermodi wie metastabile Fehler aus, d. h. Fehlermodi, die auch dann noch auftreten, wenn die ursprüngliche Fehlerursache aufgrund unerwarteter Nebeneffekte von Robustheitsmaßnahmen beseitigt worden ist. Wenn du tiefer in dieses Thema eintauchen möchtest, empfehle ich, mit der wissenschaftlichen [Abhandlung](https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf) „Metastable Failures in Distributed Systems“ von Bronson et al. und der [Abhandlung](https://www.usenix.org/publications/loginonline/metastable-failures-wild) „Metastable Failures in the Wild“ von Lexiang et al. zu beginnen, das eine praktische Untersuchung des Themas enthält. 

*Dieser Blogpost ist [ursprünglich auf Englisch](https://www.ufried.com/) in Uwe Friedrichsens Blog erschienen*

Was ist Resilienz in IT-Systemen? Uwe Friedrichsen erklärt, wie Robustheit und Denkmodelle helfen, unerwartete Herausforderungen zu meistern. Jetzt lesen!

Was ist Resilienz? Grundlagen für IT-Systeme.

Der lange und steinige Weg zur Resilienz – Teil 1

Lead API Consultant

Senior Solution Architect / Head of API Consulting

In vielen Projekten entstehen technisch funktionale APIs ohne echten Fokus auf die Fachlichkeit und spätere Nutzung. Oft folgt die Entwicklung immer noch einem klassischen Muster: Ticket zuweisen, Schnittstelle implementieren und Ticket abschließen. Was dabei fehlt: die Perspektive derjenigen, die diese APIs später tatsächlich verwenden. Genau an dieser Stelle setzt API Thinking als Denkweise an, um APIs konsequent nutzerzentriert und strategisch zu gestalten.

Der Begriff "API Thinking" ist inspiriert von [Design Thinking](https://wirtschaftslexikon.gabler.de/definition/design-thinking-54120) und dem [Design Sprint](https://www.thesprintbook.com/the-design-sprint), geprägt durch unsere Erfahrungen aus der Praxis. Gemeinsam mit Impulsen von [Dr. Martin Kiel](https://www.the-black-frame.de) haben wir API Thinking entwickelt, um APIs nicht nur technisch zu implementieren, sondern als bewusst gestaltete Produkte zu verstehen: mit Wert, Zweck, klaren Verantwortlichkeiten und klarer Zielgruppe.

## Was steckt hinter API Thinking?

API Thinking bedeutet, APIs nicht als rein technische Komponenten zur Systemintegration zu betrachten, sondern als Teil eines größeren Zusammenhangs. Im Kern geht es darum, sich frühzeitig mit den Bedürfnissen der Konsumierenden einer API auseinanderzusetzen. Seien es Entwicklungsteams, Fachabteilungen oder externe Partner. Ja, APIs sind Schnittstellen, aber eben auch Zugangspunkte zu geschäftlichen Funktionen, Daten und Prozessen. APIs stehen damit im Spannungsfeld zwischen Technologie, Fachlichkeit und Erwartungen der Nutzerinnen und Nutzer. Sie sollen Probleme lösen und echten Mehrwert bieten. Wer APIs gestaltet, muss also verstehen, wer sie nutzt, in welchem Kontext das geschieht und was eine einfache und wertstiftende Nutzung überhaupt ausmacht. Das erfordert die Bereitschaft, Designentscheidungen nicht nur technisch, sondern auch strategisch zu treffen.

Gleichzeitig gilt: APIs entstehen nicht im luftleeren Raum. Sie sind eingebettet in Datenmodelle, Prozesse und Organisationen. API Thinking nimmt diese Verflechtung ernst. Es betrachtet APIs als Produkte, die entwickelt, betreut und weiterentwickelt werden. Das beinhaltet auch die Verantwortung für ihre Qualität, Nutzbarkeit und Zukunftsfähigkeit.

## Vom Denken ins Tun: Das Modell hinter API Thinking

API Thinking ist kein starrer Prozess, sondern ein Modell für einen iterativen Ansatz  Ein strukturierter Rahmen hilft dabei, die Idee greifbar zu machen:

![de_api_thinking.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma0qc0oagw2a08ulvtbikb6o)

Am Anfang steht das Verständnis der Stakeholder. Wer nutzt die API? Wofür? Was bedeutet für diese Personen "gute Nutzungserfahrung"? Statt Zielgruppen abstrakt zu beschreiben, geht es darum, konkrete Perspektiven einzunehmen, etwa durch strukturierte Workshops, Interviews oder die Analyse bestehender Nutzungsmuster.

Aufbauend auf dem Verständnis für die Stakeholder wird definiert, welche Daten eine Rolle spielen. Das erfolgt nicht technisch, sondern inhaltlich. Was wird wirklich gebraucht? In welcher Qualität und Aktualität? 

Erst danach folgt das API-Design: Welche Interaktionsmuster passen? Welcher Detailierungsgrad ist sinnvoll? Wie bleibt die Schnittstelle konsistent und verständlich?

Die Implementierung ist dann ein Ergebnis dieser Überlegungen und nicht ihr Ausgangspunkt. Und sie ist auch nicht das Ende: Eine API wird idealerweise frühzeitig durch Stakeholder validiert, Feedback wird aktiv eingeholt, neue Erkenntnisse fließen wieder zurück. So entsteht nicht nur ein funktionierender Endpunkt, sondern eine tatsächlich nutzbare und nutzbringende API.

## Abgrenzung: Was API Thinking nicht ist

API Thinking wird gern mit Begriffen wie API First oder API Management vermischt, dabei gibt es klare Unterschiede. API Thinking ist keine Methode, kein Toolset und kein Architekturprinzip, sondern eine Denkweise.

Während API First eine organisatorische Entscheidung beschreibt, APIs frühzeitig in den Mittelpunkt zu stellen, liefert API Thinking die inhaltliche Grundlage dafür, eine konkrete API zu erstellen. Es beleuchtet die API aus einem Produktgedanken heraus: Warum braucht es diese API überhaupt? Wer profitiert davon? Und wie wird sie gestaltet, damit sie echten Nutzen bringt?

API Design First bedeutet, das API-Design vor der Implementierung bewusst zu definieren, idealerweise mit Blick auf Wiederverwendbarkeit und Konsistenz. Doch auch hier gilt: Ohne Verständnis für die eigentlichen Nutzenden bleibt die API oft technisch sauber, aber fachlich wenig relevant.

Und API Management? Das kümmert sich um den Betrieb, das Monitoring, die Sicherheit und weitere Querschnittsthemen. Auch das ist wichtig, greift aber erst, wenn die API bereits erstellt ist. API Thinking setzt viel früher an: Es klärt, ob und wie eine API überhaupt sinnvoll ist.

## Was API Thinking für verschiedene Rollen bedeutet

API Thinking wirkt auf mehreren Ebenen und betrifft nicht nur Entwicklung und Architektur.

Für Entwicklungsteams bedeutet es, APIs nicht nur umzusetzen, sondern mitzugestalten. Sie übernehmen Verantwortung für Verständlichkeit, Konsistenz und Wartbarkeit und treten in Dialog mit ihren Nutzerinnen und Nutzern, um deren Bedürfnisse zu verstehen. 

Für Produktverantwortliche werden APIs sichtbarer Teil der Wertschöpfung, mit eigenen Nutzenden, Erfolgsmetriken und strategischer Relevanz. APIs sind kein technisches Nebenprodukt, sondern ein bewusster Bestandteil des Produktportfolios und können somit messbar zum Geschäftserfolg beitragen.

Architektinnen und Architekten können mithilfe von API Thinking Systeme strukturieren, Verantwortung klären und Komplexität reduzieren, zum Beispiel durch klar definierte technische Verträge zwischen Domänen. 

Und für alle Rollen im Business-Kontext öffnen APIs mit der richtigen Denkweise neue Türen: für Partnerschaften, neue digitale Erlösmodelle oder effizientere Prozesse. Nicht die API selbst steht im Vordergrund, sondern das, was sie ermöglicht.

## Vom Konzept zum Geschäftswert

APIs entfalten ihren Wert nicht allein durch saubere Technik, sondern durch ihre Wirkung im jeweiligen Kontext. Eine API wird zum echten Business-Enabler, wenn sie Prozesse beschleunigt, Integration vereinfacht oder neue Märkte zugänglich macht. Das gelingt aber nur, wenn sie auch genutzt wird und das wiederum setzt gute Gestaltung voraus. Wenn die Bedürfnisse der Zielgruppe bekannt sind, kann eine API verständlich, relevant und vertrauenswürdig umgesetzt werden. Das spart Aufwand, erhöht die Akzeptanz und verbessert die Qualität des Gesamtprodukts. API Thinking unterstützt dabei, diesen Zusammenhang herzustellen. Es hilft, technische Schnittstellen mit strategischen Zielen zu verknüpfen und die Frage nach dem "Warum" konsequent mitzudenken, egal ob intern oder extern, ob für Menschen oder Maschinen.

## Fazit: Denken statt nur machen

API Thinking ist kein Framework, kein Template, kein Werkzeugkasten. Es ist eine Denkweise. Eine, die APIs nicht als technischen Selbstzweck betrachtet, sondern als Teil einer größeren Idee: Nutzende befähigen, Wert schaffen, Systeme vernetzen. Wer APIs ausschließlich baut, weil es technisch notwendig ist, verschenkt Potenzial. Wer hingegen versteht, wie und warum sie genutzt werden, schafft Schnittstellen, die funktionieren, wachsen und dauerhaft gebraucht werden.

Die entscheidenden Fragen bei der API-Erstellung lauten nicht: "Welche Methode wenden wir an?" oder "Welches Tool setzen wir ein?". Sondern: "Für wen machen wir das?", "Welches Problem lösen wir?" und "Wie bleibt unsere Schnittstelle langfristig relevant?"

**API Thinking liefert dafür keine fertigen Antworten. Aber es hilft, die richtigen Fragen zu stellen.**


Erfahren Sie, wie nutzerzentrierte APIs echten Mehrwert schaffen & Geschäftserfolge fördern.

API Thinking – mehr als nur Schnittstellenentwicklung

Senior Agile Consultant

**Kann man mit KI wirklich Anwendungen erzeugen, ohne selbst coden zu können, mit einem Bruchteil des Aufwands und der Zeit?**

"Gib dich dem *Vibe* hin! Erstelle Software nur mit natürlicher Sprache! GenAI ist der *Builder*. Hör auf, dich zu beschweren und fang mit builden an!" So oder so ähnlich liest man es neuerdings in den Sozialen Medien. 

Was ist dran an dem "vibe coding"? 

Der Begriff "vibe coding" wurde von [Andrej Karpathy in einem Tweet Anfang Februar 2025](https://x.com/karpathy/status/1886192184808149383) geprägt. Andrej war Direktor für Künstliche Intelligenz bei Tesla und hat davor und danach für OpenAI an ChatGPT gearbeitet. Sicher weiß der Mann, wovon er spricht.

In seinem Tweet beschreibt er, was er mit "vibe coding" meint: Sich nicht um den Code kümmern, sondern ausschließlich KI-gestützte Werkzeuge nutzen. Alle Vorschläge der KI immer annehmen, Fehlermeldungen 1:1 einfach an die KI geben und diese den Fehler beheben lassen. Er beschreibt diese Art, Software zu entwickeln, begeistert und in leuchtenden Farben.

Wichtig ist, den Begriff "vibe coding" abzugrenzen: Nicht jeder Einsatz von Generativer KI (GenAI oder einfach nur KI) ist "vibe coding". Wer Copilot, ChatGPT, Claude, aber auch Cursor oder Windsurf und so weiter nur als eines von vielen Werkzeugen nutzt, um Code zu schreiben, zu verändern oder zu verstehen, der ist noch lange kein "vibe coder". Mit diesem speziellen Begriff ist ausschließlich eine Arbeitsweise mit GenAI gemeint, bei der man sich gar nicht oder fast gar nicht um den erzeugten Code kümmert. Das ist dann die Aufgabe der KI.

Seit dem Tweet von Andrej Karpathy ist der Begriff “vibe coding” überall im Netz zu finden. Allerdings sind die Reaktionen häufig nicht besonders positiv. Die Memes reichen von Witzen:


![vibe-coding-meme1.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cm8kf56lwwnsv07up1g7z0psv)

bis zu eher katastrophalen Meldungen:

![vibe-coding-meme2.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cm8kf766mvs3g07un67a6fipb)

Wie kann das sein? Wieso kann etwas, das ein echter Profi derartig anpreist, eine so ablehnende Reaktion hervorrufen oder gar katastrophale Wirkung haben? Kommen diese Memes nur von Entwicklern, die um ihren Job fürchten?

Schauen wir einmal an dem Hype vorbei und werfen einen Blick darauf, welche Werkzeuge es gibt, was KI-gestützte Softwareentwicklung kann und was sie vielleicht auch (noch) nicht kann.

### Die Agenten kommen

GenAI à la ChatGPT – also einfach einen Prompt eingeben und eine Antwort erhalten – war gestern. Die nächste Generation von KI-Tools sind sogenannte Agentensysteme. Das sind Lösungen, die KI nutzen, um einen Plan zu erstellen, der dann Schritt für Schritt durch "klassische Tools" und auch KI abgearbeitet wird. Prominente Vertreter dieser Gattung für Softwareentwicklung sind [Cursor](https://www.cursor.com/), [Windsurf](https://codeium.com/windsurf) oder auch [V0](https://v0.dev/) und seit Neuestem auf [Github Copilot](https://github.com/features/copilot) mit dem Agenten-Modus.

Derartige Agenten-KI-Tools können selbstständig Programmcode lesen, Vereinbarungen in der Architekturdokumentation nachschlagen, Code entsprechend der Vorgaben erstellen oder ändern, Compile-Fehler korrigieren und auch Tests schreiben und ausführen.

Zwar kann eine solche Aktion etliche Minuten dauern (und viele Token in den KI verbrauchen, die viele Euro kosten), liefert dann aber bedeutend hochwertigere Lösungen als der "einfache" Dialog mit einer KI. Das kann im Einzelfall die Arbeit von Stunden oder vielleicht sogar Tagen ersetzen.

Ich persönlich erwarte, dass sich die Qualität der eigentlichen KI-Modelle (ChatGPT, Claude etc.) in der näheren Zukunft nicht deutlich weiter steigern wird, wohl aber die Qualität der Agenten, die KI mit klassischer Automatisierung kombinieren.

### Die Stärken und Schwächen von GenAI in der Softwareentwicklung

Ich arbeite seit über einem Jahr in Kundenprojekten mit Github Copilot und habe in meiner Freizeit bereits eine Menge an (Agenten-) KI-Werkzeugen ausprobiert. Daneben habe ich mich mit meinen Kolleginnen und Kollegen ausgetauscht, die ebenfalls Erfahrungen mit KI-unterstützter Entwicklung haben. Die Bilder decken sich:

Zu den **Stärken von GenAI / KI in der Softwareentwicklung** gehören demnach:

- **Übernehmen von repetitiven Aufgaben** Beispiele sind das wiederholte Füllen von Datenstrukturen oder Durchführen von Mappings, sowie das Aufsetzen von Grundgerüsten für Softwarekomponenten.
- **Zugriff auf gelöste Probleme** Damit ist gemeint, dass es in vielen Fällen schneller und nützlicher ist, eine KI nach einer Lösung für ein Problem zu fragen, als die Suchmaschine der Wahl anzuwerfen oder in Stackoverflow nachzuschauen. Besonders, wenn die KI Zugriff auf den eigenen Code hat (als Plugin in der IDE), ist die Lösung häufig besser auf die eigene Situation zugeschnitten als alles, was man im Netz finden kann.
- **Erzeugen von kreativen Lösungen** Manchmal liefert die KI für eine Aufgabe eine besonders effektive oder effiziente Lösung, an die man selbst gar nicht gedacht hätte. Mit dem oben vorgestellten V0 kann man sich z. B. Vorschläge für UI oder sogar ganze UX Flows erzeugen lassen.
- **Erstellen einzelner Module oder Funktionen** Ist eine gewünschte Funktionalität einfach und vollständig zu beschreiben, können KI-Lösungen hier eine Menge hilfreicher Programmzeilen bauen.

Das liest sich beeindruckend und das ist es auch. Generative KI ist in den letzten zwei Jahren extrem gut geworden – auch im Rahmen der Softwareentwicklung. Ist also der Hype um "vibe coding" gerechtfertigt? Ersetzt die KI im Agentensystem die Softwareentwickler?

Nun, um diese Frage zu beantworten, müssen wir auch einen Blick auf die Schwächen von KI werfen. Diese Liste gilt auch für Agentensysteme:

- **Beherrschen von Komplexität.** Wenn eine Software wächst, steigt die Menge an Informationen, Regeln, Absprachen etc., die berücksichtigt werden müssen, in der Regel nicht linear, sondern nahezu exponentiell. Eine KI kann diese Menge irgendwann nicht mehr berücksichtigen und beachten. Diese Schwäche gleichen die o. g. Tools durch immer größere Kontexte aus, sowie durch spezielle Dateien, die im Projekt liegen können, in denen man z. B. Coding Richtlinien hinterlegen kann. Komplexität ist also im Moment noch ein Problem, aber es kann in der Zukunft kleiner werden. Ich persönlich bin aber nicht davon überzeugt, dass an dieser Stelle KI den Menschen überholen wird. Mal sehen.
- **Korrekte Funktionsweise sicherstellen** KI versteht nicht, was sie selbst tut. Im Kern wird immer nur das nächste Wort oder das nächste Stück Code erzeugt. KI kann also niemals vollständig verhindern, dass Aktionen unerwünschte Nebenwirkungen haben. Je komplexer eine Anwendung aber ist, desto aufwändiger und fehleranfälliger ist es, manuell die korrekte Funktionsweise sicherzustellen. Automatisierte Tests können hier helfen, aber man muss in einem solchen Fall die Tests anders schreiben, als man es derzeit tut, um den selbst geschriebenen und damit bekannten Code zu testen.
- **Der Output von KI ist nicht deterministisch.** Die große Stärke von KI, nämlich die (gefühlte) Kreativität, ist gleichzeitig eine große Schwäche. Wie weiter oben gesagt, kann KI z. B. das Grundgerüst für neue Komponenten erstellen. Dabei ist es aber möglich bis wahrscheinlich, dass manche dieser Komponenten unterschiedlich strukturiert werden. Zwar funktionieren sie, aber sie sind nicht miteinander vergleichbar. Je öfter man dann diesen Code ändern lässt (z. B. durch neue Anforderungen), desto mehr driften die unterschiedlichen Code-Teile auseinander.
- **Wartbarkeit** Eng mit dem Punkt davor verbunden ist zunehmend auffällig, dass KI-generierter Code schwerer wartbar ist als Code, der einen vernünftigen 4-Augen-Review-Prozess durchlaufen hat. Das hat zur Folge, dass es nach dem "vibe coding" schwerer ist, die Anwendung zu ändern oder zu erweitern.
- **Berücksichtigung von Qualitätsanforderungen wie z. B. Betriebssicherheit, IT-Sicherheit, vernünftiger Umgang mit Ressourcen etc.** KI-Systeme haben anhand von Code aus dem Internet "programmieren gelernt". Ein großer Teil dieses Codes berücksichtigt die oben genannten Qualitätsanforderungen nicht (ausreichend) und die KI demnach auch nicht. Das liegt daran, dass ein Großteil des Programmierwissens der KIs aus Tutorials oder Anleitungen gezogen wird. Und in denen ist IT-Security oder ressourcenschonender Umfang häufig kein Thema. Besonders kritisch wird es, wenn jemand, der oder die selbst keine Ahnung von IT hat, eine Lösung ins Netz stellt, die genau diese Anforderungen nicht berücksichtigt hat. Potenzielle Angreifer haben so leichten Zugriff auf unsichere Systeme; die Folgen sind nicht abzuschätzen, aber möglicherweise gravierend. Das zweite oben dargestellte Meme zeigt dieses Problem deutlich. (Ich hoffe sehr, dass das nicht wirklich passiert ist.)

## Was ist denn nun richtig? KI einsetzen oder nicht?

Die vorherige Gegenüberstellung zeigt das aktuelle Dilemma. Manch einer sieht vor allem die Stärken und proklamiert den Untergang des Berufsstandes der Softwareentwickler, andere möchten KI am liebsten überhaupt nicht nutzen.

Ich denke, in beiden Standpunkten liegt ein Kern der Wahrheit. Ich persönlich würde folgende Bewertung vornehmen:

- Mithilfe von KI kann man sehr schnell und effizient *bestimmten* Code erzeugen.
- Es ist erstaunlich, wie gut und kreativ die Lösungen manchmal sind.
- Es macht Spaß, mit diesen Werkzeugen zu arbeiten, wenn man den Umgang einmal gelernt hat.

Aber: 

- Gerade bei großen Anwendungen (also eigentlich alle, die wir im Kundenauftrag erstellen) gerät man sehr schnell an Grenzen, wo die KI nur noch wenig helfen kann oder sogar Schaden anrichtet.
- Kaum jemand würde den Code 1:1 in Produktion übernehmen. In jedem Fall muss man sich den Code sehr gründlich und kritisch anschauen – kritischer, als man den Code einer Kollegin oder eines Kollegen prüfen würde.

## Hat Andrej Karpathy also unrecht?

Nein, hat er nicht. Denn die meisten Leute übersehen einen sehr wichtigen Satz in seinem Tweet: "*It's not too bad for throwaway weekend projects, but still quite amusing.*" Er selbst beschreibt "vibe coding" also als Methode und Werkzeug für **Wegwerfprojekte am Wochenende**. Kein Satz darüber, dass er hier an den echten, produktiven Einsatz denkt.

Das entgeht vielen offenbar.

Beachtet man die vorgenannten Risiken des vibe codings, sehe ich persönlich durchaus ein paar professionelle Einsatzgebiete:


- **Rapid prototyping** 
Mit Agenten-KI kann man sehr leicht Beispielanwendungen bauen, die viel mehr sind als reine Klick-Dummys. Man kann sie für Anwendertests einsetzen oder um Stakeholdern “anfassbare” Lösungsansätze zu präsentieren, nicht aber, um sie in Produktion zu bringen.
- **Ideen generieren** Gerade Tools, die auch UIs erzeugen, können sehr hilfreich sein, um in der Discovery Phase die Lösung iterativ zu erkunden.
- **Erstellen einzelner Code-Blöcke und Module** Gerade, wenn etwas mit ein paar Sätzen vollständig beschreibbar ist, können solche Tools auch produktiven Code erzeugen. Nur muss man ihn gründlich prüfen.

Und was ist mit den kühnen Behauptungen, dass KI die Softwareentwickler überflüssig macht?

Um die Frage zu beantworten schaue man sich am besten an, *wer* solche Behauptungen aufstellt und welche Ziele die Person verfolgt: Sind es es Toolhersteller, die das nächste KI-Werkzeug verkaufen wollen (wobei die meisten von ihnen mittlerweile vorsichtiger argumentieren)? Ist es die Geschäftsleitung, die einen Personalabbau begründen will? Sind es Menschen im Fachbereich, die von KI gehört haben, und die Lösungen eher morgen als übermorgen haben möchten? Oder sind es Anfänger in der Softwareentwicklung, die meinen, man könnte die Lernkurve auf diese Weise abkürzen?

Bisher jedenfalls habe ich keine solche Behauptung von einem erfahrenen Softwareentwickler oder einer Softwareentwicklerin gehört.

Nun könnte man sagen, das seien ja auch genau diejenigen, die ersetzt werden sollen. Das stimmt prinzipiell. Aber es sind auch die einzigen, die eine professionelle Einschätzung geben können. Und – nicht zu vergessen: Die meisten meiner Kolleginnen und Kollegen nutzen die KI-Tools oft und gerne. Wir fühlen uns nicht bedroht durch die Technik. Die Bedrohung kommt – wenn überhaupt – von Entscheidungsträgern, die den überzogenen Behauptungen mehr glauben als ihren eigenen Kolleginnen und Kollegen.

## Fazit

Ich schließe mich Andrej Kaparthy an, "vibe coding" kann eine spannende und lustige Wochenendbeschäftigung und – manchmal – in kleinen Dosen auch im professionellen Umfang nützlich sein.

Niemals allerdings würde ich damit eine Anwendung live setzen. Mein Geld, meine Reputation und meine Sicherheit wären mir dafür viel zu kostbar.

Illustration von Mensch-Maschinen-Hybriden vor Computern

Vibe Coding, also das Erstellen von Code ausschließlich durch die KI, ist gerade groß in Mode. Wie realistisch ist es? Können wir bald auf Developer verzichten?

Vibe Coding – was nun?

Vibe coding – Was nun?

Der April, der April, der macht, was er will.

**Was ist der Patch Tuesday?**

Der Begriff bezeichnet den zweiten Dienstag im Monat, an dem Microsoft wichtige Patches für seine Systeme veröffentlicht. Durch den festen Rhythmus wird die Arbeit von Systemadministratoren und Nutzern erleichtert, da somit ein klarer Planungszeitpunkt zum Einspielen von Updates gegeben ist.

Der Patch Tuesday bringt im April 2025 unter anderem wichtige Sicherheitsupdates von Microsoft und schließt damit mehrere Sicherheitslücken.

Interessant ist die Schwachstelle [CVE-2025-29824](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-29824) - Windows Common Log File System Driver Elevation of Privilege Vulnerability. Lokale Angreifer können durch diese Lücke System-Rechte bekommen. Diese wird bereits aktiv ausgenutzt und sollte zügig gepatcht werden. Updates gibt es für Windows 11 und Windows Server. Der Patch für Windows 10 soll zeitnah geliefert werden.

Generelle Patches wurden für Windows 10 und Windows 11 herausgebracht sowie für die gängigen Server-Typen, siehe [hier](https://msrc.microsoft.com/update-guide/en-us/releaseNote/2025-apr).

SAP hat diesen Monat drei kritische Schwachstellen veröffentlicht. Zwei davon ([CVE-2025-27429](https://www.cve.org/CVERecord?id=CVE-2025-27429) und [CVE-2025-31330](https://www.cve.org/CVERecord?id=CVE-2025-31330)) betreffen Code Injection und sollten daher umgehend gepatcht werden. Mehr Informationen über die veröffentlichten Schwachstellen sind [hier](https://support.sap.com/en/my-support/knowledge-base/security-notes-news/april-2025.html) zu finden.

Weitere Hersteller, die Sicherheitsupdates herausgebracht haben, sind nachfolgend aufgelistet:

[Cisco](https://sec.cloudapps.cisco.com/security/center/publicationListing.x): Sicherheitsupdates für mehrere Produkte.

[Ivanti](https://forums.ivanti.com/s/article/Security-Advisory-EPM-April-2025-for-EPM-2024-and-EPM-2022-SU6?language=en_US&_gl=1*189yt27*_gcl_au*Nzg5MDg4OTc1LjE3MzY5MjE3ODQ.): Sicherheitsupdates für den Ivanti Endpoint Manager sowie Anfang des Monats eine Korrektur für eine [kritische Schwachstelle in Connect Secure](https://forums.ivanti.com/s/article/April-Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-22457?language=en_US), die von chinesischen Bedrohungsakteuren ausgenutzt wird.

[Fortinet](https://www.fortiguard.com/psirt?page=1&date=&severity=&product=FortiAP-W2,FortiAP-C,FortiSandbox,FortiManager,FortiAP-S,FortiOS,FortiAnalyzer-BigData,FortiAnalyzer,FortiAnalyzer%20Cloud,FortiExtender,FortiOS-6K7K,FortiSwitchManager,FortiManager%20Cloud,FortiAP,FortiSwitch,FortiAP-U&component=&version=): Sicherheitsupdates für mehrere Produkte, einschließlich einem Fix für eine kritische Schwachstelle, die es Angreifern ermöglicht, Admin-Passwörter in FortiSwitch zu ändern.

Apache: Fix für eine [kritische Sicherheitslücke](https://www.endorlabs.com/learn/critical-rce-vulnerability-in-apache-parquet-cve-2025-30065---advisory-and-analysis) in Apache Parquet.

Kurze Zusammenfassung der Sicherheitsupdates aus dem Patch Tuesday April 2025

Patch Tuesday April 2025

IT Consultant

YAML ist die gängige Konfigurationssprache im Container- und Kubernetes-Umfeld.  Das hat zum einen Vorteile, denn YAML besitzt wenige Konstrukte und spezielles Markup, das man sich merken muss. Andererseits wirft die Arbeit mit YAML auch einige Probleme auf, die andere Konfigurationssprachen lösen.

So kommt es bei YAML auf die Einrückungstiefe an, und wenn YAML-Dateien über String-Templates verarbeitet werden, führt das zu dem Effekt, der sich in vielen Helm-Charts wiederfindet: YAML wird in ein anderes YAML-File eingesetzt und die Helm-Commands "indent" oder "nindent" müssen für die richtige Einrückungstiefe sorgen:

```
apiVersion: v1
kind: Service
metadata:
  name: {{ service_name }}
  labels:
    {{- include "service.labels" . | nindent 4 }}
```

Ändert sich die Struktur der YAML-Dateien, müssen gegebenenfalls alle solchen Werte angepasst werden – das ist weder schön, noch sonderlich wartungsfreundlich. Ähnliche Probleme bringen Conditionals und andere Konstrukte mit sich, die String Templates bieten. Letzten Endes ist die ganze Herangehensweise fehleranfällig und reduziert die Möglichkeiten für Wiederverwendung und Modularität von Kubernetes-Konfiguration.

## Jsonnet fördert die Wiederverwendbarkeit

Einen Ausweg aus dem Dilemma eröffnen Konfigurationssprachen wie Jsonnet [1], die Konfiguration auf funktionale Weise managen und damit beispielsweise die Wiederverwendung von Config-Snippets ohne die oben beschriebenen Klimmzüge ermöglichen. Jsonnet ist eine Übermenge von JSON und bietet über die Markup-Funktionen hinaus einige wenige Merkmale einer richtigen Programmiersprache, zum Beispiel Funktionsaufrufe, Variablen und Conditionals. 

Ein Projekt, das auf Jsonnet aufbaut und mit Wissen über Kubernetes-Objekte ausstattet, ist Tanka [2] von den Grafana Labs. Tanka bietet insbesondere bei Kubernetes-Projekten gegenüber YAML etliche Vorteile, zum Beispiele deutlich kürzere und damit besser lesbare Konfigurationsdateien. Wer als Team auf Tanka setzt, kann sich eine eigene Bibliothek bauen, um den Grad an Wiederverwendung noch zu steigern. 

Ist das Tool installiert, lässt sich mit einem Aufruf ein Verzeichnis für Tanka initialisieren:
```
tk init
```
Damit werden diverse Dateien angelegt und auch die k8-libsonnet-Bibliothek installiert, um einfacher mit Kubernetes-Ressourcen zu arbeiten. Tanka unterstützt Environments, um etwa für Development und Production unterschiedliche Manifeste oder Werte zu verwenden. Standardmäßig installiert "tk init" ein Default-Environment, das sich in "environment/default" wiederfindet, wo wiederum die Datei "main.jsonnet" liegt, die den Einstiegspunkt darstellt – dazu muss übrigens das Binary von "jsonnet-bundler" installiert sein.  

Diese JSON-Datei (und somit Jsonnet-Datei) startet im Kubernetes-Cluster einen Pod, wenn sie mit "tk apply" angewendet wird.
```
{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "nginx-pod",
    "labels": {
      "app": "nginx"
    }
  },
  "spec": {
    "containers": [
      {
        "name": "nginx",
        "image": "nginx:latest",
        "ports": [
          {
            "containerPort": 80
          }
        ]
      }
    ]
  }
}
```
Die folgenden Zeilen importieren den Pod in das Main-Manifest "main.jsonnet":
```
local pod = import 'pod.jsonnet';
{
  data: pod
}
```
Wenn alle Dateien korrekt sind, zeigt "tk show" das aus den Jsonnet-Dateien erzeugte YAML an. "tk diff" zeigt (wie kubectl) die potenziellen Änderungen, wenn das Tanka-Projekt auf einem Kubernetes-Cluster umgesetzt werden soll.

Natürlich ist an dieser Stelle noch nichts gewonnen, denn die Jsonnet-Datei des Pod ist sogar länger als ihr YAML-Gegenstück, aber etwas Refactoring vereinfacht die Jsonnet-Pod-Definition drastisch. Wir werden hier nicht alle Refactoring-Schritte reproduzieren, die das Tanka-Tutorial ausführlich durchgeht. Zum einen geht es dabei darum, aus den Kubernetes-Manifesten Funktionen zu machen, die es erlauben, Parameter zu übergeben; zum anderen vereinfacht die Library k8-libsonnet die Konfiguration. Am Ende steht die in Jsonnet mit wenigen Zeilen formulierte Definition eines kompletten Service (Beispiel aus dem Tanka-Tutorial)
```
local k = import "github.com/grafana/jsonnet-libs/ksonnet-util/kausal.libsonnet";

{
  local deploy = k.apps.v1.deployment,
  local container = k.core.v1.container,
  local port = k.core.v1.containerPort,
  local service = k.core.v1.service,

  new(name, port):: {
    deployment: deploy.new(name, replicas=1, containers=[
      container.new("grafana/grafana")
      + container.withPorts(
          [port.new("ui", 3000)]
        ),
    ]),

    // Helper, um automatisch einen Service für ein Deployment anzulegen
    service: k.util.serv.util.serviceFor(self.deployment)
             + service.mixin.spec.withType("NodePort"),
  }
}
```

## Helm-Support

Manche werden sich vielleicht fragen, was jetzt mit den schönen Helm-Charts passieren soll, die bekanntlich in YAML abgefasst sind. Die gute Nachricht ist: Sie lassen sich mit Tanka weiter nutzen und sogar besser parametrisieren als mit dem Helm-Tool selbst. Dazu ist es nötig, die Jsonnet-Helm-Bibliothek zu installieren. Anschließend können in einer Jsonnet-Datei das Helm-Chart geladen und anschließend die Helm-Values geändert werden, etwa so:
```
  grafana: helm.template("grafana", "./charts/grafana", {
    namespace: "monitoring",
    values: {
      persistence: { enabled: true }
    }
  })
```
Ein Wermutstropfen ist dabei, dass das nur funktioniert, wenn die Helm-Charts im Jsonnet-Projektverzeichnis installiert sind. Hierbei hilft das Tanka-Subcommand "tk tool charts", das die Charts an der passenden Stelle installiert.

Alternativ zu Tanka existieren noch weitere Tools wie Kubecfg, die auf der Jsonnet-Homepage zu finden sind. Daneben gibt es Jsonnet-Bindings für verschiedene Programmiersprachen/Umgebungen, angefangen bei Python, das vom Core-Projekt bereitgestellt wird, über Go, PHP, Ruby, Node.js und Rust als Community-Projekte. 

Wer sich ohne irgendwelche Tools zu installieren mit Jsonnet vertraut machen möchte, findet einen interaktiven Playground mit praktischen Übungen auf der Jsonnet-Seite.

## Fazit

Neben Tanka/Jsonnet gibt es noch weitere Ansätze, das "YAML-Problem" beim Management von Cloud-Konfiguration zu lösen, beispielsweise CUE [3], das aber etwas komplexer ist. Ansätze wie Pulumi gehen noch einen Schritt weiter und erlauben die Erstellung und Konfiguration von Kubernetes-Ressourcen mit verbreiteten Programmiersprachen wie Python, Java oder Go – mit der entsprechenden Freiheit für jeden Entwickler, damit sein eigenes Süppchen zu kochen. Tanka/Jsonnet trifft demgegenüber den Sweet Spot zwischen absoluter Freiheit, die leicht ins Chaos führt, und dem engen YAML-Korsett. 

Einen Styleguide zu Jsonnet [4] bietet die KI-Firma Databricks, die nach eigenen Angaben über 1000 Jsonnet-Templates verwendet. Sie setzt dazu allerdings nicht auf Tanka, sondern auf einen eigenen Jsonnet-Compiler [5], der als Open Source verfügbar ist.

## Links

[1] [Jsonnet](https://jsonnet.org)

[2] [Tanka](https://tanka.dev)

[3] [CUE](https://cuelang.org)

[4] [Jsonnet Style Guide](https://github.com/databricks/jsonnet-style-guide)

[5] [Writing a fast Jsonnet compiler](https://www.databricks.com/blog/2018/10/12/writing-a-faster-jsonnet-compiler.html)


Wie Jsonnet die Konfiguration von Kubernetes-Ressourcen strukturierter und funktionaler macht. 

Kubernetes, Konfiguration, Jsonnet, YAML, Tanka

Kubernetes-Konfiguration mit Jsonnet

Software-Architect

Fullstack Dev

Pull off Architecture Reviews at Light-Speed with LASR!

Architecture reviews don't always need to take a month! 
Timing matters, and with LASR, finding critical insights on software takes as little as 2 to 3 days.

Pull off Architecture Reviews at Light Speed with LASR!

Architektur Rewiew mit LASR in Lichtgeschwindigkeit!

IT Consultant & Developer

Server Side Rendering (SSR) und Static Side Generation (SSG) sind Begriffe, die in der Webentwicklung aktuell immer wieder auftauchen. Aber was bedeuten sie eigentlich und warum werden sie gerade jetzt wieder relevant, obwohl wir sie in Zeiten von Single Page Applications (SPA) nicht brauchen? Zudem fühlt es sich an, als würde eine altbekannte Technik in neuem Gewand durch das Dorf getrieben werden. PHP, ich hör dir trapsen!

## Die Ära der statischen Webseiten (bis ca. 2005\)

Damals™, in den Anfangstagen des Internets, waren Webseiten statische, unveränderliche Dokumente. Das bedeutete, dass jede Seite als HTML-Datei auf einem Server abgelegt, von einem Browser abgerufen, interpretiert und angezeigt wurde. Zu jener Zeit war die semantische Bedeutung der HTML-Tags auch noch dem Gros der Entwickelnden bekannt (Spoiler: semantisches HTML ist und war schon immer relevant\!). Gegen Ende der 90er, mit dem Aufkommen von DHTML (Dynamic HTML: CSS und JavaScript), wurden Webseiten zunehmend dynamischer und grafisch aufwändiger. Diese Ära war geprägt von HTML-Seiten, die oft mit Tabellen als Layout-Elemente und CSS für das Styling erstellt wurden. Die Interaktivität war noch minimal und wurde hauptsächlich durch serverseitige Skripte wie PHP oder Perl realisiert.

## Der Aufstieg von AJAX und dynamischen Webanwendungen (2005-2010)

Ein Wendepunkt war das Jahr 2005, als Google Maps veröffentlicht wurde und die Transition hin zu Web 2.0 manifestierte. Google Maps demonstrierte eindrucksvoll, wie AJAX (Asynchronous JavaScript and XML) genutzt werden konnte, um dynamische Inhalte zu laden, ohne die gesamte Webseite neu aufbauen zu müssen. Das war der Beginn einer neuen Ära in der Webentwicklung, in der Benutzererfahrung und Interaktivität im Vordergrund standen. In den folgenden Jahren wurde AJAX immer populärer und ermöglichte die Entwicklung von dynamischen Webanwendungen. Frameworks wie jQuery erleichterten die Arbeit mit AJAX erheblich und trugen zur Verbreitung dieser Technik bei. Erst mit dem Aufkommen von Single-Page-Frameworks verlor u.a. jQuery an Bedeutung und eine professionalisierte Entwicklung von Webanwendungen nahm Fahrt auf.

## Die Ära der Single-Page-Applications (SPAs) (ab 2010\)

Der Aufstieg von SPAs begann etwa ab dem Jahr 2010\. Mit dem Aufkommen leistungsfähiger JavaScript-Frameworks wie AngularJS (2010), React (2013) und Vue.js (2014) wurde es möglich, komplexe Anwendungen zu entwickeln. Spätestens jetzt wurde deutlich, dass der Web 2.0 Ansatz, das Internet als Plattform zu betrachten, eingeschlagen war.  
SPAs laden einmal die Grundstruktur der Anwendung und aktualisieren dann dynamisch den Inhalt (genauer: das DOM) über AJAX-Anfragen. Das führte zu einer deutlich geänderten Benutzererfahrung, da Seitenwechsel schneller, flüssiger und vor allem ohne sichtbarem Neuaufbau realisiert wurden. In den letzten 15 Jahren hat sich die SPA-Entwicklung naturgemäß erheblich weiterentwickelt, und moderne Frameworks bieten neuere und ausgefeiltere Funktionen wie serverseitiges Rendering (SSR) und statische Seitengenerierung (SSG), um die Leistung und SEO weiter bzw. wieder zu verbessern. Doch warum geht man nun einen Schritt zurück? SPAs laufen ausschließlich auf dem Client (im Browser) und entlasten somit Server, warum also dieser Turn-Around? Mit SPA war doch alles schön und gut oder etwa nicht?

## Was ist SSR und SSG?

Beim Server Side Rendering (SSR) wird der Inhalt einer Webseite nicht im Browser des Benutzers, sondern bereits auf dem Server generiert. Der Browser erhält dann eine fertig (vor-)gerenderte HTML-Seite. Das war früher die gängige Methode, bevor JavaScript-basierte Single-Page-Applications (SPAs) populär wurden und wird auch heute noch von vielen CM-Systemen wie Wordpress oder Typo3 implementiert.

Sowohl SSR als auch SSG generieren Inhalte statisch vor und reduzieren somit die initiale Ladezeit, da hier klassische Caching-Machanismen auf dem Server greifen können. Der wesentliche Unterschied zwischen SSR und SSG liegt im Zeitpunkt der Generierung: Bei SSR wird die HTML-Seite bei jeder Anfrage dynamisch auf dem Server generiert. Das bedeutet, dass der Server jedes Mal, wenn ein Benutzer eine Seite anfordert, die Daten abruft und das HTML-Dokument neu zusammenstellt. SSG hingegen generiert die HTML-Seiten während des Build-Prozesses, also einmalig. Die statischen HTML-Dateien werden dann auf einem Server gespeichert und bei jeder Anfrage unverändert ausgeliefert. SSG eignet sich besonders gut für Webseiten mit Inhalten, die sich selten ändern (Blogs, Wiki, Zeitungsartikel,…). SSR hingegen ist ideal für dynamische Inhalte mit hoher Benutzerinteraktion und vom Nutzenden erstellen Inhalten bzw. Inhalten, die sich im zeitlichen Verlauf sekündlich ändern können. Nimmt man es genau, sind PHP-basierte Webseiten dem SSR zuzuordnen, da hier bei jedem Aufruf das PHP-Skript erneut ausgeführt wird und die Daten an den Client schickt.

## Die Renaissance von SSR

Dass SSR ein wiederaufgelebtes Thema in der Webentwicklung ist, lässt sich auf mehrere Schlüsselfaktoren zurückführen: Unter anderem ist die Performance von SSR-basierten Anwendungen besser gegenüber den Applikationen, die mit SPA-Frameworks erstellt werden. Moderne SSR-Frameworks nutzen etablierte Caching-Strategien und Edge-Computing, um schnelle Ladezeiten zu gewährleisten. Das bedeutet, dass Benutzer Webseiteninhalte schneller sehen (First Contentful Paint (FCP)) und interagieren können. Außerdem ist SSR ideal für Suchmaschinenoptimierung (SEO), da der Inhalt direkt als HTML ausgeliefert wird. Suchmaschinen-Crawler können den Inhalt leicht lesen und indexieren, was zu einer besseren Sichtbarkeit und einem höheren Ranking in den Suchergebnissen führen kann. Schließlich trägt die schnellere Ladezeit von SSR-Anwendungen auch zu einer besseren Benutzererfahrung bei. Benutzer schätzen schnelle Webseiten, was zu geringeren Absprungraten und einer höheren Benutzerzufriedenheit führt und bei Shopsystemen nicht selten zu mehr Abschlüssen.

Doch was macht SSR aktuell so besonders, wenn bspw. PHP dies seit jeher “von Haus aus” macht? Ein wesentlicher Aspekt ist, dass kein Framework- oder Technologie-Bruch stattfinden muss: Verwendet man Next.js, Nuxt.js oder Angular in einer aktuellen Version, kann mit den vom jeweiligen Framework angebotenen Feature-Set für beide Seiten, Client- und Server, entwickelt werden. Überspitzt gesagt reicht es aus, Grundlagen der Webentwicklung, Typescript und eins der großen Frameworks zu kennen statt zusätzlich noch die weiteren rein Server-seitigen Sprachen wie PHP oder ASP.NET. Zudem ist durch den Einsatz der Ursprünglich für den SPA-Fokus entwickelten Frameworks ein hybrider Betrieb möglich: Die Webapplikation wird zunächst ohne weitere Notwendigkeit für JavaScript an den Browser ausgespielt und anschließend über “hydration” mit Hilfe von JavaScript-Funktionen um Interaktive Elemente angereichert.

## Fazit

Auch wenn es den Anschein hat, ist SSR kein alter Trend im neuen Gewand, sondern ein topaktuelles Thema mit wesentlichen Weiterentwicklungen. Wer eine performante, SEO-freundliche und benutzerfreundliche Website entwickeln möchte, sollte sich mit SSR auseinandersetzen und über bekannte Muster aus PHP oder .NET-Zeiten hinaus blicken. Seit der Einführung dieser Technologien hat sich die Internetarchitektur maßgeblich weiterentwickelt und die neuen Webframeworks machen sich dies zu Nutzen und ermöglichen es, die Konzepte wie CDNs, Caching, Edge-Computing einfacher und für den Entwickelnden transparenter zu nutzen.

SSR erlebt ein Comeback? Wir beleuchten die Entwicklung von Server Side Rendering, seine Vorteile und wie moderne Frameworks es neu definieren.

SSR: Alter Trend im neuen Gewand?

Server Side Rendering - Ein alter Trend im neuen Gewand?

Im Rahmen eines Red-Team-Assessments bestand die Herausforderung darin, eigenen Code über eine DLL auszuführen. Der Grund für dieses Szenario lag im Einsatz einer „Application Allow Listing“-Software, die die Ausführung unbekannter Executables blockiert. Dabei wurden die üblichen Möglichkeiten zum Laden von DLLs, wie z.B. rundll32, vom Blue Team des Kunden stark überwacht, sodass wir uns nach anderen Optionen umsehen mussten.\nNach einigem Ausprobieren in unseren Labs und der Analyse des Verhaltens bestimmter Windows-Programme zur Laufzeit, stellte sich heraus, dass in einem aktuellen Windows 11 (Stand März 2025) einige Microsoft-eigene Programme eine Schwachstelle aufwiesen –  nämlich Relative Path DLL Hijacking.\nMithilfe eines kleinen Twists ermöglicht diese Schwachstelle es Angreifern, über vertrauenswürdige Anwendungen (Schad-)Code auszuführen und möglicherweise weitere Sicherheitsmechanismen wie Application Allow Listing oder gezieltes Monitoring zu umgehen.\nDieses Problem wurde am 21.02.2025 an Microsoft gemeldet und am 07.03.2025 als „keine Schwachstelle“ klassifiziert. Gerne zeigen wir euch dennoch in diesem Blogpost, wie ihr als Red Teamer Microsoft-Programme für das Nachladen von DLLs verwenden könnt.\nWas ist eigentlich Relative Path DLL Hijacking?\nRelative Path DLL Hijacking ist eine Schwachstelle, die auftritt, wenn eine Anwendung eine erforderliche DLL nicht über einen festen Pfad lädt, sondern die übliche Suchreihenfolge von Windows verwendet (siehe untenstehende Grafik). Bei dieser Reihenfolge kann ein Angreifer eine DLL mit dem gesuchten Namen in einem manipulierten, und für ihn beschreibbaren Verzeichnis platzieren. Wird die Anwendung gestartet, lädt sie die DLL und führt den darin enthaltenen Code mit den Rechten des betroffenen Programms aus. \nDie nachfolgende Grafik veranschaulicht die Suchreihenfolge für DLLs unter Windows. Dabei fällt auf, dass einige Suchpfade nicht nur von Administratoren, sondern auch von normalen Benutzern manipuliert werden können.\n\n\nBetroffene Windows-Komponenten\nEinige Komponenten aus dem System-Verzeichnis \nC:\Windows\System32\n sind für den beschriebenen Angriff anfällig, sofern ein kleiner Trick angewendet wird. Der Schlüssel dazu liegt in der DLL-Suchreihenfolge, speziell im Punkt „Pfad der Applikation“.  Dafür wird eine betroffene Komponente (z. B. calc.exe) aus dem System32-Ordner in einen anderen, für den Angreifer beschreibbaren Ordner kopiert:\ncopy C:\Windows\System32\calc.exe C:\Users\Public\\nMit dem Tool Process Monitor kann nun der Start des Prozesses im Detail analysiert werden. Die Filterung der Ereignisse hilft dabei, nur die wichtigen Informationen ausgeben zu lassen:\nPfade, die mit .dll enden, sollen in der Anzeige inkludiert werden\nErgebnisse von Ereignissen, bei denen eine Datei nicht gefunden wird, soll in der Anzeige inkludiert werden\nAlle Prozesse, die nicht calc.exe sind, sollen aus der Anzeige entfernt werden\n\n\nWie zu sehen ist, versucht die Anwendung calc.exe vergeblich, verschiedene DLLs aus dem Ordner zu laden, in dem sie ausgeführt
wurde.\n\n\nEin Angreifer könnte demnach eine DLL mit dem Namen Windows.Storage.dll erzeugen und im selben Verzeichnis ablegen, in dem calc.exe ausgeführt wird. Beim Start von calc.exe würde die manipulierte DLL geladen und der darin enthaltene Code ausgeführt. \nDer folgende Beispielcode öffnet beim Laden der DLL eine sog. Message Box mit dem Inhalt „Hijacked DLL …“:\n\n\nWird calc.exe nun gestartet und findet die DLL im selben Ordner, wird diese geladen und die Message Box geöffnet:\n\n\n\nWarum ist das Verhalten trotzdem ein Problem?\nIn diesem speziellen Fall müssen die betroffenen Programme zusammen mit der jeweils manipulierten DLL-Datei in einen Ordner platziert und ausgeführt werden. Das bedeutet, dass der Angreifer eine initiale Kontrolle über das System erlangt haben muss, oder eines der legitimen Programme zusammen mit seiner DLL über andere Wege verteilt. Für den Angreifer ist es von Vorteil, dass die betroffenen Applikationen durch Microsoft digital signiert sind und somit als vertrauenswürdig eingestuft werden. Das kann dazu führen, dass weitere Sicherheitsmechanismen umgangen werden. Einige Lösungen, wie Antivirus-Programme, EDR- und Allow-Listing-Tools, analysieren unter Umständen zunächst nur den ladenden Prozess. \nSomit bietet diese Schwachstelle Angreifern eine Alternative zu den sogenannten LOLBAS (Living Off The Land Binaries and Scripts). Hierbei handelt es sich um systemeigene Windows-Programme und Skripte, die von Angreifern in der Regel für versteckte Aktionen missbraucht werden. Da LOLBAS in der Regel intensiv durch Sicherheitslösungen überwacht werden und ein höheres Entdeckungsrisiko aufweisen, eröffnet das Relative Path DLL Hijacking in Windows-Programmen zusätzliche Möglichkeiten für Angreifer.\nZeitleiste der Responsible Disclosure\nDatum\nAktion\n20.02.2025\nEntdeckung der Schwachstelle in mehreren Programmen\n21.02.2025\nMeldung an Microsoft\n25.02.2025\nErstellung einer Case-Nummer durch Microsoft und interne Analyse\n07.03.2025\nKlassifikation als keine Schwachstelle\n12.03.2025\nBlog-Freigabe durch Microsoft\nWeiterführende Links\n\nhttps://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order\n\n\nhttps://learn.microsoft.com/en-us/sysinternals/downloads/procmon\n\n\nhttps://lolbas-project.github.io/\n\n


Relative Path DLL Hijacking: Als Red Teamer legitime Windows-Programme missbrauchen, um eigenen Code nachzuladen.

Relative Path DLL Hijacking in Windows-Programmen

Übersicht und Erklärung von Angular Signals an einfachen Beispielen sowie an einem konkreten Projekt.

angular-signals

Angular Signals

Der Frühling zeigt uns, wie Neuanfang geht, und der Patch Tuesday zeigt uns, wie das Beheben von Schwachstellen funktioniert.

**Was ist der Patch Tuesday?**

Der Begriff bezeichnet den zweiten Dienstag im Monat, an dem Microsoft wichtige Patches für seine Systeme veröffentlicht. Durch den festen Rhythmus wird die Arbeit von Systemadministratoren und Nutzern erleichtert, da somit ein klarer Planungszeitpunkt zum Einspielen von Updates gegeben ist.

Der Patch Tuesday bringt im März 2025 unter anderem wichtige Sicherheitsupdates von Microsoft und schließt damit mehrere Sicherheitslücken.

Im März bekommen wir es mit einigen RCEs (Remote Code Executions) zu tun. Hervorzuheben sind die zwei Schwachstellen [CVE-2025-24035](https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-24035) und [CVE-2025-24045](https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-24045). Beide Schwachstellen betreffen die Windows Remote Desktop Services. Mittels der Manipulation einer unbekannten Eingabe kann Remote Code ausgeführt werden. Für beide Schwachstellen gibt es aktuell aber noch keinen veröffentlichten PoC.

Patches wurden für Windows 10 und Windows 11 herausgebracht sowie für die gängigen Server-Typen, siehe [hier](https://msrc.microsoft.com/update-guide/releaseNote/2025-Mar).

SAP hat diesen Monat ebenfalls keine kritischen Schwachstellen veröffentlicht. Mehr Informationen über die veröffentlichten Schwachstellen sind [hier](https://support.sap.com/en/my-support/knowledge-base/security-notes-news/march-2025.html) zu finden.

Weitere Hersteller, die Sicherheitsupdates herausgebracht haben, sind nachfolgend aufgelistet:

[Cisco](https://sec.cloudapps.cisco.com/security/center/publicationListing.x): Sicherheitsupdates für mehrere Produkte, darunter eine Anleitung zum Deaktivieren des Remote Management als eine Art Workaround für eine kritische Schwachstelle im web-based Management Interface für RVxxx Router.

[Ivanti](https://www.ivanti.com/blog/march-security-update): Sicherheitsupdates für Secure Access Clients sowie Neurons für MDM.

[Fortinet](https://www.fortiguard.com/psirt?page=1&date=&severity=&product=FortiAP-W2,FortiAP-C,FortiSandbox,FortiManager,FortiAP-S,FortiOS,FortiAnalyzer-BigData,FortiAnalyzer,FortiAnalyzer%20Cloud,FortiExtender,FortiOS-6K7K,FortiSwitchManager,FortiManager%20Cloud,FortiAP,FortiSwitch,FortiAP-U&component=&version=): Sicherheitsupdates für mehrere Produkte.

[Zyxel](https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-post-authentication-command-injection-vulnerabilities-in-certain-dsl-ethernet-cpe-fiber-ont-and-wifi-extender-devices-03-11-2025): Sicherheitsupdates, um eine Schwachstelle für eine Command Injection zu beheben.

[Broadcom](https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/25390): Sicherheitsupdates, um kritische Schwachstellen in VMware ESX Produkten zu beheben. Angreifer mit privilegierten Administrator- bzw. Root-Rechten auf den Produkten können durch eine Verkettung der Schwachstellen aus der Sandbox ausbrechen.

Kurze Zusammenfassung der Sicherheitsupdates aus dem Patch Tuesday März 2025

Patch Tuesday März 2025

# Spring Boot Admin - Wrap Up
Nach über 10 Jahren seiner Existenz möchten wir in diesem Blogpost die Geschichte des Spring Boot Admin beleuchten und Hintergründe über die aktuelle Entwicklung geben. Wie hat alles angefangen? Was war die Motivation? Wo kommt das Werkzeug her? Wie sieht die Entwicklung aus? Was ist der aktuelle Stand? Und: Warum tun wir das Ganze überhaupt?
## Wo kommen wir her?
Wie im Blog-Artikel "Spring Boot Admin"[^1] zu lesen, hat im Jahre 2014 die Geschichte des Spring Boot Admin angefangen. Im Zuge eines Kundenprojekts entstand die Notwendigkeit, die neu entwickelten Micro Services, basierend auf Spring Boot, zu administrieren und teilweise zu überwachen. Die damals implementierten Funktionen sind bis heute relevant, beispielsweise die Möglichkeit, das Log-Level von Anwendungen zu ändern, welche weiterhin ein integraler Bestandteil des Tools ist. Die anfängliche Übersicht aller installierten Anwendungen mit Versionsnummern, Status, JVM-Details, Log-Dateien und Log-Leveln[^1][^2] hat sich mittlerweile zu einer nahezu vollständigen Unterstützung der von Spring Boot angebotenen Actuator-Endpunkte weiterentwickelt. Mit Ende des Jahres 2014 und dem Release der Version 1.1.0[^3], welches Spring Boot 1.2.0 unterstützte (lang, lang ist's her), wurde das Jahr der Grundsteinlegung beschlossen.
## Der Aufstieg
In den folgenden Jahren verzeichnete das Projekt einen starken Gewinn an Popularität, was sich in der steigenden Anzahl von Stars und Forks auf GitHub widerspiegelte. Insbesondere die kontinuierliche Weiterentwicklung durch regelmäßige Releases, sowie die Einführung neuer Funktionen und Verbesserungen haben zu dieser Popularität beigetragen. Heute findet das Tool weltweit Anwendung, beispielsweise bei der Post in Brasilien, Banken in Norwegen, Fluggesellschaften in der Türkei, diversen Unternehmen in Deutschland und vielen anderen. 
Durch die Zusammenarbeit von Josh Long und Johannes Edmeier vor Ort im Hauptquartier der codecentric AG in Solingen, ist das Tool seit 2018 im Spring Initializer ([start.spring.io](https://start.spring.io/#!dependencies=codecentric-spring-boot-admin-server)) gelistet, wodurch es nicht selten schon während des Setups eines Spring Boot-Projekts berücksichtigt wird.

Im März 2018 und dem Release von Spring Boot 2 wurde die Architektur des Spring Boot Admin neu gedacht und das Frontend auf eine moderne Plattform mit Vue.js gehoben. Wir haben veraltete Features im Backend ersetzt oder entfernt, neue Features integriert und die Benutzeroberfläche modernisiert. Bis zu diesem Zeitpunkt verzeichnete das Repository bereits knapp 5700 Stars mit über 200 gemeldeten Issues, an denen wir regelmäßig arbeiteten. Durch die Nutzung des Spring Cloud DiscoveryClient wurde die Flexibilität des Spring Boot Admin zusätzlich erhöht. Dieser ermöglicht die Integration unterschiedlicher Plattformen (wie bspw. Kubernetes, Eureka, Zookeeper und weitere), wodurch das Tool noch vielseitiger und anpassungsfähiger für verschiedene Systemlandschaften wird.
## Die Fortentwicklung
Am Ende des Jahres 2020 stellte sich das Team rund um Spring Boot Admin neu auf, da die Kolleginnen und Kollegen, die bis dato das Werkzeug entwickelt hatten, das Unternehmen verlassen haben und eine Weiterentwicklung sonst nicht gewährleistet werden konnte. Durch die Restrukturierung ist es uns gelungen, auch nach 2020 weiterhin regelmäßig Updates mit neuen Features liefern zu können und sogar die Produktivität bezüglich der Abarbeitung von Issues zu steigern. Dies zeigt sich durch einen Anstieg der Stars, nachdem diese Kurve vorher stark abgeflacht war. Unsere Bemühungen trugen auch dahingehend Früchte, dass Microsoft mit seinem Cloud Dienst Azure Spring Boot Admin als Werkzeug in sein Repertoire aufgenommen hat[^4].

Zwischenzeitlich, nämlich am 24. November 2022, wurde Spring Boot in Version 3 veröffentlicht. Bereits frühzeitig haben wir als Team mit Vorab-Versionen des Frameworks, an der Kompatibilität des Werkzeugs gearbeitet und konnten am Anfang des kommenden Jahres eine kompatible Version freigeben. Wie auch bei der Veröffentlichung von Spring Boot Admin 2 haben wir nicht nur im Backend notwendige Updates und Anpassungen vorgenommen, sondern auch wieder der UI ein neues Aussehen verpasst und verwendete Upgrades von Frameworks umgesetzt.
## Motivation
Als Idee zur Überwachung und Steuerung von Spring Boot Applikation gestartet, ist Spring Boot Admin mittlerweile ein herausstechendes Open Source-Projekt bei der codecentric AG geworden. Bei vielen unserer Kunden setzen wir Spring Boot als Framework ein und haben uns somit selbst die Möglichkeit geschaffen, die von uns implementierten Services zu überwachen. Aus dem anfänglichen Gedanken der 'Hilfe zur Selbsthilfe' entstand der Idealismus, der Community etwas zurückzugeben. Durch unsere langjährige Erfahrung in der Entwicklung mit Spring Boot in diversen Kontexten, können wir dieses Werkzeug selbstbewusst frei zur Verfügung stellen. Natürlich steht diesem Idealismus auch ein praktischer Nutzen gegenüber: Wir beschäftigen uns frühzeitig mit neuen Spring Boot-Versionen und können so Migrationspfade, Hindernisse, Herausforderungen und Best Practices identifizieren, die wir später an unsere Kunden weitergeben können.
## Wie geht es weiter?
Die Adoptionsrate des Tools und die Möglichkeit, stets am Zahn der Zeit zu bleiben, motivieren uns, dieses Tool weiterzuentwickeln. Aktuell sind wir weiterhin bemüht, ein stabiles Werkzeug anzubieten und gleichzeitig mit neueren Versionen von Spring Boot weitere Funktionen einzubauen. Auch wenn es noch kein Releasedatum oder gar eine Ankündigung von Spring Boot 4 gibt, werden wir wie gewohnt in regelmäßigen Abständen Releases des Tools zur Verfügung stellen und die aktuellen Spring Boot Versionen unterstützen.
## Ein Dankeschön!
An dieser Stelle möchten wir uns bei Thomas Bosch, Dennis Schulte und Johannes Edmeier bedanken, die die initiale Idee für dieses Werkzeug hatten und es als Open Source-Projekt innerhalb der codecentric AG etabliert haben. Natürlich geht das Dankeschön auch an die Community, also an euch, die dieses Werkzeug aktiv benutzen, denn ohne euch gäbe es keine Grundlage für die Fortentwicklung des Tools.
Wir, das sind Erik Petzold, Ulrich Schulte, Andreas Fritz, Timo Kockert und Stephan Köninger, freuen uns darauf, euch weiterhin mit Releases versorgen zu dürfen und die Open Source-Welt mitgestalten zu können. 

[^1]: [Spring Boot Admin](https://www.codecentric.de/wissens-hub/blog/spring-boot-admin-2)  

[^2]: [Spring Boot Admin - First official release1](https://www.codecentric.de/wissens-hub/blog/spring-boot-admin-first-official-release)

[^3]: [Spring Boot Admin 1.1.0 - New Release is out](https://www.codecentric.de/wissens-hub/blog/spring-boot-admin-1-1-0-new-release-amazing-new-features)

[^4]: [Azure und Spring Boot Admin](https://learn.microsoft.com/de-de/azure/container-apps/java-admin?tabs=azure-cli)


Dieser Post beleuchtet die Geschichte und Entwicklung vom Tool "Spring Boot Admin" und gibt Einblicke in die Motivation und Zukunftspläne des Projektteams.

Spring Boot Admin - 10 Jahre später: Eine Erfolgsgeschichte

Spring Boot Admin - 10 Jahre Wrap Up

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

CODECENTRIC BLOG

Angular 17 – Eine echte Renaissance?

Für mehr Nachhaltigkeit – CO2 sparen mit Rust

Produktstrategie als Erfolgsgrundlage: Warum du nicht mit deiner Vision starten solltest

Wie als Software-Entwickler sichtbar werden?

How to gain visibility as a software developer?

Charge your APIs Volume 26: Choosing the Right API Development Strategy: A Guide to API Design First vs. Code First Approaches

Agilität

Big Data

CI/CD

Cloud

Container

DevOps

Digitalisierung

Generative KI

IT-Security

Künstliche Intelligenz

Kubernetes

Microservices

Produktmanagement

Bei codecentric leben wir eine offene Kultur und teilen gerne unser Wissen. Tauche weiter in unsere Welt ein.

WISSENS-HUB

Der Softwerker Spezial Generative KI

Drei Personen sitzen am Tisch in einem Meetingraum mit Laptop und besprechen sich.

Leistungen

codecentric AG in den TOP 20 der Lünendonk-Liste

Lünendonk-Studie: codecentric unter den TOP20

JOBANGEBOT

JavaScript

Java

Spring

React

Python

Scala

Kotlin

GitHub

GitLab

Azure

Google Cloud

Remote Work

Senior Agile Consultant und Developer (w/d/m) 

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

Community

Softwareentwicklung

Kultur

SoftwerkerCast

Events – codecentric mittendrin

CODECENTRIC ENTDECKEN

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Produktentwicklung

Weitere Leistungen...

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Im codecentric Blog gibt es Expertenwissen zu aktuellen IT-Themen: Agile Methoden, Softwarearchitektur, KI, Testing und vieles mehr. ► Jetzt entdecken!

Blog: IT-Wissen von Entwickler*innen für Entwickler*innen

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

codecentric Blog

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen

Themenfilter

CODECENTRIC ENTDECKEN

Der Softwerker Spezial Generative KI

Senior Agile Consultant und Developer (w/d/m)

Leistungen

SoftwerkerCast

codecentric AG in den TOP 20 der Lünendonk-Liste

Events – codecentric mittendrin

Jetzt für unseren Newsletter anmelden

codecentric Blog

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

Themenfilter

Bitte Themen anklicken

CODECENTRIC ENTDECKEN

Der Softwerker Spezial Generative KI

Senior Agile Consultant und Developer (w/d/m)

Leistungen

SoftwerkerCast

codecentric AG in den TOP 20 der Lünendonk-Liste

Events – codecentric mittendrin

Jetzt für unseren Newsletter anmelden

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen