Nachdem GitLab seine Duo Agent Platform zum Jahresbeginn allgemein verfügbar gemacht hatte – inklusive Agentic Chat, Planner Agent und Security Analyst Agent –, legt das Unternehmen mit dem Release GitLab 18.9 nach. Die Neuerungen konzentrieren sich unter anderem auf die Anbindung eigener KI-Modelle, einen umfangreichen Ausbau der Sicherheitswerkzeuge und die Lieferung eines von Entwicklerinnen und Entwicklern lang gewünschten Features: Project-level Epics.

Eigene KI-Modelle per Token-Authentifizierung anbinden

Unter dem Motto Bring Your Own Key (BYOK) führt GitLab in einem ersten Schritt die Möglichkeit ein, unternehmenseigene KI-Modell-Abonnements über das GitLab AI Gateway zu nutzen. Unternehmen sollen damit bestehende Verträge mit KI-Anbietern weiterhin nutzen können, während sie gleichzeitig Zugriff auf die agentischen Workflow-Funktionen der Duo Agent Platform erhalten. Die Anbindung erfolgt über tokenbasierte Authentifizierung. Das Feature baut auf der Self-Hosted-Option der Duo Agent Platform und der Modellauswahl aus früheren Releases auf.

Ebenfalls erweitert wird der Agentic Chat: Er soll künftig Datei-Uploads und Web-Inhalte als vollwertigen Kontext verarbeiten können. Teams könnten damit Logs, Spezifikationen und Dokumentationen direkt in Agenten-Konversationen einbringen, ohne zwischen externen Dokumenten und GitLab wechseln zu müssen. Laut Ankündigung soll damit ein Schritt weg von rein Repository-basiertem Reasoning hin zu quellenübergreifender Fehleranalyse und Planung gelingen.

KI gegen Fehlalarme und für automatische Schwachstellenbehebung

In puncto Sicherheit setzt GitLab verstärkt auf KI-Hilfe. Eine neue Funktion zur KI-gestützten False-Positive-Erkennung soll Befunde der Secrets-Erkennung analysieren, bevor sie Entwicklerinnen und Entwickler erreichen. Laut GitLab identifiziert das System Test-Credentials, Beispielwerte und Platzhalter-Secrets und liefert dabei Erklärungen sowie Konfidenzwerte. Validierte Fehlalarme sollen sich per Bulk-Dismiss verwerfen lassen. GitLab betont, dass Präzisions- und Recall-Metriken erhoben werden, um die Erkennungsgenauigkeit kontinuierlich zu verbessern.

Die agentenbasierte Massenbereinigung von Schwachstellen geht einen Schritt weiter: Wenn dasselbe Verwundbarkeitsmuster an mehreren Stellen im Code auftritt, soll das System verwandte Befunde nach gemeinsamer Ursache gruppieren und konsolidierte Merge Requests (MR) erzeugen. Damit will GitLab auch der „Review-Müdigkeit“ entgegenwirken, die auftreten kann, wenn für jede einzelne Instanz ein separater MR erstellt wird. Die Funktion baut auf dem bestehenden SAST-Resolution-Flow auf.

Ergänzend dazu erweitert GitLab die automatische Behebung durch Dependency Bumping: Die Auto-Remediation soll konfigurierbare Schweregrade von LOW bis CRITICAL unterstützen und die Wahl zwischen Major-, Minor- und Patch-Versionssprüngen ermöglichen. Betroffene Abhängigkeiten lassen sich dann wahlweise in gruppierten oder einzelnen Merge Requests aktualisieren.

Schwachstellenmanagement über den Default-Branch hinaus

Eine laut GitLab häufig geforderte Funktion ist das Tracking von Schwachstellen auf Nicht-Default-Branches. Bisher erfasst die Plattform Verwundbarkeiten ausschließlich auf dem Default-Branch, was Organisationen mit langlebigen Release-Branches keine Sicht auf die Sicherheitslage ihres produktiven Codes bietet. Künftig sollen Teams konfigurieren können, welche Branches für das Schwachstellenmanagement verfolgt werden. Statusänderungen lassen sich lokal auf einzelne Branches oder global anwenden, und der Vulnerability Report erhält Branch-bezogene Filter.

Diese Branch-Awareness soll sich auch auf das Security-Dashboard und die Software Bill of Materials (SBOM) erstrecken: Schwachstellentrends, Abhängigkeitslisten und SBOM-Exporte – in den Formaten CycloneDX, JSON und SPDX – sollen künftig branch-spezifisch abrufbar sein.

Risikobasierte Richtlinien und neue Sicherheitsrolle

GitLab erweitert die Merge-Request-Genehmigungsrichtlinien um KEV- und EPSS-Filter. KEV (Known Exploited Vulnerabilities) und EPSS (Exploit Prediction Scoring System) eröffnen die Möglichkeit, Genehmigungspflichten nicht mehr allein am CVSS-Schweregrad festzumachen, sondern an der tatsächlichen Ausnutzbarkeit einer Schwachstelle. Sicherheitsteams können damit künftig Richtlinien formulieren, wie „Merge blockieren, wenn eine Abhängigkeit einen bekannten Exploit aufweist“.

Mit der neuen Security-Manager-Rolle adressiert GitLab ein Berechtigungsproblem: Bisher benötigten Sicherheitsteams Developer- oder Maintainer-Zugang für das Schwachstellenmanagement und erhielten damit weit mehr Rechte als nötig. Die neue Rolle erbt vom Reporter und ergänzt sicherheitsspezifische Berechtigungen – laut GitLab ein nicht-hierarchisches Modell, das die lineare Guest-to-Owner-Vererbung durchbricht.

CI/CD, DORA-Metriken und Project-level Epics

Für die CI/CD-Pipeline stehen nun Job-Inputs für manuelle Pipeline-Jobs parat. Bisher existieren Inputs nur auf Pipeline-Ebene; wenn sich die Parameter für einzelne manuelle Jobs ändern, ist ein vollständiger Pipeline-Neustart nötig. Künftig sollen individuelle Job-Parameter konfigurierbar sein, auch basierend auf Ergebnissen vorheriger Jobs. GitLab hofft, mit dieser Neuerung insbesondere Teams, die von Jenkins wechseln möchten, die Migration zu erleichtern.

Die DORA-4-Metrics-API soll eine vollständige Abdeckung aller vier DORA-Metriken – Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service – bieten. So sollen Entwicklerinnen und Entwickler programmatischen Zugriff für Dashboards, Executive Reporting und automatisiertes Alerting ohne Abhängigkeit von der GitLab-Oberfläche erhalten.

Mit Project-level Epics liefert GitLab eine der meistgewünschten Funktionen aus. Bisher sind Epics ausschließlich auf Gruppenebene verfügbar, was Teams laut GitLab dazu zwingt, unnötige Untergruppen anzulegen oder Milestones zweckzuentfremden. Künftig sollen Epics im Premium-Tier auch auf Projektebene nutzbar sein, inklusive Roadmap-, Board- und View-Unterstützung. GitLab beschreibt dies als dokumentierten Blocker für Migrationen.

Einen vollständigen Überblick aller Änderungen sowie mehr Details zu den einzelnen Aspekten in GitLab 18.9 liefern der Blogbeitrag sowie die Release Notes.

(map)

Im Rahmen des „India AI Impact Summit“ in Delhi gab OpenAI-Mitbegründer und CEO der Tageszeitung „The Indian Express“ eines seiner seltenen ausführlichen Interviews. Dabei waren auch Fragen aus dem Publikum zugelassen. Davor gab es jedoch ein Gespräch mit dem Geschäftsführer des Express, Anant Goenka. Er fragte unter anderem nach der von Altmans Konkurrent Elon Musk propagierten Idee von Rechenzentren im Weltall.

„Ganz ehrlich glaube ich, dass mit der gegenwärtigen Umgebung die Idee von Rechenzentren im All lächerlich ist.“ Wenn man nur die „einfachste Berechnung“ der Kosten des Transports ins All durchführe, zeige sich das. Und dann, so Altman, „Rede ja auch noch keiner davon, wie man eine kaputte GPU im All repariert. Und leider gehen die immer noch sehr oft kaputt.“ Es könne zwar sein, dass sich ein Rechenzentrum im Weltraum irgendwann rechnet, im laufenden Jahrzehnt sieht der OpenAI-Chef das jedoch noch nicht.

Enge Beziehungen zu Regierungen nötig

Weil schon auf der Erde die Infrastrukturkosten so hoch sind – Altman träumte einst von Billionen an Investitionen – sei auch eine enge Zusammenarbeit mit Regierungen für die KI-Branche nötig. Dabei sieht er zwar nach wie vor Konflikte, zu den Beziehungen auch mit der aktuellen US-Regierung sagt Altman jedoch: „Je besser sie sein kann, umso besser für uns alle.“ Auf dem Gipfel hatte er an anderer Stelle jedoch auch Regulierung gefordert.

Der Indian Express hat das gesamte Gespräch auch auf YouTube als Video veröffentlicht. Auf eine Frage an dieser Stelle nach den Kosten von KI für Training, insbesondere was Energie betrifft, ließ sich Altman zu einem merkwürdigen Vergleich hinreißen. Oft, so sagte er, werde eine Anfrage bei ChatGPT mit einer Anfrage bei einem Menschen verglichen. „Es braucht 20 Jahre Leben, und all das Essen, das man in dieser Zeit isst, bevor man schlau wird.“ Dazu komme noch die gesamte Evolution der Menschheit. Die bessere Frage sei, wieviel Kosten eine Anfrage bei einer KI gegenüber der bei einem Menschen an Energie benötige. „Und vielleicht hat KI da schon aufgeholt, wenn man die Energieeffizienz auf diese Art misst.“

(nie)

Die Nachricht schlägt in der Community der Onlineenzyklopädie derzeit hohe Wellen: Die englischsprachige Wikipedia hat beschlossen, den Archivdienst Archive.today sowie alle zugehörigen Domains wie archive.is und archive.ph mit sofortiger Wirkung zu sperren. Oberflächlich wirkt das wie ein technischer Streit über die Verlinkung von Quellen. Doch bei näherem Hinsehen entpuppt sich der Schritt als handfester Digitalskandal um Rachefeldzüge, manipulierte Zeitzeugnisse und den Missbrauch von Nutzerhardware für Cyberangriffe.

Hintergrund der Entscheidung ist ein Konflikt zwischen dem Betreiber von Archive.today und dem Blogger Jani Patokallio. Dieser hatte in seinem Webjournal Gyrovague.com über die verschleierte Identität der Hintermänner des Archivdienstes berichtet und dabei Verbindungen nach Russland sowie verschiedene Pseudonyme wie „Denis Petrov“ oder „Masha Rabinovich“ thematisiert. Die Reaktion des Betreibers von Archive.today sprengte jedoch jeden Rahmen einer üblichen Auseinandersetzung.

Gekaperte Browser für den Rachefeldzug

Wikipedia-Editoren stellten fest, dass Archive.today den Besuchern seiner Seite schädlichen Code unterjubelte. Über die Captcha-Abfragen des Dienstes wurde die Rechenkraft der ahnungslosen Nutzer gekapert, um eine Distributed-Denial-of-Service-Attacke (DDoS) gegen Patokallios Blog zu fahren. Ein solches Vorgehen verstößt fundamental gegen die Richtlinien der Wikimedia Foundation. Diese will ihre Leser nicht auf Webseiten schicken, die deren Computer für Angriffe missbrauchen.

Doch die Vorwürfe wiegen noch schwerer: Im Zuge der internen Untersuchungen entdeckten die Wikipedia-Autoren, dass Archive.today offenbar die Integrität seiner Snapshots korrumpiert hat. Beweise deuten darauf hin, dass der Betreiber gezielt Inhalte in archivierten Seiten veränderte, um Patokallio zu diskreditieren. So wurde etwa in archivierten Blogposts der Name einer anderen Person durch den Namen des verhassten Bloggers ersetzt.

Für ein Onlinelexikon, dessen Kernprinzip die Verifizierbarkeit und Belegbarkeit durch unveränderliche Quellen ist, stellen solche Vorgänge den Super-GAU dar. Wenn ein Archivdienst anfängt, die Geschichte nach eigenem Gutdünken umzuschreiben, verliert er seine Daseinsberechtigung als Referenzquelle.

Manipulation rüttelt an Wikipedias Pfeilern

In internen Diskussionen äußerten sich die Wikipedia-Editoren schockiert. Ein Archiv, das als neutraler Zeuge fungieren soll, dürfe nicht als Waffe in persönlichen Fehden eingesetzt werden. Befürworter von Archive.today hielten dagegen, der Service sei aufgrund seiner Fähigkeit, Paywalls zu umgehen, unverzichtbar. Doch dieses Argument verfing angesichts der Sicherheitsrisiken und der nachgewiesenen Manipulationen nicht mehr. Die Community kam zum Schluss, dass die Zuverlässigkeit der Quellen Vorrang vor der Bequemlichkeit beim Umgehen von Bezahlschranken hat.

Die Dimension des Vorhabens ist gewaltig. Schätzungen zufolge finden sich auf rund 400.000 Wikipedia-Seiten mehr als 695.000 Links, die auf Archive.today verweisen. Sie sollen nun sukzessive entfernt oder durch sicherere Alternativen wie Internet Archive (archive.org) oder Ghostarchive ersetzt werden. An die Editoren ging der Appell, Links manuell zu prüfen und – sofern die Originalquelle noch online ist – den Archivlink komplett zu löschen oder auf seriöse Anbieter umzustellen. Dabei betonen die Wikipedianer ausdrücklich, dass das renommierte und in den USA ansässige Internet Archive in keiner Verbindung zu den Vorfällen rund um Archive.today steht.

Drohungen und Suche nach Alternativen

Der Fall wirft auch ein Schlaglicht auf die intransparenten Strukturen hinter vielen „Grauzonendiensten“ im Netz. Archive.today galt jahrelang als nützliches Werkzeug für Journalisten und Faktenprüfer. Doch die Identität der Betreiber blieb stets im Dunkeln. Selbst das FBI soll bereits versucht haben, über den Registrar Tucows Informationen über die Hintermänner zu erzwingen – bislang ohne Erfolg.

Die nun bekannt gewordenen Drohungen gegen Patokallio, die laut Berichten sogar die Erstellung gefälschter Dating-Profile und KI-generierter Pornografie unter seinem Namen beinhalteten, unterstreichen das aggressive Gebaren der Macher der Seite.

Für Archive.today bedeutet die Verbannung aus dem Wikipedia-Universum einen schweren Reputationsverlust. Das Onlinelexikon selbst sieht das Einschreiten als schmerzhaften, aber notwendigen Reinigungsprozess an. Die Wikimedia Foundation erklärte vor wenigen Tagen, dass sie im Zweifel auch direkt eingreifen würde, falls die ehrenamtlichen Editoren keine Einigung erzielen sollten. Sie hielt die Sicherheit der User durch die infizierten Captcha-Seiten unmittelbar bedroht. Könnte dieser Vorfall nun die Geburtsstunde eines eigenen Wikimedia-Archivdienstes sein? Blogger Patokallio hofft zumindest genau darauf, wie er Ars Technica erklärte.

(nb)