[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-content-tech-news-der-woche-kw-21":3},"\u003Cp>KW21 ist im Web- und Infrastruktur-Stack ungewöhnlich dicht besetzt. \u003Cstrong>GitLab 19.0 geht heute (21. Mai) GA\u003C\u002Fstrong> und bringt 15 Breaking Changes mit, die jede selbst-gehostete Instanz betreffen. Parallel werden zwei aktive Exploits gefahren — die Cisco-Catalyst-SD-WAN-Lücke mit CVSS 10.0 und der \u003Cstrong>TanStack-Shai-Hulud-Wurm\u003C\u002Fstrong>, der über vergiftete GitHub-Actions-Caches ganze Build-Pipelines abgreift. Grafana meldet einen Codebase-Klau via GitHub-Token, Ollama vollzieht den Architektur-Wechsel auf llama.cpp und MLX, und die deutsche A12-Plattform geht unter EUPL 1.2 als Open Source online. Hier ist, was in der Praxis wirklich zählt.\u003C\u002Fp>\n\n\u003Ch2>Top-Story: GitLab 19.0 GA — Envoy statt NGINX, Valkey statt Redis, PostgreSQL 17 Pflicht\u003C\u002Fh2>\n\u003Cp>GitLab 19.0 ist heute GA. Wer eine selbst-gehostete Instanz betreibt, sollte sich den \u003Ca href=\"https:\u002F\u002Fabout.gitlab.com\u002Fblog\u002Fa-guide-to-the-breaking-changes-in-gitlab-19-0\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Breaking-Changes-Guide\u003C\u002Fa> im Detail anschauen — 15 Breaking Changes, eine drastische Reduktion gegenüber den 27 in 18.0 und 80 in 17.0, aber trotzdem ein Upgrade, das man nicht im Vorbeigehen einspielt.\u003C\u002Fp>\n\u003Cp>Die drei härtesten Punkte: \u003Cstrong>NGINX Ingress ist EOL\u003C\u002Fstrong> und wird durch \u003Cstrong>Gateway API mit Envoy Gateway\u003C\u002Fstrong> ersetzt — wer GitLab via Helm Chart auf Kubernetes betreibt, muss die Ingress-Konfiguration komplett umbauen. \u003Cstrong>Valkey ersetzt Redis als Default-Binary\u003C\u002Fstrong> im Linux-Package; externe Redis-6-Instanzen müssen vor dem Upgrade auf Redis 7.2 oder Valkey 7.2 migriert werden. \u003Cstrong>PostgreSQL 17 wird neue Mindestversion\u003C\u002Fstrong> — wer mit Postgres 14 oder 15 fährt, muss die Datenbank vorher heben. Dazu fliegen gebündeltes PostgreSQL, Redis und MinIO aus dem Helm Chart raus.\u003C\u002Fp>\n\u003Cp>Weitere Drops: Ubuntu 20.04 als Support-Plattform, SUSE-Linux-Package, gebundeltes Mattermost, der OAuth Resource-Owner-Password-Credentials-Flow (was nach OAuth 2.1 RFC ohnehin überfällig war). Auf der positiven Seite landet \u003Cstrong>GitLab Duo Agent Platform\u003C\u002Fstrong> mit besserer Claude-Opus-4.7-Integration für agentic Chat und Workflows. Plan-Tipp: erst Staging upgraden, externe Postgres und Redis vorher heben, Ingress-Konfiguration neu schreiben, dann Production in einem dedizierten Wartungsfenster ziehen.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fabout.gitlab.com\u002Fblog\u002Fa-guide-to-the-breaking-changes-in-gitlab-19-0\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitLab Blog — Breaking Changes in 19.0\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Freleases\u002F19\u002Fgitlab-19-0-released\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitLab Docs — 19.0 Release Notes\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Cfigure>\n\u003Cimg src=\"\u002Fimages\u002Fblog\u002Fweekly-tech-news-kw21-gitlab19.webp\" alt=\"Isometrische Darstellung der GitLab-19-Migration — NGINX→Envoy und Redis→Valkey\" loading=\"lazy\">\n\u003C\u002Ffigure>\n\n\u003Ch2>Cisco Catalyst SD-WAN — CVSS-10.0-Auth-Bypass aktiv exploitet\u003C\u002Fh2>\n\u003Cp>Cisco hat in der Vorwoche \u003Ca href=\"https:\u002F\u002Fwww.cisco.com\u002Fc\u002Fen\u002Fus\u002Fsupport\u002Fdocs\u002Fcsa\u002Fcisco-sa-sdwan-rpa2-v69WY2SW.html\" target=\"_blank\" rel=\"noopener noreferrer\">CVE-2026-20182\u003C\u002Fa> veröffentlicht — eine Authentication-Bypass-Schwachstelle im Catalyst SD-WAN Controller und im SD-WAN Manager mit dem Maximum-Score CVSS 10.0. Konkret betroffen ist die Peering-Authentication im \u003Ccode>vdaemon\u003C\u002Fcode>-Service über DTLS auf UDP-Port 12346. Ein unauthentifizierter Remote-Angreifer kann die Authentication komplett umgehen und administrative Privilegien auf dem System bekommen.\u003C\u002Fp>\n\u003Cp>Cisco PSIRT hat \u003Cstrong>aktive Exploitation in freier Wildbahn\u003C\u002Fstrong> bestätigt und attribuiert die Aktivität mit hoher Konfidenz dem Threat-Cluster \u003Cstrong>UAT-8616\u003C\u002Fstrong> — derselbe Akteur, der bereits CVE-2026-20127 für unauthorisierten SD-WAN-Zugriff weaponized hat. Die \u003Ca href=\"https:\u002F\u002Fsecurityaffairs.com\u002F192157\u002Fhacking\u002Fu-s-cisa-adds-a-flaw-in-cisco-catalyst-sd-wan-to-its-known-exploited-vulnerabilities-catalog.html\" target=\"_blank\" rel=\"noopener noreferrer\">CISA hat die Lücke in den KEV-Katalog\u003C\u002Fa> aufgenommen und für FCEB-Behörden eine Remediation-Deadline auf den \u003Cstrong>17. Mai\u003C\u002Fstrong> gesetzt — die ist also bereits abgelaufen. Für jeden privaten Cisco-Catalyst-SD-WAN-Betreiber gilt: Patchen, sofort. Rapid7 hat eine \u003Ca href=\"https:\u002F\u002Fwww.rapid7.com\u002Fblog\u002Fpost\u002Fve-cve-2026-20182-critical-authentication-bypass-cisco-catalyst-sd-wan-controller-fixed\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">detaillierte Analyse mit Detection-Hinweisen\u003C\u002Fa> veröffentlicht — wer die letzten 30 Tage Logs nicht prüfen kann, sollte den Controller als kompromittiert annehmen.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.cisco.com\u002Fc\u002Fen\u002Fus\u002Fsupport\u002Fdocs\u002Fcsa\u002Fcisco-sa-sdwan-rpa2-v69WY2SW.html\" target=\"_blank\" rel=\"noopener noreferrer\">Cisco Security Advisory CVE-2026-20182\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.rapid7.com\u002Fblog\u002Fpost\u002Fve-cve-2026-20182-critical-authentication-bypass-cisco-catalyst-sd-wan-controller-fixed\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Rapid7 Vulnerability Engineering Analyse\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fsecurityaffairs.com\u002F192157\u002Fhacking\u002Fu-s-cisa-adds-a-flaw-in-cisco-catalyst-sd-wan-to-its-known-exploited-vulnerabilities-catalog.html\" target=\"_blank\" rel=\"noopener noreferrer\">Security Affairs — CISA KEV Addition\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Shai-Hulud-Wurm 2.0 — TanStack, Mistral und 160+ npm\u002FPyPI-Pakete betroffen\u003C\u002Fh2>\n\u003Cp>Am 11. Mai hat eine neue Variante des \u003Cstrong>Mini-Shai-Hulud-Wurms\u003C\u002Fstrong> zugeschlagen. \u003Ca href=\"https:\u002F\u002Fsnyk.io\u002Fblog\u002Ftanstack-npm-packages-compromised\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Snyk und Wiz haben den Vorfall\u003C\u002Fa> detailliert dokumentiert: \u003Cstrong>84 npm-Package-Artefakte über 42 @tanstack\u002F*-Pakete kompromittiert\u003C\u002Fstrong>, dazu eine Welle weiterer Pakete in npm und PyPI — insgesamt über 160 Pakete betroffen, darunter Mistral AI, UiPath, Guardrails AI.\u003C\u002Fp>\n\u003Cp>Der Angriffspfad ist ein präziser Drei-Schritt: Der Angreifer forkt das \u003Ccode>TanStack\u002Frouter\u003C\u002Fcode>-Repository, öffnet einen Pull Request, der einen \u003Ccode>pull_request_target\u003C\u002Fcode>-Workflow triggert, der wiederum Fork-Code mit voller Production-Token-Reichweite ausführt. Dort wird der \u003Cstrong>GitHub-Actions-Cache mit einem malicious pnpm-Store vergiftet\u003C\u002Fstrong>. Wenn später ein legitimer Maintainer-PR zu \u003Ccode>main\u003C\u002Fcode> gemerged wird, restored der Release-Workflow den vergifteten Cache, die Angreifer-Binary extrahiert OIDC-Tokens aus dem Runner-Prozess-Memory und published infizierte Package-Versionen auf npm.\u003C\u002Fp>\n\u003Cp>Die Malware installiert auf den Entwickler-Maschinen einen persistenten \u003Cstrong>gh-token-monitor-Daemon\u003C\u002Fstrong> (macOS LaunchAgent \u002F Linux systemd), der jede Minute GitHub anpingt. Bei einem 40X-Fehler — etwa weil das Token rotiert wurde — versucht er \u003Ccode>rm -rf ~\u002F\u003C\u002Fcode>. Nach 24 Stunden ohne Token-Rotation deaktiviert sich der Daemon selbst. Wer am 11. Mai eine \u003Ccode>@tanstack\u002F*\u003C\u002Fcode>-Version installiert hat, sollte die betroffene Umgebung als kompromittiert behandeln und jedes Secret rotieren, das von dort aus erreichbar war.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fsnyk.io\u002Fblog\u002Ftanstack-npm-packages-compromised\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Snyk — TanStack npm Compromise\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.wiz.io\u002Fblog\u002Fmini-shai-hulud-strikes-again-tanstack-more-npm-packages-compromised\" target=\"_blank\" rel=\"noopener noreferrer\">Wiz — Mini Shai-Hulud Strikes Again\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fthehackernews.com\u002F2026\u002F05\u002Fmini-shai-hulud-worm-compromises.html\" target=\"_blank\" rel=\"noopener noreferrer\">Hacker News — Compromise Discussion\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Grafana Codebase-Klau über GitHub-Token\u003C\u002Fh2>\n\u003Cp>Am 16. Mai hat \u003Ca href=\"https:\u002F\u002Fthehackernews.com\u002F2026\u002F05\u002Fgrafana-github-token-breach-led-to.html\" target=\"_blank\" rel=\"noopener noreferrer\">Grafana Labs öffentlich gemacht\u003C\u002Fa>, dass ein Angreifer ein Token mit Zugriff auf die GitHub-Umgebung kompromittiert und die Codebase heruntergeladen hat. Die Ursache: eine kürzlich aktivierte GitHub Action mit einer \u003Cstrong>\"Pwn Request\"-Vulnerability\u003C\u002Fstrong> — eine Workflow-Misskonfiguration, die \u003Ccode>pull_request_target\u003C\u002Fcode>-Events von externen Forks ausführt und dabei Production-Secrets exponiert.\u003C\u002Fp>\n\u003Cp>Der Angreifer hat ein Grafana-Repository geforkt, malicious Code per \u003Ccode>curl\u003C\u002Fcode> injected, Environment-Variablen in eine mit Private-Key verschlüsselte Datei gedumpt und privilegierte Tokens extrahiert. Detection lief über einen der \u003Cstrong>tausenden Grafana-Canary-Tokens\u003C\u002Fstrong> — als das Token unerwartet getriggered wurde, hat das Security-Team die Alarmstufe ausgelöst, das kompromittierte Token invalidiert, die GitHub Action entfernt und alle Public-Repo-Workflows deaktiviert. Eine CoinbaseCartel-genannte Gruppe hat die Verantwortung übernommen und Ransom gefordert; Grafana hat \u003Cstrong>das Lösegeld auf FBI-Empfehlung nicht gezahlt\u003C\u002Fstrong>. Kundendaten waren laut Grafana nicht betroffen.\u003C\u002Fp>\n\u003Cp>Lessons: Erstens — Canary-Tokens funktionieren. Zweitens — \u003Ccode>pull_request_target\u003C\u002Fcode>-Workflows ohne strenge Branch- und Author-Checks sind eine offene Tür. Drittens — die Source-Code-Exposition als solche ist für Open-Source-First-Unternehmen wie Grafana weniger schlimm als die Token-Exposition.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fthehackernews.com\u002F2026\u002F05\u002Fgrafana-github-token-breach-led-to.html\" target=\"_blank\" rel=\"noopener noreferrer\">The Hacker News — Grafana Token Breach\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fcybersecuritynews.com\u002Fgrafana-labs-security-breach\u002Famp\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Cybersecurity News — Grafana Breach\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Ollama vollzieht den Architektur-Wechsel auf llama.cpp und MLX\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Follama\u002Follama\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">Ollama\u003C\u002Fa> hat in den letzten zwei Wochen einen leisen, aber strukturellen Umbau geliefert. \u003Cstrong>v0.23.4\u003C\u002Fstrong> ist seit dem 13. Mai die latest-stable; v0.24.0-rc0 vom 14. Mai bringt \u003Cstrong>Codex App Integration\u003C\u002Fstrong> (\u003Ccode>ollama launch codex\u003C\u002Fcode>) und MLX-Memory-Trace-Logging. Der wichtigere Wechsel passiert in der v0.30.0-rc15-Linie: \u003Cstrong>Ollama läuft jetzt direkt auf llama.cpp\u003C\u002Fstrong> statt auf der eigenen GGML-Implementierung und unterstützt \u003Cstrong>GGUF nativ\u003C\u002Fstrong>. Auf Apple Silicon kommt \u003Cstrong>MLX als Beschleunigungs-Backend\u003C\u002Fstrong> dazu — Routing geschieht automatisch nach Modell-Format.\u003C\u002Fp>\n\u003Cp>Die Performance-Auswirkungen sind dokumentiert: Auf einem M4 Max 32 GB hebt MLX ein Qwen 3.5 35B-A3B-Modell von rund \u003Ca href=\"https:\u002F\u002Follama.com\u002Fblog\u002Fmlx\" target=\"_blank\" rel=\"noopener noreferrer\">45 tok\u002Fs mit llama.cpp Metal auf 70–80 tok\u002Fs mit MLX\u003C\u002Fa>, bei rund 10 Prozent geringerem Speicherverbrauch. Für DACH-Devs, die Apple-Silicon-Workstations als Dev-Inference-Setup nutzen, ist das \u003Cstrong>die wichtigste Setup-Änderung der letzten Quartale\u003C\u002Fstrong> — endlich kommt das volle MLX-Potenzial in der Mainstream-Toolchain an, ohne dass man separate MLX-Stacks neben Ollama betreiben muss.\u003C\u002Fp>\n\u003Cp>Wer auf Production-Stacks fährt, bleibt für den Moment bei \u003Cstrong>vLLM\u003C\u002Fstrong> (siehe oben, v0.21 RC1 mit TOKENSPEED_MLA). Aber für Single-Developer-Setups und kleine Inferenz-Knoten ist Ollama jetzt wieder die saubere Default-Wahl.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Follama\u002Follama\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">Ollama Releases\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Follama.com\u002Fblog\u002Fmlx\" target=\"_blank\" rel=\"noopener noreferrer\">Ollama Blog — MLX on Apple Silicon\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Atlassian Rovo Code Intelligence — Multi-Repo-Source-Graph-Queries\u003C\u002Fh2>\n\u003Cp>Atlassian hat im \u003Ca href=\"https:\u002F\u002Fwww.atlassian.com\u002Fblog\u002Fdevops\" target=\"_blank\" rel=\"noopener noreferrer\">DevOps-Blog\u003C\u002Fa> \u003Cstrong>Rovo Code Intelligence\u003C\u002Fstrong> weiter aufgebaut — die Multi-Repo-Source-Graph-Query-Schicht, die typische Refactoring-Fragen beantworten soll: \"Welche Services nutzen ein veraltetes UI-Pattern? Wer owns die Migration? Welche Tests müssen wir vor dem Switch noch laufen lassen?\". Konzeptuell sehr ähnlich zu GitHub Copilot Custom Agents, aber für die Atlassian-Welt: Confluence-Pages, Jira-Tickets und Repository-Daten landen in einem gemeinsamen Source Graph.\u003C\u002Fp>\n\u003Cp>Für DACH-Teams, die Atlassian-Cloud nutzen, ist das relevant, weil Multi-Repo-Reasoning bisher nur über Custom-Pipelines oder Source-Code-Graph-Tools wie Sourcegraph ging. Rovo zieht das näher an die ohnehin schon vorhandene Tool-Suite heran. Für Teams in DSGVO-kritischen Branchen bleibt die Frage: Welche Source-Code-Daten landen für die Indizierung in welcher Cloud-Region? Atlassian hat dazu noch keine klare DACH-Hosting-Roadmap geliefert — Frage gehört im Procurement-Gespräch auf den Tisch.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.atlassian.com\u002Fblog\u002Fdevops\" target=\"_blank\" rel=\"noopener noreferrer\">Atlassian DevOps Blog\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>DACH-Story: A12-Plattform geht Open Source — die Software hinter ELSTER\u003C\u002Fh2>\n\u003Cp>Am wichtigsten DACH-News-Punkt der Woche steht nicht ein Cyber-Incident, sondern ein Open-Source-Release. Das \u003Cstrong>Bayerische Landesamt für Steuern und mgm technology partners\u003C\u002Fstrong> geben die \u003Ca href=\"https:\u002F\u002Finsights.mgm-tp.com\u002Fde\u002F2026\u002Funternehmen\u002Fa12-enterprise-ai-low-code-plattform-wird-open-source-bayerisches-landesamt-fuer-steuern-und-mgm-oeffnen-quellcode\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">A12 Enterprise AI Low-Code-Plattform\u003C\u002Fa> unter \u003Cstrong>EUPL 1.2\u003C\u002Fstrong> frei. A12 ist die Software-Basis, auf der \u003Cstrong>ELSTER\u003C\u002Fstrong> läuft — das zentrale Online-Steuerportal Deutschlands.\u003C\u002Fp>\n\u003Cp>Die Plattform ermöglicht es, komplexe Verwaltungs-Anwendungen modell-basiert zu entwickeln — Domain-Experten designen die Anwendungs-Logik, ohne tief programmieren zu müssen. Für die DACH-Verwaltungs-Digitalisierung ist das ein größerer Hebel als die meisten \"AI-Use-Case\"-Pilotprojekte: Eine an produktivem ELSTER-Volumen bewiesene Plattform geht in den offenen Pool und kann von jeder Behörde, jedem Landesamt, jeder Kommune verwendet werden. Sergio Lerena (mgm) ordnet es in der \u003Ca href=\"https:\u002F\u002Fwww.allgeier.com\u002Fde\u002Fpressroom\u002Fpress-releases\u002Fa12-enterprise-ai-low-code-plattform-wird-open-source-bayerisches-landesamt-fuer-steuern-und-mgm-oeffnen-quellcode\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Pressemeldung\u003C\u002Fa> klar ein: \"Wir schaffen ein neues Fundament für digitale Souveränität im öffentlichen Sektor.\" Repository auf GitHub und Opencode, Code in den nächsten Wochen.\u003C\u002Fp>\n\u003Cp>Das passt in das größere Bild des \u003Cstrong>Deutschland-Stacks\u003C\u002Fstrong>, an dem das \u003Ca href=\"https:\u002F\u002Fbmds.bund.de\u002Faktuelles\u002Fpressemitteilungen\u002Fdetail\u002Fki-basierte-open-source-module-fuer-die-verwaltung\" target=\"_blank\" rel=\"noopener noreferrer\">Bundesministerium für Digitales und Staatsmodernisierung (BMDS)\u003C\u002Fa> zusammen mit Ländern und Kommunen baut: souveräne, interoperable Plattform-Bausteine für die Verwaltung. Für DACH-Plattform-Anbieter ist das ein klares Signal — Open-Source-Komponenten der Verwaltung sind kein Wunschdenken mehr, sondern Strukturpolitik.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Finsights.mgm-tp.com\u002Fde\u002F2026\u002Funternehmen\u002Fa12-enterprise-ai-low-code-plattform-wird-open-source-bayerisches-landesamt-fuer-steuern-und-mgm-oeffnen-quellcode\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">mgm Insights — A12 wird Open Source\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.allgeier.com\u002Fde\u002Fpressroom\u002Fpress-releases\u002Fa12-enterprise-ai-low-code-plattform-wird-open-source-bayerisches-landesamt-fuer-steuern-und-mgm-oeffnen-quellcode\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Allgeier SE Pressemitteilung\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fbmds.bund.de\u002Faktuelles\u002Fpressemitteilungen\u002Fdetail\u002Fki-basierte-open-source-module-fuer-die-verwaltung\" target=\"_blank\" rel=\"noopener noreferrer\">BMDS — KI-basierte Open-Source-Module\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Fazit\u003C\u002Fh2>\n\u003Cp>KW21 zeichnet zwei sehr unterschiedliche Pfeile auf dasselbe Brett. Im Plattform-Maschinenraum kommen mit GitLab 19.0, dem Ollama-Architektur-Wechsel und der laufenden vLLM-Welle harte, planungspflichtige Releases — wer Self-Hosting fährt, bekommt in den nächsten 30 Tagen eine ehrliche Migration-Pipeline. Auf der Security-Seite zeigt die parallele Welle aus Cisco SD-WAN, Shai-Hulud-Wurm und Grafana-Token-Klau, dass die Supply-Chain- und Identity-Schicht weiterhin der dünnste Punkt im Stack ist — Canary-Tokens, Branch-Protection und strikte Action-Policies sind keine Optionen mehr, sondern Pflicht. Und an der DACH-Front zeigt die A12-Open-Source-Veröffentlichung, dass die Verwaltungs-Digitalisierung jetzt ernsthaft auf souveräne Open-Source-Plattformen umstellt — mit ELSTER als Referenz. Wer in der Architektur-Diskussion bisher mit \"ja, aber zeig mir einen Production-Case\" antworten musste, hat ab dieser Woche einen.\u003C\u002Fp>\n\n\u003Cp>\u003Cem>Kuratiert von SEADEV Studios — Stand: 18. Mai 2026\u003C\u002Fem>\u003C\u002Fp>\n"]