Das neue Release GitLab 19.1 stattet die Entwicklungsplattform mit zahlreichen neuen Features aus, darunter die Erkennung falsch positiver Secrets mithilfe von GitLab Duo Agent Platform. Den KI-Dienst GitLab Duo können Admins oder Besitzer von Top-Level-Gruppen darüber hinaus zentral für alle Projekte einschalten, sodass andere Personen ihn nicht deaktivieren können.

Secrets-Erkennung per KI

Die Secret False Positive Detection ist ein Feature der GitLab Duo Agent Platform, einer Orchestrierungsplattform für KI-Agenten. Die neue Funktion zur Secrets-Erkennung ist per Opt-in nun für GitLab-Ultimate-Kunden allgemein verfügbar. Wie das GitLab-Team ausführt, führt die Erkennung vermeintlicher Secrets nicht nur zu einem Zeitverlust, sondern kann auch „Alert-Müdigkeit“ und einen Vertrauensverlust in Scanergebnisse nach sich ziehen sowie von echten Sicherheitsrisiken ablenken. Dort setzt das neue Feature an: Bei einem Security-Scan analysiert es mithilfe von KI für jede Secret Detection Vulnerability, die als kritisch oder mit hohem Schweregrad erkannt wurde, die Wahrscheinlichkeit dafür, dass es sich um einen falsch positiven Fund handeln könnte. Das Ergebnis erscheint dann im Vulnerability-Bericht.

Wer die neue Analysefunktion nutzen möchte, soll laut GitLab zuerst einen Blick in die Datenrichtlinien seines Unternehmens werfen, denn die Informationen über die Vulnerabilität mitsamt deren Codekontext werden an Large Language Models gesendet.

Zentrale Kontrolle über GitLab Duo

Ein weiteres Update betrifft die allgemeine Verwendung von GitLab Duo. Der KI-Dienst lässt sich nun für alle Projekte in einer kompletten Instanz oder Top-Level-Gruppe auf „always on“ setzen. Dazu navigieren Admins einer Instanz (bei GitLab Self-Managed) oder Owner einer Top-Level-Gruppe (auf GitLab.com) zu den GitLab-Duo-Einstellungen und setzen GitLab Duo availability auf Always on. Dann lässt sich GitLab Duo in ersterem Fall durch Besitzer von Gruppen, Untergruppen oder Projekten nicht mehr deaktivieren; in zweiterem Fall betrifft das Besitzer von Untergruppen und Projekten. Ein „always off“-Modus war bisher bereits verfügbar.

Alle Neuerungen in GitLab 19.1, von denen sich auch einige weitere um künstliche Intelligenz drehen, sind den Release Notes zu entnehmen.

(mai)

Google setzt seine im August 2025 angekündigten Pläne zur Verifizierung von Apps und Entwicklern für Android-Geräte weiter fort. Am Donnerstag, den 18. Juni, hat Google im Android Developers Blog ein Update zur Entwicklerüberprüfung für Android veröffentlicht, deren Einführung für später in diesem Jahr geplant ist und bis ins Jahr 2027 andauern wird. Das Unternehmen nennt zudem erste App-Stores, die am Programm teilnehmen, und einen Zeitplan für wichtige Funktionen, wie den „Advanced Flow“ zur Umgehung der Verifizierung für nicht verifizierte Apps.

Ablauf wie geplant

Im Blogbeitrag bestätigt Matthew Forsythe, Director of Product Management, Google Play Developer Experience & Chief Product Explainer, dass das Entwickler-Verifizierungssystem wie vorgesehen am 30. September in Betrieb gehen soll. Die Einführung sei zunächst auf Länder mit einer hohen Zahl an App-Betrugsfällen beschränkt, zu diesen gehören Brasilien, Indonesien, Singapur und Thailand.

Google hat im März seine neue Entwicklerkonsole veröffentlicht, die externen Entwicklern ermöglicht, gegen eine einmalige Kontogebühr von 25 US-Dollar ihre Identität und Apps vorzeitig zu verifizieren. Seitdem haben Entwickler Millionen von Apps registriert, die nahezu alle Installationen auf Google Play sowie einen Großteil der Installationen außerhalb von Google Play abdecken, so Google.

Start in ausgewählten Ländern

Ab dem 30. September werden die Maßnahmen der Entwicklerüberprüfung in Brasilien, Indonesien, Singapur und Thailand eingeführt. Damit blockiert Google die Installationen von unbekannten Entwicklern. Diese App-Stores sind zum Start dabei:

• Google (Google Play)
• Honor (HONOR App Market)
• OPlus (OPPO App Market)
• Samsung (Galaxy Store)
• Transsion (Palm Store)
• Vivo (V-Appstore)
• Xiaomi (GetApps)

Vor dem Stichtag im September wird Google im August die sogenannten „Limited Distribution“-Konten einführen. Dieses Android-Entwicklerkonto richtet sich an Studenten, Hobbyentwickler und Lernende und ermöglicht es ihnen, ihre Apps auf bis zu 20 Geräte zu übertragen, ohne dass bei Google ein Ausweis vorgelegt oder eine Gebühr entrichtet werden muss.

Ferner wird dann auch eine neue Android-Developer-Console-API weltweit eingeführt, wie auch der „Advanced Flow“ für die Installation von Apps von nicht verifizierten Entwicklern. Dieser Ablauf erlaubt das Sideloading nicht verifizierter Apps, erfordert aber den Neustart des Geräts und eine 24-stündige Wartezeit. Der Advanced Flow richtet sich Google zufolge primär an erfahrene Nutzer. Dieses Verfahren muss laut Google nur einmal durchgeführt werden und kann auf ein neues Gerät übertragen werden.

Eine Ausnahme gibt es ebenfalls: Wer seine Apps über die Android Debug Bridge (ADB) am PC installiert, ist vom Advanced Flow nicht betroffen und muss auch keine 24 Stunden warten, so soll es in Zukunft auch bleiben.

Automatischer Systemdienst ab Android 8

Überdies wird Google einen neuen Systemdienst namens „Android Developer Verifier“ (com.google.android.verifier) auf Geräten mit Android 8 und neuer einführen. Dieser Dienst wird offenbar serverseitig ohne das Zutun der Nutzer über die Google-Play-Dienste eingespielt. Nach der Installation „überprüft der Dienst, ob eine App bei einem verifizierten Entwickler registriert ist“. Die Einführung dieses Hintergrunddienstes beginnt im Juni.

Google führt außerdem die Android-Developer ID Status API ein, um die App-Registrierung zu vereinfachen. Damit können Entwickler „Apps in großen Mengen oder direkt über [ihre] CI/CD-Pipelines (Continuous Integration and Deployment) registrieren“.

Der von Google genannte Zeitplan nach dem 30. September ist nur grob skizziert. Das Unternehmen schreibt lediglich, dass der Verifizierungsprozess für Entwickler bis „2027 und darüber hinaus“ zu einer weltweit geltenden Richtlinie gemacht wird.

Gegenwind aus der Open-Source-Community

Derweil laufen unabhängige Entwickler und Open-Source-App-Stores wie F-Droid seit der Ankündigung der Entwickler-Verifizierung Sturm gegen Googles Pläne. Sie sagen unter anderem, dass die neuen Regeln Google zum Gatekeeper für alle Android-Apps machen würde.

In einem vor einigen Monaten veröffentlichten offenen Brief werfen Akteure und Unternehmen aus der Open-Source-Szene sowie aus der Zivilgesellschaft Google weiter vor, dass so künstliche Zugangshürden geschaffen würden, und befürchten Datenschutzrisiken durch eine zentrale Datenbank von Android-Entwicklern in der Hand des Unternehmens. Ferner könne es zu Wettbewerbsverzerrungen kommen, wenn Google über eine solche Registrierung Daten sammelt, wer welche Apps anbietet.

(afl)

Databricks stellt mit Lakehouse//RT eine Engine für Echtzeitanalysen auf Delta-Lake- und Apache-Iceberg-Tabellen vor. Anwendungen und KI-Agenten sollen dadurch direkt auf Daten im Lakehouse zugreifen können, ohne dass zusätzliche Serving-Systeme oder spezialisierte Echtzeitdatenbanken erforderlich sind.

Der Markt für Echtzeitanalysen wird bislang von spezialisierten Systemen wie ClickHouse, Apache Pinot oder Apache Druid geprägt. Unternehmen setzen diese häufig zusätzlich zu ihren Analyseplattformen ein, um Anwendungen, Dashboards oder KI-Systeme mit niedrigen Antwortzeiten zu versorgen. Die dafür erforderlichen Datenkopien und Synchronisationsprozesse erhöhen jedoch Komplexität und Kosten.

Mit Lakehouse//RT will Databricks diese Architektur vereinfachen. Die neue Engine führt Abfragen mit Latenzen im Millisekundenbereich direkt auf Delta-Lake- und Apache-Iceberg-Tabellen aus. Eine separate Echtzeit-Serving-Schicht soll dadurch entfallen. Die Technologie ist ab sofort als Beta verfügbar. Databricks begründet den Schritt unter anderem mit dem zunehmenden Einsatz von KI-Agenten. Diese greifen nach Vorstellung des Herstellers kontinuierlich auf Unternehmensdaten zu und benötigen dafür aktuelle Informationen mit möglichst geringer Latenz. Lakehouse//RT soll deshalb Daten direkt aus dem Lakehouse bereitstellen, ohne sie zuvor in zusätzliche Systeme zu kopieren.

Echtzeitabfragen direkt auf Delta- und Iceberg-Tabellen

Nach Angaben des Herstellers richtet sich Lakehouse//RT an Anwendungen mit hohen Parallelitätsanforderungen. Dazu zählen interaktive Dashboards, kundenseitige Anwendungen sowie KI-Agenten. Die Engine greift direkt auf verwaltete Delta-Lake- und Apache-Iceberg-Tabellen zu und soll auch bei einer großen Zahl gleichzeitiger Anfragen niedrige Antwortzeiten ermöglichen. Bislang setzen viele Unternehmen für solche Szenarien auf zusätzliche Echtzeit-Serving-Systeme.

Databricks argumentiert, dass diese Architektur zu Datenkopien, separaten Governance-Strukturen und zusätzlichem Betriebsaufwand führt. Lakehouse//RT soll diese Zwischenschicht ersetzen und Analysen unmittelbar auf den im Lakehouse gespeicherten Daten ermöglichen.

Technische Grundlage von Lakehouse//RT ist Reyden, eine neue Rechen-Engine mit vollständig asynchronem Ausführungsmodell. Nach Herstellerangaben erreicht sie Antwortzeiten von rund 10 Millisekunden bei kleineren Datensätzen sowie unter 100 Millisekunden bei größeren Datenbeständen. Bei Standard-Analyse-Benchmarks nennt Databricks Latenzen von unter 100 Millisekunden bei 12.000 Abfragen pro Sekunde. Gegenüber bestehenden Echtzeit-Serving-Stacks sollen Kunden Leistungssteigerungen um den Faktor 16 gemessen haben. Welche Datensätze und Abfragetypen den Benchmarks zugrunde liegen, erläutert der Hersteller bislang nicht im Detail. Anders als viele auf niedrige Latenzen optimierte Systeme sei Reyden nicht nur für einfache Schlüssel-Wert-Abfragen ausgelegt, sondern könne auch komplexere analytische Abfragen verarbeiten.

Governance im bestehenden Lakehouse

Lakehouse//RT integriert sich in den Unity Catalog von Databricks. Richtlinien, Berechtigungen und Audit-Funktionen gelten damit auch für Echtzeitabfragen. Zusätzliche Governance-Schichten oder proprietäre Datenformate sollen nicht erforderlich sein. Nach Angaben des Herstellers genügt es, bestehende Delta- oder Iceberg-Tabellen auszuwählen, um innerhalb weniger Minuten auf Live-Daten zuzugreifen. Separate CDC- oder Synchronisationspipelines seien nicht notwendig.

Databricks ordnet Lakehouse//RT als Erweiterung seiner bestehenden Engine-Familie ein. Neben Spark für Data Engineering und Data Science sowie Photon für analytische Workloads soll die neue Engine den Bereich niedriger Latenzen abdecken.

Erste Referenzkunden und offene Fragen

Als Referenzkunden nennt Databricks unter anderem Cisco und den Werbetechnologieanbieter Magnite. Cisco berichtet von einer fünffachen Verbesserung der Antwortzeiten bei der Bedrohungssuche auf Live-Daten. Magnite gibt Antwortzeiten von unter 200 Millisekunden für zentrale Dashboard-Abfragen an. Ob Lakehouse//RT tatsächlich spezialisierte Echtzeitdatenbanken ersetzen kann, bleibt offen. Die bislang veröffentlichten Leistungsdaten stammen ausschließlich von Databricks und ausgewählten Referenzkunden. Unabhängige Benchmarks oder direkte Vergleiche mit anderen Echtzeitsystemen liegen bislang nicht vor.

Sollte sich die Architektur in der Praxis bewähren, könnte sie einen weiteren Schritt in Databricks’ Strategie markieren, Analyse-, Transaktions- und KI-Workloads auf einer gemeinsamen Plattform zusammenzuführen. Der Beta-Status zeigt allerdings auch, dass sich dieser Anspruch erst noch im produktiven Einsatz beweisen muss. Parallel dazu kündigt Databricks weitere Schritte an, bislang getrennte operative und analytische Datenarchitekturen enger miteinander zu verzahnen.

(axk)