Das Node.js-Team diskutiert derzeit darüber, den Workflow für die Flut an eingereichten, LLM-generierten Sicherheitsmeldungen zu ändern. Ideen sind, die Meldungen öffentlich zu bearbeiten und mit künstlicher Intelligenz vorzusortieren.

Das Team hat das Problem jetzt auf die Agenda des nächsten Treffens der Security Working Group am 7. Juli gesetzt. Der Initiator Rafael Gonzaga schreibt, dass alle bisherigen Maßnahmen nicht geholfen haben: „Wir sind nach wie vor überlastet.“

Daher schlägt er vor, die eingereichten Meldungen zu veröffentlichen und als Pull Requests (PR) abzuarbeiten. Bei den Einreichungen handelt es sich oft nur um Bugs, die auch gefixt gehören, aber weniger um wirkliche sicherheitsrelevante Lücken. Außerdem kommen so viele gleichartige Meldungen an, die quasi jeder mit LLM erzeugen kann: „Diese Funde sind praktisch eh schon öffentlich.“ Als PR kann sich die Community darum kümmern und das Kernteam ist entlastet.

Eine Vorsortierung durch KI könnte nur die wirklich ernsthaften Lücken erkennen und nicht öffentlich an das Sicherheitsteam zur Bearbeitung weiterleiten.

Gegenstimmen geben zu bedenken, dass der Vorschlag die Masse an Sicherheitsreports durch eine Masse an PRs ersetzt, die auch vom Kernteam geprüft werden müssen. Außerdem könnten die veröffentlichten Lücken Hacker anziehen, „als kostenlose Quelle für Ideen für automatisierte Attacken.“ Daher schlagen andere Maintainer vor, nicht die komplette Öffentlichkeit einzubeziehen, aber den Kreis auf alle Mitarbeitenden (collaborators) zu erweitern.

Kampf gegen den AI-Slop

Wie viele andere Projekte kämpft Node.js mit AI Slop und hat im April bereits das Bug-Bounty-Programm zur Belohnung von Warnungen gestrichen. Auch zu solchen Maßnahmen waren andere Projekte bereits gezwungen. Das hat laut Gonzaga aber keine Erleichterung gebracht, da es den Einreichenden eher um den Ruhm als Autor auf einer offiziellen CVE-Warnmeldung zu erscheinen geht, als um Geld.

Auch andere Maßnahmen führten nicht zum Erfolg: höhere Hürden bei der Reporting-Plattform HackerOne, engere Relevanzkriterien und automatisiertes Schließen von Reports minderer Qualität. Letzteres hat sogar dazu geführt, dass mehr Meldungen bei der Mutter OpenJS landeten. „Bald wird auch dieses Team überlastet sein“, schließt Gonzaga.

(who)

Die freie Embedded-Datenbank LMDB (Lightning Memory-Mapped Database) hat Version 1.0 erreicht. Mit dem ersten Major-Release dokumentieren die Entwickler die API und das Verhalten der Bibliothek neu und stellen eine aktualisierte Dokumentation bereit. Für bestehende Anwendungen gibt es einen eigenen Migrationsleitfaden von der 0.9-Serie.

LMDB ist eine in Anwendungen eingebettete Key/Value-Datenbankbibliothek für lokale Datenhaltung. Sie richtet sich an Entwickler, die eine transaktionssichere Datenbank ohne separaten Serverprozess benötigen, etwa für Verzeichnisdienste, Caches oder Metadaten. Anders als klassische Datenbanksysteme lädt LMDB Daten nicht in einen eigenen Puffer-Cache, sondern bildet die komplette Datenbank per Memory Mapping in den virtuellen Adressraum des Prozesses ab. Lesezugriffe erfolgen dadurch direkt auf die gemappten Speicherbereiche, ohne zusätzliche Speicherallokationen oder Kopieroperationen.

Memory Mapping statt Datenbank-Cache

Das Grundprinzip von LMDB bleibt auch mit Version 1.0 unverändert. Die Bibliothek verwendet einen B-Baum als Datenstruktur und überlässt das Caching vollständig dem Betriebssystem. Da Datensätze direkt aus dem Speicherabbild gelesen werden, entfallen Zwischenschritte wie malloc() oder memcpy() beim Auslesen von Daten. Das reduziert den Verwaltungsaufwand und kann insbesondere bei leseintensiven Workloads die Leistung steigern. Grundlage dafür ist die Memory-Mapping-Funktion des Betriebssystems, bei der Dateiinhalte transparent in den virtuellen Speicher eingeblendet werden.

Auch das Transaktionsmodell bleibt erhalten. LMDB bietet ACID-Eigenschaften und setzt auf Multi-Version Concurrency Control (MVCC). Neue Daten werden per Copy-on-Write geschrieben, sodass bereits vorhandene Seiten niemals überschrieben werden. Ein Leser sieht dadurch stets einen konsistenten Datenbestand, während Schreibvorgänge parallel vorbereitet werden können. Ein typisches Beispiel ist ein Dienst, der kontinuierlich Konfigurationsdaten ausliest, während ein Verwaltungswerkzeug Änderungen schreibt: Leser arbeiten ohne Sperren weiter und werden durch den Schreibvorgang nicht blockiert.

Ein Schreiber, viele Leser

Das Nebenläufigkeitsmodell von LMDB unterscheidet sich von vielen anderen Datenbanken. Beliebig viele Prozesse oder Threads können gleichzeitig lesen, Schreibtransaktionen werden dagegen vollständig serialisiert. Zu jedem Zeitpunkt darf nur eine Schreibtransaktion aktiv sein. Dadurch schließt das System Deadlocks zwischen konkurrierenden Schreibern aus. Leser blockieren Schreiber nicht, ebenso wenig müssen Leser auf laufende Schreibvorgänge warten.

Die Entwickler verzichten außerdem bewusst auf ein Write-Ahead-Log oder ein Append-only-Protokoll. Statt regelmäßig Logdateien zusammenzuführen oder Datenbanken zu komprimieren, verwaltet LMDB freie Seiten innerhalb der Datenbank selbst und verwendet sie für spätere Schreibvorgänge erneut. Dadurch wächst die Datenbank im Normalbetrieb nicht unbegrenzt an, wie es bei logbasierten Verfahren ohne Wartung passieren kann.

Hinweise für den Betrieb

Die Release-Notes auf GitHub sowie die Dokumentation weisen auf einige Einschränkungen hin: Lange laufende Lesetransaktionen können verhindern, dass bereits freigegebene Seiten wiederverwendet werden. Dadurch kann die Datenbankdatei unnötig anwachsen. Entwickler sollten deshalb lang andauernde Transaktionen vermeiden und abgebrochene Prozesse regelmäßig auf verwaiste Reader-Einträge prüfen. Dafür stehen unter anderem die Funktion mdb_reader_check sowie das Werkzeug mdb_stat zur Verfügung.

Nicht empfohlen wird außerdem der Einsatz auf Netzwerkdateisystemen. Da LMDB auf Memory Mapping sowie Dateisperren des Betriebssystems setzt, können dort Synchronisationsprobleme auftreten. Auch das gleichzeitige mehrfache Öffnen derselben Datenbank innerhalb eines Prozesses gilt laut Dokumentation als problematisch.

(fo)

MongoDB stellt seine Volltextsuche und Vektorsuche nun allgemein für selbst verwaltete Installationen bereit. Die Funktionen sind sowohl für MongoDB Enterprise Advanced als auch für die Community Edition verfügbar. Entwickler können damit Suchabfragen, semantische Suche und hybride Suchverfahren direkt in ihrer Datenbank nutzen, ohne eine separate Suchplattform mit eigener Datensynchronisation betreiben zu müssen.

MongoDB ist eine dokumentenorientierte NoSQL-Datenbank, die JSON-ähnliche BSON-Dokumente speichert. Sie wird häufig für Anwendungen mit flexiblen Datenmodellen eingesetzt und ist sowohl als Cloud-Dienst MongoDB Atlas als auch für den Eigenbetrieb erhältlich. Bislang standen einige der erweiterten Suchfunktionen vor allem in Atlas zur Verfügung.

Volltext-, Vektor- und Hybridsuche aus einer Hand

Laut der Ankündigung erreichen die Suchfunktionen in selbst verwalteten Umgebungen nun Funktionsparität mit MongoDB Atlas. Unterstützt werden unter anderem die Aggregationsstufen $search, $searchMeta, $vectorSearch, $rankFusion und $scoreFusion. Dadurch lassen sich klassische Volltextsuche und semantische Vektorsuche in einer gemeinsamen Abfrage kombinieren.

Während die Volltextsuche Dokumente anhand von Schlüsselwörtern und sprachabhängigen Merkmalen durchsucht, vergleicht die Vektorsuche numerische Repräsentationen von Inhalten, sogenannte Embeddings. Dadurch lassen sich auch inhaltlich ähnliche Dokumente finden, selbst wenn sie andere Begriffe verwenden. Eine hybride Suche verbindet beide Verfahren und kann so sowohl exakte Treffer als auch semantisch passende Ergebnisse liefern. Solche Ansätze kommen unter anderem in RAG-Systemen (Retrieval-Augmented Generation) zum Einsatz, bei denen Sprachmodelle externe Wissensquellen in ihre Antworten einbeziehen.

KI-Funktionen direkt in der Datenbank

MongoDB integriert außerdem eine automatische Erzeugung von Embeddings auf Basis der Modelle von Voyage AI. Entwickler müssen die Vektoren damit nicht mehr selbst außerhalb der Datenbank erzeugen und synchronisieren. Laut MongoDB erfolgt die automatische Embedding-Erstellung derzeit über einen von MongoDB gehosteten Dienst von Voyage AI. Zusätzlich stehen sogenannte Reranker zur Verfügung, die Suchergebnisse nachträglich neu bewerten und in eine relevantere Reihenfolge bringen sollen.

Der Anbieter sieht die Neuerungen vor allem als Baustein für KI-Anwendungen wie Chatbots, Empfehlungssysteme oder KI-Agenten. Statt Daten zwischen Datenbank, Suchmaschine und Vektor-Datenbank zu replizieren, sollen sich Such- und KI-Workloads innerhalb derselben Plattform umsetzen lassen. Die Suchtechnologie basiert dabei auf Apache Lucene.

In der Community Edition stehen Such- und Vektorsuche ab MongoDB 8.2 ohne zusätzliche Lizenzkosten unter der Server Side Public License (SSPL) zur Verfügung. Die Funktionen laufen in einem separaten Prozess namens mongot, der parallel zum eigentlichen Datenbankprozess mongod betrieben wird. MongoDB hat den Quellcode von mongot nach eigenen Angaben ebenfalls unter der SSPL veröffentlicht.

Für Enterprise-Kunden werden die Suchfunktionen als kostenpflichtige Erweiterung von MongoDB Enterprise Advanced angeboten. Für Kubernetes-basierte Installationen erfolgt die Bereitstellung über MongoDB Controllers for Kubernetes (MCK), sodass sich Such- und Vektorsuche in Kubernetes-basierte On-Premises-, Private-Cloud- oder Hybrid-Cloud-Umgebungen integrieren lassen. Nach Angaben des Herstellers richtet sich das Angebot insbesondere an Unternehmen mit regulatorischen Anforderungen oder isolierten Infrastrukturen, die KI-Anwendungen vollständig unter eigener Kontrolle betreiben möchten.

(fo)