Connect with us

Künstliche Intelligenz

GitLab 18.9: Eigene KI-Modelle und KI-gestützte Sicherheitsfeatures


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.

Weiterlesen nach der Anzeige

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.

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.

Weiterlesen nach der Anzeige

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.

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.

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.

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.

Lesen Sie auch

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)



Source link

Künstliche Intelligenz

Nach 20 Jahren: Wikinews wird zum 4. Mai in Lese-Modus versetzt


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Die 31 Sprachversionen des Wikipedia-Schwesterprojekts „Wikinews“ werden nach mehr als zwei Jahrzehnten geschlossen. Nach einem Beschluss des Stiftungskuratoriums der Wikimedia Foundation soll das Projekt zum 4. Mai in einen reinen Lese-Modus versetzt werden, da es die Erwartungen der Stiftung nicht erfüllt habe. Die Inhalte seien zudem redundant im Vergleich zu den oft in Echtzeit aktualisierten Informationen in Wikipedia-Artikeln.

Weiterlesen nach der Anzeige

Der Schritt folgt auf eine längere Phase interner Diskussionen: Eine Task Force der Stiftung hatte bereits 2025 empfohlen, alle Wikinews-Ausgaben zu schließen. Als Gründe nannte sie unter anderem eine geringe Nutzung durch Leser, große Lücken in der thematischen Abdeckung und Zweifel an der langfristigen Relevanz. Die Empfehlung löste eine Debatte in der Community aus, ob das Wikinews-Projekt eventuell mit strukturellen Änderungen weitergeführt werden könne.

Wikimedia hatte Wikinews 2004 gestartet, um eine offene Plattform für sogenannten Graswurzeljournalismus unter Creative-Commons-Lizenzen zu schaffen. Trotz anfänglicher Aufmerksamkeit konnte das Wikinews-Projekt nicht an die Nutzungszahlen der anderen Wikimedia-Projekte anknüpfen. Bereits 2018 äußerte die damalige Wikimedia-Geschäftsführerin Katherine Maher im im Interview mit heise online Zweifel an der Idee, mehr Ressourcen in die Plattform zu investieren. Der Wikipedia-Mitgründer Jimmy Wales widmete sich damals bereits anderen journalistischen Projekten.

Zuletzt belief sich die Zahl der aktiven Autorinnen und Autoren in allen Wikinews-Sprachversionen auf etwas über 700. Die deutsche Sprachversion von Wikinews enthält heute über 14.000 Artikel und gehörte im internationalen Vergleich zu den aktivsten Ausgaben. Die weiterhin verfügbaren Artikel mit einer Gesamtgröße von knapp 120 MByte können auch gebündelt heruntergeladen werden.


(hag)



Source link

Weiterlesen

Künstliche Intelligenz

IGEL holt Container, KI und mehr in die Thin-Client-Welt


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Im Rahmen ihrer Hauskonferenz Now & Next setzt die deutsche Firma IGEL Technologies neue Impulse rund um ihr Thin-Client-Angebot. Während das Unternehmen bisher vor allem für das eigene Betriebssystem IGEL OS bekannt ist, sollen künftig Container und die Laufzeitumgebungen Docker und Podman auf dem Thin Client eine Rolle spielen. Laut den Ankündigungen betritt der Software-Hersteller gleich eine Reihe neuer Gebiete, sowohl auf Betriebssystemebene als auch im Hinblick auf neue Marktsegmente wie Operational Technology (OT).

Weiterlesen nach der Anzeige

IGEL OS basiert auf Linux im Zusammenspiel mit Mechanismen wie UEFI Secure Boot. Die typische Anwendung liegt in den Bereichen VDI (Virtual Desktop Infrastructure), DaaS (Desktop as a Service) sowie Browser-basierten Anwendungen. Hardwareseitig blieb das bislang x86-Anwendern vorbehalten. Nun möchte IGEL zunächst auch den Einsatz von Containern auf dem Thin Client ermöglichen. Anwender können dazu mit den IGEL Managed Containers (IMC) zunächst Podman als Laufzeitumgebung nutzen.

Damit das funktioniert, müssen IGEL-Admins aber einige Konfigurationen in der Universal Management Suite (UMS) vornehmen. Dazu gehört das Freischalten der benötigten Repos von Container-Abbildern; des Weiteren das Freischalten für Benutzer beziehungsweise Endgeräte. Letzteres bezieht sich auf die tatsächlichen Container-Instanzen. Laut Matthias Haas, CTO bei IGEL Technologies, geht es momentan nur um einzelne lokale Container – entweder auf dem Desktop oder im Edge-Bereich.

Wie aber passen Container in das Konzept von Thin Clients, auf denen lokal keine wichtigen Daten vorliegen? IGEL bedient sich hier eines kleinen Kunstgriffs. Die Container-Daten liegen auf einer separaten verschlüsselten LVM-Partition (Logical Volume Manager). Damit bleibt das IGEL OS „sauber“ und „zustandslos“. Für diese LVM-Partition gibt es eine zentrale Verwaltung der Schlüssel. So lässt sich das Ausführen von Containern auf dem Endgerät erlauben oder auch verbieten. Das Gleiche gilt für den Zugriff auf die entsprechenden Daten. Die IGEL Managed Containers will das Unternehmen noch im Sommer dieses Jahres zur Verfügung stellen.

Mit dem IGEL Managed Hypervisor (IMH), einem KVM-basierten Hypervisor, will IGEL Technologies künftig auch unterhalb der Betriebssystemebene Fuß fassen. Der IMH erfüllt gleich mehrere Aufgaben und dient als Basis für neue Thin-Client-Funktionen. Dazu zählt unter anderem das Freischalten von beliebigen einzelnen Windows-Anwendungen für den IGEL-Desktop. Im Hintergrund läuft eine virtuelle Maschine mit dem Microsoft-Betriebssystem – angebunden über das RDP-Protokoll (Remote Desktop Protocol). Die Daten der VM liegen – analog zu den IGEL Managed Containers – auf einer separaten verschlüsselten LVM-Partition. Die Verwaltung des Gesamtkonstrukts erfolgt ebenfalls über die UMS. Dazu gehören auch das Implementieren von E/A-Richtlinien, das Abschalten von Netzwerk oder anderen Schnittstellen, sowie das Umleiten von Daten über Proxies oder Firewalls. All das geschieht außerhalb der virtuellen Maschine und erfordert keine Neukonfiguration.

Ein weiterer Anwendungsfall für IMH liegt im Bereich Operational Technology (OT). Hier geht es um das Weiterverwenden von veralteten Betriebssystemen oder das Nachbilden von Hardware, die es physisch nicht mehr gibt. Matthias Haas zufolge benötigen solche alten OT-Systeme nur sehr selten eine Netzwerkverbindung, sodass sich beispielsweise auch der Einsatz von Windows XP weniger unsicher gestaltet. Außerdem erlaubt die Virtualisierung auch bessere Möglichkeiten für Sicherung und Wiederherstellung des OT-Systems. Der IMH ist bereits seit 2025 verfügbar. Basierend auf den Rückmeldungen der Kunden entwickelt IGEL Technologies den Hypervisor kontinuierlich weiter. Neu hinzugekommen ist nun die Möglichkeit, eine Sicherungskopie zu erstellen und ein Endgerät damit komplett neu zu installieren. Zeitgesteuerte Sicherungen, die Verwaltung sogenannter Goldener Abbilder (Golden Images) oder die (Neu-)Installation von vielen Endgeräten sind geplant.

Weiterlesen nach der Anzeige

Gemeinsam mit Qualcomm arbeitet IGEL Technologies zudem an einer Portierung der Thin-Client-Software auf ARM. Die Wahl fiel auf Qualcomm weil dessen Chips oft in Industriezweigen wie Automotive oder dem Gesundheitswesen zum Einsatz kommen. Mit der Unterstützung von ARM stärkt IGEL Technologies so seine Ambitionen im OT-Bereich. Konkret geht es im ersten Schritt um Geräte mit einem Bildschirm oder Zugriff per Browser, später sollen auch Tablets folgen. Weitergehende Informationen finden sich auch in der Ankündigung zu IGEL OS for ARM aus dem vergangenen Herbst.


(map)



Source link

Weiterlesen

Künstliche Intelligenz

Studio Display XDR für Ärzte: Apple bekommt Zulassung von US-Gesundheitsaufsicht


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Mediziner, die Apple-Technik in der Praxis einsetzen, können das kürzlich erschienene Studio Display XDR in einem ersten Markt auch professionell nutzen: Der Bildschirm bekam in den Vereinigten Staaten nun die Zulassung der Food and Drug Administration (FDA) zum Einsatz in der Radiologie. Damit kann der Screen in der Diagnostik verwendet werden. Laut Apple-Marketingchef Greg Joswiak muss dazu auf dem Mac macOS 26.4 laufen. „Das heißt, dass Radiologen jetzt den weltbesten Pro-Bildschirm im Bereich der allgemeinen Radiologie einsetzen können.“ Es sei „fantastisch, diese Überschneidung von Gesundheit und Technik zu sehen“, lobte er.

Weiterlesen nach der Anzeige

Das Studio Display XDR ist einer von zwei neuen Bildschirmen, die Apple im März vorgestellt hatte. Während das Studio Display 2026 nur minimale Verbesserungen wie Thunderbolt 5 erhielt, kommt das Studio Display XDR mit bis zu 2000 Lux, 120 Hertz und 2304 Mini-LEDs als Backlight. Diese Funktionen sind es auch, die die medizinische Nutzung erlauben. So wird der DICOM-Standard für die Anzeige von Inhalten aus bildgebenden Verfahren ebenso unterstützt wie eine Kalibrierung mit Medical-Imaging-Calibrator.

Günstig ist das Studio Display XDR zwar mit mindestens 3399 Euro (ohne Ständer und mit VESA-Mount) nicht, doch im Wettbewerb mit professionellen Bildschirmen für den medizinischen Bereich ist dieser Preis geradezu ein Schnäppchen – besonders wenn man 5K-Auflösung und Helligkeit einberechnet. Allerdings ist der Screen mit 27 Zoll relativ klein geraden, das Pro Display XDR, zuletzt völlig veraltet, hatte Apple mit seinen knapp 32 Zoll ersatzlos aus dem Programm gestrichen.

Apple hatte bereits zuvor mitgeteilt, dass man DICOM-Fähigkeit und medizinische Kalibrierung anstrebt, mit der FDA-Zulassung sind sie nun offiziell. Für DICOM bietet macOS in der aktuellen Version passende Presets, die sich durch die Systemeinstellungen auswählen lassen. Apple bereitet offenbar auch eine Zertifizierung in weiteren Ländern vor, darunter vermutlich Europa. Auch hier könnte der Konzern mit dem Screen im Radiologie-Bereich punkten.

Das Studio Display XDR spielt seine Vorteile allerdings nur mit passenden Macs aus. So sind nur Apple-Silicon-Geräte überhaupt kompatibel, 120 Hertz unterstützen nur neuere Macs beziehungsweise bessere ausgestattete Maschinen. M1, M1 Pro, M1 Max, M1 Ultra, M2 und M3 stellen nur 60 Hertz dar.

Weiterlesen nach der Anzeige


(bsc)



Source link

Weiterlesen

Beliebt