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?

Wissens-Hub | codecentric AG

codecentric Blog

Vibe coding – Was nun?

IT Security Consultant

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?

Principal IT Security Consultant

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

AI Consultant & Engineer

Hype oder Zukunftstechnologie? Das ist eine Frage, die sich aktuell sehr viele in Bezug auf KI-Agenten stellen. Unsere Antwort darauf ist: KI-Agenten sind mehr als nur Hype. Sie geben uns in ihrem aktuellen Zustand einen Ausblick auf die Arbeitsweise der Zukunft. \nDieser Grundlagen-Artikel richtet sich an alle, die gerne mehr darüber erfahren möchten, was intelligente Agentensysteme sind und wie sie funktionieren. Wir beleuchten ihre technische Architektur, wichtige Frameworks und Use-Cases in verschiedenen Branchen. Zudem geben wir einige Tools an die Hand, mit denen jeder ein eigenes Agentensystem erstellen kann. In den kommenden Wochen werden wir außerdem weitere Artikel zu dem Thema veröffentlichen, in denen wir anhand konkreter Beispiele und Tools zeigen, wie ein eigenes kleines Agentensystem gebaut werden kann.\n\n\nEin Agentensystem auf dem Smartphone (Apple Intelligence). Foto von appshunter.io\n⁠Was sind KI-Agentensysteme?\nKI-Agenten sind autonome Softwareprogramme, die Aufgaben für Nutzer oder andere Systeme erledigen. Sie sammeln und verarbeiten Daten über verschiedene Eingaben, treffen Entscheidungen und führen Aktionen aus, um spezifische Ziele ohne menschliches Eingreifen zu erreichen. Klingt das bekannt? Das liegt daran, dass uns solche Agentensysteme bereits seit Jahrzehnten begleiten. Von simplen Entscheidungsalgorithmen, über klassische, regelbasierte Chatbots bis hin zu altbekannten NPCs in Videospielen: Das alles bezeichnen wir seit langem bereits als KI-Agenten. Doch die rasante Entwicklung von generativer KI in den letzten Jahren hat auch den Begriff der Agenten grundlegend verändert. Wenn wir heute über KI-Agenten sprechen, dann meinen wir meistens Systeme, die komplexe Aufgaben autonom lösen können und deutlich mehr können als die Agenten der Vergangenheit. Die zentrale Rolle eines KI-Agenten spielt dabei die Entscheidungslogik. Sie ist das Herzstück des Systems und bestimmt, welche Entscheidungen der Agent trifft. Setzen wir hierfür große Sprachmodelle (Large Language Models, kurz \nLLMs\n) ein, so erhalten wir die modernen KI-Agenten von heute die wir uns jetzt genauer anschauen.\n
⁠Wie sind KI-Agenten aufgebaut?\nDer Aufbau eines KI-Agenten lässt sich am besten mit dem menschlichen Entscheidungsprozess vergleichen. Stellen Sie sich vor, wie wir Menschen Informationen aufnehmen, verarbeiten und darauf reagieren. Genauso funktioniert auch ein KI-Agent, nur dass er digital arbeitet.\nDie grundlegende Architektur eines KI-Agenten besteht in der Regel aus mehreren Kernkomponenten:\nWahrnehmung\n: Dies ist gewissermaßen das "Sinnesorgan" des Agenten. Hier werden alle Eingangsdaten aufgenommen - das können Texte, Bilder, Sensordaten oder andere Informationen sein. Denken Sie an die Kamera eines selbstfahrenden Autos, das Mikrofon eines Sprachassistenten, oder ganz einfach das Interface des Chatbots. Auch der Output eines anderen Agenten kann an so einer Stelle genutzt und aufgenommen werden.\nVerarbeitung / Entscheidungen\n: Dies ist das "Gehirn" des Agenten. Im Zentrum der modernen KI-Agenten steht hier das LLM, das als eine Art Entscheider agiert. Es kann komplexe Zusammenhänge verstehen, logische Schlüsse ziehen und kreative Lösungen entwickeln. Zusätzlich verfügen moderne Agenten über ein "Arbeitsgedächtnis", das wichtige Informationen aus früheren Interaktionen speichert und in aktuelle Entscheidungen einbezieht. Basierend auf der Analyse der Daten, der Aufgabenstellung und dem vorhandenen Wissen im Kontext trifft der Agent hier Entscheidungen darüber, ob und welche Aktionen ausgeführt werden sollen. Der Agent kann verschiedene Handlungsoptionen durchspielen, indem er sie in natürlicher Sprache "durchdenkt". Dies ermöglicht es ihm, komplexe Strategien zu entwickeln und die Konsequenzen seiner Handlungen vorherzusehen. Moderne Agenten können sogar mehrschrittige Pläne erstellen und diese dynamisch anpassen.\nAktionen\n: LLM-basierten Agenten können nicht nur kommunizieren, sondern auch aktiv Werkzeuge nutzen - zum Beispiel Internetsuchen durchführen, Dokumente erstellen, Kundenakten und Verträge einsehen, APIs nutzen, oder Code schreiben und ausführen. Das LLM entscheidet dabei, welche Werkzeuge zum Lösen der Aufgabe genutzt werden sollen und interpretiert die Ergebnisse ihres Einsatzes.\nGedächtnis\n: Viele moderne KI-Agenten können aus ihren Aktionen lernen und ihr Verhalten entsprechend anpassen. Sie sammeln Informationen darüber, wie erfolgreich ihre Aktionen waren, und nutzen diese, um ihre zukünftigen Entscheidungen zu verbessern.\n\n\nArchitektur eines sehr einfachen KI-Agentensystem mit angebundenen Tools und Speicherfunktion für Informationen über den Nutzer\nEin Beispiel für die Anwendung von KI-Agenten ist die Nutzung in Webbrowsern. Hier können sie autonom Informationen suchen, Daten extrahieren oder sogar Transaktionen durchführen, um dem Nutzer bestimmte Aufgaben abzunehmen.\n
⁠Reasoning-Frameworks\nEs gibt verschiedene Arbeitsweisen, die beschreiben, wie ein Agent seine Ziele erreicht. Dabei bieten sie jeweils verschiedene Vor- und Nachteile. Nachfolgend werden zwei der bekanntesten Frameworks erklärt.

\nReAct (Reasoning and Acting)

\nDas bekannteste Framework, bei dem der Agent nach jeder Aktion und jeder erhaltenen Information reflektiert und plant, um zu entscheiden, welche Handlung als nächstes durchgeführt werden soll. Der Agent iteriert dabei durch drei Phasen, bis entweder das Ziel oder eine Abbruchbedingung (z.B. unlösbar) erreicht ist:\nThought\n (Denken): Der Agent überlegt, was er als nächstes tun sollte
⁠\nAction\n (Handlung): Er führt eine konkrete Aktion aus, zum Beispiel eine Internetsuche
⁠\nObservation\n (Beobachtung): Er wertet das Ergebnis seiner Aktion aus\nDieses iterative Vorgehen ermöglicht es dem Agenten, Probleme Schritt für Schritt zu lösen und seine Antworten kontinuierlich zu verbessern. Dies ist vor allem bei komplexeren Aufgaben sinnvoll, wo die Zwischenergebnisse nicht immer vorhersehbar, aber oft entscheidend für den weiteren Verlauf der Aufgabenlösung sind.\nPlan-and-Solve\nBei Planungsbasierten Frameworks erstellt der Agent zuerst einen detaillierten Plan, bevor er handelt. Dabei zerlegt das Hauptproblem in Teilprobleme, plant die Reihenfolge der Lösungsschritte, führt den Plan Schritt für Schritt aus, und beobachtet dann (oder zwischendurch) das Ergebnis. Durch das detaillierte Planen können diese Agenten potenzielle Herausforderungen eher vorhersehen und Ressourcen effizienter zuweisen.\nEin weiteres konkretes Beispiel für ein Planungsbasiertes Framework ist ReWOO (Reasoning Without Observation). Bei dem Framework antizipiert der Agent die notwendigen Schritte zur Zielerreichung und führt sie aus, ohne während des Prozesses zusätzliche Beobachtungen zu machen. Dadurch ist die Ausführung sehr schnell, ist aber aufgrund der fehlenden Auswertung als Zwischenschritte eher für den Einsatz bei leicht verständlichen und konkreten Aufgaben geeignet. \nDie Wahl des geeigneten Frameworks hängt also immer von der spezifischen Anwendung und den Anforderungen des jeweiligen Systems ab.\n
⁠Multiagentensysteme\nMit der steigenden Komplexität der Aufgaben, die so ein Agentensystem bewältigen soll, kommt oft auch die Notwendigkeit, solche Systeme performanter und effizienter zu gestalten. Da kommen Multiagentensysteme ins Spiel. Sie arbeiten mehrere Agenten zusammen, um komplexe Aufgaben zu bewältigen. Sie können miteinander kommunizieren und ihre Aktionen koordinieren. Der Vorteil der Nutzung solcher Multiagentensysteme besteht darin, dass verschiedene Modelle, Parameter und System Prompts je nach Aufgabe des Agenten eingesetzt werden können. Während einfache Anfragen beispielsweise effizient von kleineren LLMs bearbeitet werden, können rechenintensive Aufgaben, wie die detaillierte Analyse wissenschaftlicher Arbeiten oder komplexe logische Schlussfolgerungen, an leistungsstärkere Reasoning-Modelle oder andere spezialisierte KI-Agenten delegiert werden. Dies sorgt für eine effiziente Ressourcennutzung und eine optimierte Aufgabenverteilung. Zusätzlich können sich Agenten in einem solchen System gegenseitig mit Wissen versorgen. Beispielsweise kann ein spezialisierter Agent, der Daten extrahiert, seine Ergebnisse an einen anderen Agenten weitergeben, der darauf basierend weiterführende Berechnungen oder Schlussfolgerungen zieht. Ein gut gestaltetes Multiagentensystem ermöglicht eine adaptive und skalierbare Lösung für viele KI-Anwendungen.\n\n\nArchitekturdiagramm eines Komplexeren KI-Agentensystems mit einem Koordinator-Agent für die Interaktion mit dem Nutzer und der Planung der Schritte, und mehreren spezialisierten Subagenten zum ausführen von dedizierten Aufgaben. Der Übersichtshalber sind die Antworten der Subagenten an den Koordinator-Agenten nicht auf dem Diagram verzeichnet.\nBeispielhafte Anfrage eines Nutzern\nUser-Input\n 
Erstelle mir einen Blogartikel über mein Produkt. Poste ihn bitte auf LinkedIn. Anschließend möchte ich, dass eine Slack-Nachricht an meine Mitarbeitenden gesendet wird, die darüber informiert, dass ein neuer Blogartikel erstellt wurde.\nWir nutzen an dieser Stelle Plan-and-Solve, da hier ein Koordinator-Agent die Planung aller notwendigen Schritte am Anfang durchführt. Folgende Schritte würden nun basierend auf der Architektur aus dem vorangegangenen Diagram passieren: \n1. Analyse der Anfrage durch den Koordinator-Agenten und Aufbau einer Aufgabenplanung für die Sub-Agents\n2. Sucht nach dem Namen und Informationen zu dem Produkt des Nutzers im Speicher, und gibt diese an den Koordinator-Agenten zurück.\n3. Koordinator-Agent gibt dem RAG-Agenten die Aufgabe, relevanten Informationen zu dem Produkt aus der Vektordatenbank zu holen. Der spezialisierte RAG-Agent weiß anhand der ihm vorliegenden Beschreibungen aller angeschlossenen Vektordatenbanken, in welcher die relevanten Informationen zu finden sein könnten, und durchsucht diese. Anschließend trägt er die Ergebnisse in Bezug auf die Anfrage zusammen und liefert die Zusammenfassung dem Koordinator-Agenten.\n4. Der Koordinator-Agent verfasst auf Basis der Informationen nun einen Blog-Artikel. An dieser Stelle könnte beispielsweise auch ein dedizierter Writer-Agent genutzt werden. Der Einfachheitshalber ist dieser nicht im Beispiel enthalten. \n5. Der fertige Blogartikel wird dann an den Social-Media-Agent übergeben der diesen als LinkedIn Beitrag postet, und bei Slack die Mitarbeitenden über die Veröffentlichung benachrichtigt. Anschließend sagt der Social-Media-Agent dem Koordinator-Agent bescheid, dass die Aufgabe erfolgreich erledigt wurde.\n6. Der Koordinator-Agent liefert dem Nutzer nun eine Antwort, in der der Nutzer über den Erfolg der Aufgabe informiert wird. \nUse-Cases für Agentensysteme\nNun, wo wir einige technische Details und Beispiele für Agentensysteme gesehen haben, stellt sich die Frage, für was diese alles eingesetzt werden können. Dabei gibt es bei ihren Einsatzmöglichkeiten viele Möglichkeiten. Hier sind einige Beispiele, wie diese den Arbeitsalltag erleichtern oder sogar gänzlich verändern können.\nKundenservice und Support
⁠\nDurch den Einsatz von intelligenten Chatbots oder virtuellen Assistenten, die weit mehr leisten als Standardantworten, können Agentensysteme den Kundenservice transformieren. Diese Systeme interagieren in natürlicher Sprache, erkennen Kundenbedürfnisse proaktiv, lösen einfachere Anliegen und leiten, wo es notwendig ist, direkt an die richtigen menschlichen Ansprechpartner weiter.\nPersonalmanagement und HR
⁠\nIm Bereich Human Resources können KI-Agenten den gesamten Rekrutierungs- und Onboarding-Prozess unterstützen. Sie analysieren Bewerbungsunterlagen, identifizieren passende Kandidaten anhand vordefinierter Kriterien und beantworten Mitarbeiteranfragen autonom. Dadurch wird nicht nur die Effizienz gesteigert, sondern auch ein personalisierter und schneller Service gewährleistet.\nFinanzwesen und Risikomanagement
⁠\nAgentic AI kann kontinuierlich Finanzdaten überwachen und analysieren, um Markttrends sowie potenzielle Risiken frühzeitig zu erkennen. Autonome Systeme treffen eigenständig Entscheidungsvorschläge, etwa zur Portfolioanpassung oder zur Betrugserkennung, und ermöglichen so eine dynamische und datengetriebene Steuerung finanzieller Prozesse.\nBildung und E-Learning
⁠\nIm Bildungssektor ermöglichen Agentensysteme die Erstellung individueller Lernpfade, indem sie den Fortschritt der Lernenden analysieren und Inhalte passgenau an deren Bedürfnisse anpassen. Dies führt zu einem personalisierten Lernprozess, der auf den jeweiligen Kenntnisstand und Lernfortschritt eingeht.\nEs gibt noch viel mehr Use-Cases, die allesamt zeigen, dass die Fähigkeiten solcher KI-Agenten, selbstständig und flexibel zu agieren, den Unternehmen sowie jedem Einzelnen von uns ganz neue Möglichkeiten bieten. \n
⁠Dein eigenes Agentensystem\nEs gibt viele Möglichkeiten KI-Agenten zu erstellen und zu nutzen. Je nach Anforderungen und Komplexität kann von No-Code-SaaS-Lösungen bis hin zu komplett selbst programmierten Agentensystemen alles gewählt werden. Hierfür stehen bereits massig Services, Tools und Frameworks zur Verfügung. Hier sind ein paar Beispiele:\nEinfach & Schnell\n\nn8n\n - No‑Code-Workflow-Automatisierungstool, das über eine intuitive Drag‑&‑Drop-Oberfläche die Verknüpfung diverser Dienste ermöglicht und schnelle Automatisierungen realisiert. Freie Nutzung privat (Fair‑Code‑Lizenz mit Einschränkungen bei großem kommerziellem Einsatz).\n\nCrewAI\n - Cloudbasierte SaaS-Lösung, mit der sich KI-Agenten schnell und ohne tiefgehende technische Kenntnisse erstellen lassen – ideal für einen schnellen Einstieg. SaaS (abonnementbasierter Cloud-Service).\n\nLangflow\n - Visuelle Open‑Source-Plattform, die den Aufbau und das Testen von LLM‑Anwendungen per Drag‑&‑Drop ermöglicht und sich sehr gut für schnelles Prototyping eignet. Open Source (frei nutzbar für private und kommerzielle Projekte).\n\nsmolagents\n - Minimalistisches Python Framework zur schnellen Implementierung kleiner KI-Agenten, das durch minimalen Overhead und schnelle Resultate überzeugt. Open Source (frei nutzbar für private und kommerzielle Projekte).\nKomplex & Flexibel\n\nLangGraph\n - LangGraph ist eine Python-Bibliothek innerhalb des LangChain-Ökosystems und ermöglicht die Erstellung tiefgreifender Agentensysteme für anspruchsvolle Anwendungsfälle. Open Source (frei nutzbar für private und kommerzielle Projekte).\n\nPydanticAI\n - Kombiniert die Stärken von Pydantic mit LLM-Funktionalitäten, um robuste und typsichere KI-Lösungen zu erstellen. Open‑Source (frei nutzbar für private und kommerzielle Projekte).\n\nAutoGen\n - AutoGen ist ein fortschrittliches Framework zur Orchestrierung von Multi-Agenten-Systemen, das ebenfalls komplexe Interaktionen und Automatisierung in anspruchsvollen Szenarien ermöglicht. Open Source (frei nutzbar für private und kommerzielle Projekte).\nSchlusswort\nWir sind der Ansicht, dass Agentensysteme weit mehr als nur ein vorübergehender Hype sind – sie repräsentieren einen bedeutenden Schritt in Richtung Zukunft. Die aktuellen Entwicklungen zeigen, dass Agentensysteme zunehmend komplexe Prozesse autonom bewältigen können, was uns ganz neue Möglichkeiten eröffnet. Insgesamt glauben wir, dass Agentensysteme einen fundamentalen Wandel sowohl im Privatleben als auch in der Arbeitswelt bewirken werden. \n

KI-Agenten sind mehr als nur Hype. Sie geben uns in ihrem aktuellen Zustand einen Ausblick auf die Arbeitsweise der Zukunft. Wir erzählen dir mehr darüber.

KI-Agenten – Grundlagen, Tools und Use-Cases

Auch an diesem nass-kalten Februartag gibt es wieder eine kurze Übersicht über den Patch Tuesday im kürzesten Monat des Jahres.

**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 Februar 2025 unter anderem wichtige Sicherheitsupdates von Microsoft und schließt damit mehrere Sicherheitslücken. Wichtig zu wissen: Für zwei Sicherheitslücken gibt es bereits Exploits. Zwei weitere Schwachstellen sind öffentlich bekannt. Hier gilt es, die Lücken zügig zu schließen.

Über die [CVE-2025-21418](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21418) können Angreifer ihre Rechte ausweiten, ein Exploit ist dazu bekannt. Dazu werden vom Angreifer kompromittierte Mails versendet. Die Lücke [CVE-2025-21391](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21391) wird bereits ausgenutzt, hier können Angreifer Daten in Windows löschen. Durch eine Verkettung mit anderen Schwachstellen können die Angreifer so ganze Systeme übernehmen.

Patches wurden für Windows 10 und Windows 11 herausgebracht, sowie für die gängigen Server-Typen.

Im Februar wurden keine kritischen SAP-Schwachstellen veröffentlicht. Zusätzlich zu neuen Schwachstellen kamen zwei Updates heraus. Das eine Update betrifft eine Cross-Site-Scripting Schwachstelle von 2024 (CVE-2024-22126) und das zweite Update betrifft eine Improper Access Control (CVE-2023-24527).

Mehr Informationen über diese und weitere Schwachstellen sind [hier](https://support.sap.com/en/my-support/knowledge-base/security-notes-news/february-2025.html) zu finden.

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

[Adobe](https://helpx.adobe.com/security/security-bulletin.html): Sicherheitsupdates für diverse Produkte, wobei für Commerce 31 CVEs veröffentlicht wurden.

[Cisco](https://sec.cloudapps.cisco.com/security/center/publicationListing.x): Sicherheitsupdates für mehrere Produkte, darunter Cisco Secure Mail und Cisco Secure Web.

[Ivanti](https://www.ivanti.com/blog/february-security-update): Sicherheitsupdates für mehrere Produkte, darunter Ivanti Connect Secure.

Fortinet: [Sicherheitsupdate](https://www.fortiguard.com/psirt/FG-IR-24-535) für eine bereits ausgenutzte kritische Schwachstelle in FortiOS & FortiProxy. Dies betrifft eine bereits im Januar veröffentlichte Schwachstelle. Inkludiert in der MItteilung sind IOCs (Indicator of Compromise), nach denen Administratoren suchen können. Weitere Updates sind auf der [PSIRT Seite](https://www.fortiguard.com/psirt?page=1&date=&severity=&product=FortiAP-W2,FortiTester,FortiEDR%20Manager,FortiCloud,FortiRecorder,FortiNDR,FortiConverter,FortiAP-U,FortiIsolator,FortiAP-C,FortiEDR,FortiSandbox,FortiWeb,FortiAP-S,Meru%20AP,FortiClientMac,FortiNAC,FortiPresence,FortiDDoS-F,FortiADCManager,FortiAuthenticator,FSSO%20Windows%20CA,FortiClientLinux,FortiClientWindows,FortiClientiOS,FortiSDNConnector,FortiMail,FortiWebManager,FortiADC,FortiSOAR,FortiOS-6K7K,FortiOS,AV%20Engine,FortiAIOps,FortiPAM,FortiAnalyzer%20Cloud,FortiTokenMobileWP,FortiFone,FortiAnalyzer,FortiAnalyzer-BigData,FortiVoice,Meru%20Controller,FortiNAC-F,FortiManager%20Cloud,FortiWLC,FortiExtender,FortiPortal,FortiSIEM,FortiDeceptor,FortiSwitch,FortiClientAndroid,IPS%20Engine,FortiAP,FortiDDoS,FortiWAN,FortiClientEMS,FortiTokenIOS,FortiProxy,FortiTokenAndroid,FortiSIEMWindowsAgent,FortiDDoS-CM,FSSO%20Windows%20DC%20Agent,FortiGuest,FortiSwitchManager,FortiWLM,FortiManager&component=&version=) von Fortinet zu finden.

Kurze Zusammenfassung der Sicherheitsupdates aus dem Patch Tuesday Februar 2025

Patch Tuesday Februar 2025

Lead API Consultant

Senior Solution Architect / Head of API Consulting

*Viele Unternehmen setzen große Hoffnungen in API-Plattformen. Sie sollen Integrationen erleichtern, Wiederverwendung fördern und das Unternehmen technologisch zukunftssicher machen. Nach der Einführung scheint vieles auf einem guten Weg zu sein: Die Plattform ist etabliert, erste Projekte wurden erfolgreich umgesetzt und das Team rund um die API-Plattform baut Wissen auf. Doch nach einer gewissen Zeit zeigt sich ein wiederkehrendes Muster. Die Nachfrage nach neuen APIs nimmt ab, bestehende APIs werden kaum wiederverwendet und das API-Team wird zunehmend als Flaschenhals wahrgenommen. APIs entstehen meist erst dann, wenn sie unmittelbar für ein Projekt benötigt werden – oft unter Zeitdruck und ohne Blick auf eine langfristige Strategie.*

In diesem Blog Post verwenden wir die Begriffe *Integration* und *API* und definieren sie dafür wie folgt:

&gt; **Integration**: bezeichnet die Verknüpfung verschiedener Systeme oder Anwendungen, um einen nahtlosen Datenaustausch zu automatisierte Prozesse zu ermöglichen.

&gt;**API**: ist eine definierte Schnittstelle, die es Anwendungen ermöglicht, miteinander zu kommunizieren.

Das API-Team ist sich dieser Herausforderungen bewusst und versucht gegenzusteuern. Es werden Workshops organisiert, Best Practices definiert und Optimierungen der Plattform, wie z.B. die Entwicklung von Self-Service Funktionalitäten, angestoßen. Doch strukturelle Probleme lassen sich auf diese Weise nur schwer lösen. Solange Integrationen in einzelnen Projekten isoliert betrachtet werden und keine übergreifende API-Strategie existiert, bleibt die Plattform in ihrer Wirkung begrenzt. APIs entstehen und verschwinden, ohne dass sie langfristig einen Mehrwert bieten.

## Warum die Bereitstellung von APIs nicht automatisch zu ihrer effektiven Nutzung führt
Was viele Organisationen unterschätzen: Der Aufbau einer API-Plattform ist nur der erste Schritt. Der eigentliche Mehrwert entsteht erst dann, wenn APIs nicht nur bereitgestellt, sondern auch aktiv genutzt und weiterentwickelt werden. Doch genau hier scheitern viele Organisationen. Die Gründe sind vielfältig: Oft fehlt eine übergeordnete API-Strategie, die eine konsistente und wiederverwendbare API-Landschaft fördert, andere Organisationen scheitern dagegen an der Umsetzung oder Kommunikation der Strategie.

Ein zentrales Problem ist, dass APIs oft als rein technische Notwendigkeit verstanden werden, nicht als Business-Enabler. Solange sie nur entwickelt werden, weil eine Schnittstelle auf die Schnelle gebraucht wird, fehlt die strategische Komponente. APIs entstehen sehr oft ausschließlich reaktiv im Rahmen eines bestimmten Projekts – als Mittel, um eine Integration schnell zum Laufen zu bringen. Dabei wird wenig darüber nachgedacht, ob eine API auch für andere Anwendungsfälle geeignet und damit wiederverwendbar sein könnte, sie langfristig erweiterbar ist oder einen nachhaltigen Mehrwert für das Unternehmen schafft.

Diese projektgetriebene Entwicklung führt dazu, dass APIs kaum über den unmittelbaren Anwendungsfall hinaus gedacht werden. Das Ergebnis ist eine Sammlung von punktuellen Integrationen zwischen genau zwei Systemen. Diese Integrationen erfüllen kurzfristig ihren Zweck, führen aber langfristig zu einer fragmentierten, schwer wartbaren Architektur.

Auch ist die Rolle des API-Teams ein Problem. Häufig wird es als reiner „Service Provider“ betrachtet, der Integrationen auf Zuruf entwickelt. Die Einbindung erfolgt oft erst spät im Projekt, wenn die grundlegenden Anforderungen bereits festgelegt sind und keine Möglichkeit mehr besteht, das API-Design hinsichtlich Wiederverwendung zu optimieren. Dadurch bleibt das API-Team auf die Umsetzung beschränkt und kann keinen strategischen Einfluss auf die API-Landschaft nehmen. Gleichzeitig fehlt es vielen Entwicklungsteams an einem tiefgehenden Verständnis für gutes API-Design, weil es keine systematische Unterstützung oder Enablement-Prozesse gibt.

Ein weiteres Problem ist die Wahrnehmung der Plattform selbst. Anstatt als Enabler für moderne Integration gesehen zu werden, wirkt sie auf viele Entwickler eher wie eine Vorgabe, die es zu erfüllen gilt. Die Technologie steht im Mittelpunkt, nicht der eigentliche Mehrwert von APIs. Statt die Plattform zu nutzen, um Integrationen nachhaltig zu verbessern, wird sie oft nur als Mittel zum Zweck zur punktuellen Integration eingesetzt. Das führt dazu, dass APIs entstehen, weil sie ad hoc gebraucht werden – nicht, weil sie als wertvolles Werkzeug zur Optimierung von Geschäftsprozessen verstanden werden.

Gleichzeitig sind API-Plattformen oft komplex und schwerfällig. Ohne größere Anpassungen werden nur wenige Standardfälle für Integrationen abgedeckt und der Automatisierungsgrad ist niedrig. Damit wirken sie auf Entwicklungsteams oft abschreckend und nicht gewinnbringend.

Auch API-Governance wird oft falsch verstanden. Zwar existieren in vielen Unternehmen technische Standards, doch es fehlen Metriken, um den tatsächlichen Nutzen und die Effektivität von APIs zu bewerten. Fragen wie „Wird eine API tatsächlich genutzt?“, „Wie lange dauert es, bis Entwicklungsteams sie erfolgreich einsetzen können?“ oder „Trägt die API in Zukunft dazu bei, Integrationsaufwände zu reduzieren?“ werden selten gestellt. Ohne diese Daten bleibt unklar, ob eine API wirklich einen Mehrwert liefert oder nur eine weitere technische Schnittstelle ist, die in Vergessenheit gerät.

Letztlich reicht es nicht aus, APIs einfach nur bereitzustellen. Sie müssen so gestaltet werden, dass sie langfristig Wert stiften, effizient nutzbar sind und strategisch zur Unternehmensarchitektur passen. Fehlt dieser Ansatz, bleibt eine API-Plattform ein gut gemeintes, aber wirkungsloses Werkzeug, das eher als Hürde denn als Enabler wahrgenommen wird.

## API-Effektivität durch Team Topologies
Der Schlüssel zu effektiven APIs liegt nicht nur in der Technologie, sondern vor allem in der richtigen Organisationsstruktur. Unternehmen müssen den Wechsel von einer projektgetriebenen API-Entwicklung zu strategischen API-Produkten vollziehen. Hier bietet das Konzept der **Team Topologies** einen klaren Rahmen.

<img height="500" width="400" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YcV9FmkrQOyVUqMeOZpn">

*Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.*

Team Topologies definiert vier verschiedene Team-Typen, von denen drei im API-Kontext besondere Relevanz haben: Platform Team, Enabling Team und Stream-Aligned Teams.

Ein **Platform Team** bildet das Rückgrat der API-Plattform. Es stellt nicht nur die Infrastruktur bereit, sondern sorgt auch für eine gute Developer Experience, fördert die Wiederverwendbarkeit von APIs und bietet Self-Service-Funktionen mit hohem Automatisierungsgrad an. Anstatt sich auf Governance oder Tooling zu beschränken, sollte das Platform Team APIs gezielt nutzbar machen und eine API-Strategie mit messbaren Zielen entwickeln.

Ein **Enabling Team** unterstützt andere Teams dabei, APIs als Produkte zu denken. Es hilft Entwicklungsteams, Best Practices zu etablieren, Wiederverwendung zu fördern und APIs gezielt für eine breitere Nutzerbasis zu gestalten. Ohne eine solche Unterstützung bleibt API-Entwicklung oft isoliert und ineffektiv.

Die größte Veränderung entsteht jedoch in den **Stream-Aligned Teams**. Diese Teams verantworten ihre APIs eigenständig und entwickeln sie mit einem langfristigen Produktgedanken. APIs werden nicht mehr nur gebaut, um ein Projekt abzuschließen, sondern um nachhaltig Mehrwert zu schaffen. So entsteht echte API-Ownership, die sich direkt auf die Effektivität auswirkt. Wenn Teams die volle Verantwortung für ihre APIs übernehmen, denken sie über deren langfristige Nutzung, Erweiterbarkeit und Qualität nach. Dadurch entstehen besser durchdachte, wiederverwendbare und wirtschaftlich sinnvolle APIs.

Ein zentraler Vorteil, der durch Team Topologies realisiert wird, ist die Abkehr von isolierten Punkt-zu-Punkt-Integrationen hin zu strategisch geplanten API-Produkten. APIs müssen langfristig gedacht werden, mit einer klaren Roadmap und definierten Metriken zur Erfolgsmessung: Adoption Rate, Time-to-First-Success oder die Reusability Rate sind essentiell, um zu verstehen, ob eine API tatsächlich genutzt und wiederverwendet wird oder nur ein weiteres technisches Artefakt bleibt.

## Fazit: API-Strategie entscheidet über den Erfolg
Eine API-Plattform allein reicht nicht aus, um nachhaltige Integrationserfolge zu erzielen. Entscheidend ist, dass APIs nicht nur bereitgestellt, sondern effektiv genutzt und weiterentwickelt werden. Ohne eine klar formulierte und umgesetzte Strategie bleibt eine API-Plattform eine technische Notwendigkeit, die genutzt wird, weil sie vorgeschrieben ist – mit der richtigen Teamstruktur wird sie hingegen zu einem echten Enabler für digitale Transformation.
Der Wechsel von reiner API-Bereitstellung zu API-Effektivität erfordert mehr als gute Technologie. Es geht darum, APIs als wertvolle Assets zu betrachten und ihre Entwicklung so zu organisieren, dass sie langfristig einen echten Beitrag zur Unternehmensstrategie leisten. Wer möchte, dass eine API-Plattform in der Organisation ihre erhoffte Wirkung entfaltet, muss über Technologie hinausdenken – und das Zusammenspiel von Teams, Prozessen und Strategie in den Mittelpunkt stellen.

Häufig erfüllen API-Plattformen nicht die Erwartungen. Eine strategische Herangehensweise und die richtigen Teamstrukturen können jedoch den Unterschied machen.

Wenn die erhoffte Wirkung der API-Plattform ausbleibt

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

Generative KI

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

Do you have any questions or would you like to exchange ideas? Happy to help – just enter your contact details.

[ENG] Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Contact us

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

About us

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

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

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen