Die JavaScript-Library React wird zur React Foundation umziehen, einer neuen Stiftung unter dem Dach der Linux Foundation. React wurde einst von Meta entwickelt, vor 12 Jahren Open Source gestellt und nun der neuen Foundation übergeben. Diese soll eine neutrale Heimat für React, React Native und unterstützende Projekte wie JSX bieten und sicherstellen, dass React offen und Community-geführt bleibt.

Struktur und Aufgaben der React Foundation

Laut der Ankündigung der Linux Foundation stellt die React Foundation einen Meilenstein für die quelloffene Frontend-Entwicklung dar. Und die OpenJS Foundation – der Meta im Jahr 2023 als Gold Member beitrat – hält die React Foundation nicht nur für einen Gewinn für React, sondern auch für JavaScript, offene Zusammenarbeit und das offene Web.

Die Verwaltung der Stiftung wird einem Board of Directors obliegen, mit Seth Webster (Head of React bei Meta) als Executive Director. Dieses wird Finanzen und Ressourcen für Reacts Entwicklung, Community und Ökosystem zuweisen. Die gewählte Struktur ist dafür geeignet, die Anbieterneutralität der Foundation sicherzustellen und die Interessen der Community zu vertreten, so Webster und weitere auf dem React-Blog.

Außer Meta zählen auch Amazon, Callstack, Expo, Microsoft, Software Mansion und Vercel zu den Gründungsmitgliedern der React Foundation.

Die Foundation wird unterschiedliche Aufgaben übernehmen: Sie wird sich um die React-Infrastruktur kümmern, die Konferenz React Conf organisieren und Initiativen erstellen, um das React-Ökosystem zu unterstützen, beispielsweise durch die finanzielle Unterstützung von Projekten.

Technische Steuerung wird ausgelagert

Eine neue technische Governance-Struktur soll unabhängig von der React Foundation entstehen und für die technische Ausrichtung von React zuständig sein. Hierfür wollen die Verantwortlichen Community-Feedback einholen, Details dazu sollen folgen.

(mai)

Das Unternehmen Docker hat angekündigt, den Zugriff auf sichere Software-Pakete für alle Entwicklungsteams – insbesondere auch in kleinen und mittleren Unternehmen – erschwinglicher machen zu wollen. Laut offizieller Verlautbarung öffnet die Firma dazu team-übergreifend unbegrenzten Zugang auf ihre Docker Hardened Images über ein neues Abonnement-Modell, das sich 30 Tage lang kostenlos testen lässt.

Kompakt und sicher mit reduzierter Angriffsfläche

Von herkömmlichen Container-Images sollen sich Hardened Images vor allem dadurch abheben, dass sie Entwicklungsteams einen nahezu CVE-freien Ansatz (near-zero CVE – Common Vulnerabilities and Exposures) ermöglichen. Jedes Image werde direkt aus dem Quellcode erstellt, kontinuierlich mit Upstream-Patches versorgt und durch das Entfernen unnötiger Komponenten gehärtet. Die minimalistische Herangehensweise reduziere nicht nur die Angriffsfläche, sondern liefert auch einige der kleinsten verfügbaren Images – laut Docker bis zu 95 Prozent kleiner als Alternativen.

Die gehärteten Images erfüllen SLSA-Level 3 und Compliance-Tools wie VEX (Vulnerability Exploitability eXchange) stellen den Teams weitergehende Informationen zu potenziellen Schwachstellen rund um die Images zur Verfügung, die dabei helfen können, sich nur auf die tatsächlich relevanten Sicherheitslücken zu konzentrieren. Docker gibt außerdem ein 7-Tage-Patch-Service-Level-Agreement ab, was bedeutet, dass bei einer neuen CVE, die eine Komponente des Images betrifft, binnen einer Woche eine gepatchte Version veröffentlicht werden muss.

Die Qualität der Hardened Images lässt Docker zudem durch die unabhängige Cybersecurity-Beratung SRLabs validieren. Die Prüfung bestätigt, dass die Images signiert sind, standardmäßig rootless laufen und mit SBOM plus VEX ausgeliefert werden.

Image-Katalog deckt vielfältige Entwicklungsanforderungen ab

Die Hardened Images sind mit weit verbreiteten Linux-Distributionen wie Alpine und Debian kompatibel. Laut Docker gelingt die Migration durch das Ändern einer einzigen Zeile im Dockerfile. Teams können die gehärteten Images individuell anpassen und sofort einsatzbereite Systempakete, Zertifizierungen, Skripte und Tools hinzufügen, ohne die gehärtete Basis zu verlieren.

Der bereitgestellte Katalog an gehärteten Container-Images deckt laut Docker ein breites Spektrum an Entwicklungsanforderungen ab – etwa durch ML- und AI-Images, Programmiersprachen und Runtimes, Datenbanken, Anwendungs-Frameworks sowie zentrale Infrastrukturdienste.

Das neue Angebot steht auf Anfrage in zwei Varianten – für Start-ups und KMU oder für Enterprises – ab sofort zur Verfügung. Für den Zugriff auf die kostenlose Testphase ist ein Docker-Hub-Login erforderlich. Weitergehende Informationen finden sich in der Ankündigung von Docker.

(map)

Wer mit npm arbeitet, kennt das Risiko: Beim Installieren einer neuen Bibliothek oder beim Aktualisieren bestehender Pakete wird Code aus fremden Quellen in die eigene Umgebung übernommen. Dieser Code ist weder geprüft noch stammt er notwendigerweise von der Person, die offiziell als Maintainer geführt wird. Angreiferinnen und Angreifer kapern Accounts, schleusen Schadsoftware ein und gefährden dadurch Projekte und Infrastruktur. Die jüngste Malware „Shai-Hulud“ hat dies erneut in großem Stil demonstriert.

Die Schadsoftware verbreitete sich selbstständig über npm-Pakete. Hunderte Module waren betroffen, darunter zahlreiche mit zehntausenden bis hunderttausenden Downloads. Die Malware griff Daten ab, manipulierte GitHub-Workflows und infizierte auf diesem Weg weitere Pakete. Wer diese Pakete installierte, konnte unbemerkt Zugangsdaten verlieren, darunter Token für private Repositories. Im schlimmsten Fall erlangten Unbefugte so Kontrolle über Quellcode und Build-Pipelines.

Diese Vorfälle reihen sich ein in eine Serie von Supply-Chain-Angriffen im JavaScript-Ökosystem. 2018 wurde etwa das Paket event-stream kompromittiert, nachdem der ursprüngliche Maintainer es an eine fremde Person übergeben hatte. 2021 war ua-parser-js betroffen und schleuste Krypto-Miner ein. Das Muster ist stets ähnlich: Ein populäres Paket mit vielen Downloads wird übernommen, eine neue Version mit Schadcode erscheint und fließt sofort in unzählige Projekte.

Warum gerade JavaScript?

Warum gerade das JavaScript-Ökosystem so anfällig ist, wird bei näherer Betrachtung deutlich. JavaScript verfügt über keine besonders umfangreiche Standardbibliothek. Daraus hat sich in den vergangenen 20 Jahren eine Kultur entwickelt, selbst kleinste Funktionen als eigenständige Pakete zu veröffentlichen: für das Trimmen von Strings, das Formatieren von Datumswerten oder das tiefe Klonen von Objekten. Aus wenigen Zeilen Code entstehen so Module mit Millionen Downloads. Selbst wer nur einige Dutzend direkte Abhängigkeiten pflegt, zieht in der Regel Hunderte oder Tausende transitive Pakete mit.

Hinzu kommt die äußerst niedrige Einstiegshürde beim Veröffentlichen von Paketen. Eine Überprüfung des Quellcodes, Code-Signing oder eine Identitätsprüfung sind bislang nicht verpflichtend. Ein einfaches npm publish genügt. Das hat die Community über Jahre hinweg enorm beflügelt und Innovationen ermöglicht, öffnet jedoch zugleich Tür und Tor für Angriffe. Jeder kann Pakete bereitstellen, und solange kein Verdacht aufkommt, bleiben sie verfügbar.

Besonders kritisch ist, dass npm beim Installieren sofort Skripte ausführt, die theoretisch nahezu unbegrenzte Möglichkeiten haben: Dateien lesen, Daten abgreifen, Systemkommandos ausführen. Da es keine Sandbox gibt, geschieht dies direkt in der Build-Umgebung, oft mit denselben Berechtigungen wie die CI/CD-Pipeline. Wer mit Node.js arbeitet, moderne Frontends mit React oder Vue entwickelt oder Build-Tools wie Webpack, Vite oder ESLint verwendet, ist praktisch immer Teil dieses Systems. Sich dem komplett zu entziehen, ist kaum möglich.

npm, GitHub und Microsoft haben das Problem ignoriert

Über viele Jahre war bekannt, dass diese Strukturen ein erhebliches Sicherheitsrisiko darstellen, dennoch blieb der Handlungsdruck gering. GitHub, das npm vor Jahren übernommen hat, und Microsoft als Mutterkonzern haben lange Zeit nur minimale Schutzmechanismen etabliert. Zwar existiert mit npm audit eine Funktion, die bekannte Schwachstellen meldet. Doch diese beschränkt sich im Wesentlichen auf eine Abfrage gegen bekannte Sicherheitsdatenbanken (CVEs). Neue, noch nicht erfasste Schadsoftware bleibt unerkannt. Warnungen beim Installieren gibt es, sie lassen sich jedoch leicht übersehen.

Verpflichtende Sicherheitsmechanismen fehlten lange: keine Zwei-Faktor-Authentifizierung für Paketveröffentlichende, keine konsequente Prüfung der Herkunft von Releases, keine automatische Quarantäne für verdächtige Pakete. Das machte npm über Jahre hinweg zu einem idealen Spielfeld für Supply-Chain-Angriffe. Viele Organisationen verließen sich darauf, dass jemand in der Community schon rechtzeitig Alarm schlagen würde. Häufig geschah das tatsächlich, jedoch oft zu spät.

GitHub als Eigentümer hätte deutlich früher reagieren können – spätestens nach den ersten großen Vorfällen. Anstatt grundlegende Sicherheitsmechanismen einzuführen, beließ man es lange bei punktuellen Warnungen und dem Hinweis auf npm audit. Erst nach dem Shai-Hulud-Wurm scheint nun Bewegung in das Thema zu kommen. Erstmals werden verpflichtende Maßnahmen angekündigt: Künftig müssen alle, die Pakete veröffentlichen, Zwei-Faktor-Authentifizierung aktivieren. Token werden zeitlich befristet und fein granular, alte unbefristete Zugänge verschwinden. Damit soll es Angreiferinnen und Angreifern erschwert werden, einmal gestohlene Zugangsdaten langfristig auszunutzen.

Trusted Publishing und andere Ansätze

Parallel treibt GitHub „Trusted Publishing“ voran. Damit sollen Releases kryptografisch signiert und aus einer sauberen Continuous-Integration-Pipeline stammen. Ziel ist es, die Herkunft von Veröffentlichungen nachweisbar zu machen und Manipulationen zu verhindern. Diese Richtung ist grundsätzlich sinnvoll, kommt jedoch spät. In anderen Bereichen, etwa App-Stores oder Linux-Distributionen, sind signierte Pakete und Build-Prüfungen seit Jahren Standard. npm hat diese Entwicklung lange verschlafen und muss nun aufholen.

Neben GitHub versuchen auch andere Werkzeuge, die Situation zu verbessern. Ein Beispiel ist pnpm, das mit Version 10.16 die Option minimumReleaseAge eingeführt hat. Damit lässt sich festlegen, dass neue Pakete oder Updates nicht sofort installiert werden, sondern erst, nachdem sie eine bestimmte Zeit verfügbar waren. So können Entwicklerinnen und Entwickler beispielsweise angeben, dass eine Version mindestens 24 Stunden alt sein muss, bevor sie in Projekten genutzt wird. Die Idee dahinter: Wenn Schadcode eingeschleust wird, soll die Community Zeit gewinnen, diesen zu entdecken und zu melden, bevor er sich weiterverbreitet.

Auf den ersten Blick wirkt dieser Ansatz pragmatisch. Er reduziert das Risiko, dass frisch kompromittierte Versionen sofort in Builds gelangen. Allerdings hat er auch klare Grenzen. Das Modell verlagert die Verantwortung vollständig auf die Nutzerinnen und Nutzer von Paketen. Es löst nicht das grundlegende Problem, dass prinzipiell jede Person beliebig Pakete veröffentlichen kann. Wer Updates verzögert, erhält zwar eine zusätzliche Beobachtungsphase, sitzt aber zugleich länger auf möglicherweise verwundbaren Versionen. Gerade bei Sicherheitsupdates ist das problematisch: Eigentlich möchte man diese so schnell wie möglich einspielen.

Wer übernimmt die Verantwortung?

Auch die neuen Sicherheitsmaßnahmen von GitHub und Funktionen wie minimumReleaseAge bei pnpm sind damit eher Pflaster auf einer offenen Wunde. Sie zeigen zwar, dass endlich reagiert wird, doch die strukturellen Risiken bleiben. Das Fundament – ein offenes, schwer kontrollierbares Registry-System mit Millionen von Modulen – verändert sich nicht. Wer sich allein auf diese Änderungen verlässt, wird langfristig enttäuscht werden.

Damit bleibt die Verantwortung bei denjenigen, die npm aktiv nutzen. Organisationen und Einzelpersonen müssen selbst Schritte unternehmen, um Projekte abzusichern. Zahlreiche Risiken lassen sich mit vergleichsweise überschaubarem Aufwand verringern, wenn bewusst auf Abhängigkeiten geachtet, die Build-Pipeline gehärtet und laufend kontrolliert wird, welche Pakete tatsächlich ins System gelangen.

Abhängigkeiten reduzieren, Versionen pinnen & Co.

Der erste, einfache, aber wirkungsvolle Schritt besteht darin, Abhängigkeiten zu reduzieren. Prüfen Sie regelmäßig, welche Pakete wirklich notwendig sind. Jedes zusätzliche Modul ist ein potenzielles Einfallstor. Gerade im JavaScript-Umfeld besteht die Gewohnheit, selbst für triviale Aufgaben externe Pakete einzubinden. Häufig reicht es aus, kleine Hilfsfunktionen selbst zu schreiben oder native Funktionen der Sprache zu verwenden. Ein flacher Abhängigkeitsbaum senkt die Angriffsfläche erheblich.

Ebenso wichtig ist es, Versionen gezielt zu steuern. Anstatt flexible Versionsbereiche zu definieren, sollten exakte Versionsnummern eingesetzt werden. Lockfiles gehören ins Repository und sollten Teil des Build-Prozesses sein. CI/CD-Pipelines sollten nur freigegebene Versionen installieren, beispielsweise durch den Einsatz von npm ci oder pnpm install --frozen-lockfile. So wird verhindert, dass unbemerkt neue, potenziell kompromittierte Versionen eingebunden werden.

Auch beim Umgang mit Skripten ist Vorsicht geboten. Viele Angriffe verstecken sich in Pre- oder Post-Install-Hooks. Falls diese nicht benötigt werden, empfiehlt es sich, ihre Ausführung global zu deaktivieren, zum Beispiel über npm install --ignore-scripts. Wenn Skripte unvermeidbar sind, sollten sie gezielt geprüft und ihre Herkunft hinterfragt werden.

Vertrauen schaffen

Ein weiterer wichtiger Bereich betrifft Vertrauen und Kontrolle. Aktivieren Sie konsequent Zwei-Faktor-Authentifizierung für alle Accounts, die Pakete veröffentlichen oder Token erzeugen. Verwenden Sie moderne Token-Formate, die zeitlich befristet und minimal berechtigt sind. Bewahren Sie geheime Zugangsdaten strikt getrennt vom Quellcode auf. Konfigurationsdateien mit Klartext-Passwörtern dürfen nicht ins Repository gelangen, Token gehören weder in Logs noch in ungeschützte Umgebungsvariablen. Fremder Code könnte ansonsten auf diese Informationen zugreifen.

Wer selbst Pakete veröffentlicht, sollte sich mit dem bereits erwähnten Konzept des Trusted Publishing vertraut machen. Dadurch lassen sich Releases kryptografisch signieren und ihre Herkunft aus einer definierten CI/CD-Pipeline nachweisen. Das erschwert es Angreiferinnen und Angreifern erheblich, sich in den Veröffentlichungsprozess einzuklinken, und stärkt gleichzeitig das Vertrauen der Nutzenden in die Integrität des Pakets.

Vor der Installation neuer Pakete ist eine manuelle Überprüfung empfehlenswert. Ein kurzer Blick in das zugehörige Repository hilft, die Vertrauenswürdigkeit einzuschätzen:

• Gibt es aktuelle Commits?
• Reagieren Maintainer auf Meldungen?
• Sind plötzliche Eigentümerwechsel oder verdächtige Änderungen erkennbar?

Solche Prüfungen dauern nur wenige Minuten, können aber langfristig große Sicherheitsprobleme vermeiden.

Monitoring und Auditing

Darüber hinaus ist laufendes Monitoring zentral. npm audit bietet eine schnelle Grundprüfung bekannter Schwachstellen. Tools wie Dependabot oder Renovate schlagen automatisch Sicherheitsupdates vor. Dienste wie Socket oder Snyk gehen sogar noch einen Schritt weiter, indem sie nicht nur bekannte Lücken erkennen, sondern auch auffällige Veränderungen beobachten – etwa neu eingeführte Installationsskripte. Entscheidend ist, Warnungen ernst zu nehmen und regelmäßig Zeit für deren Bearbeitung einzuplanen. Wer besonders vorsichtig agieren möchte, kann neue Versionen zunächst in einer internen Testumgebung beobachten, bevor sie produktiv genutzt werden. So bleibt Flexibilität erhalten, um sicherheitskritische Updates trotzdem sofort einzuspielen.

Ein unterschätzter Faktor ist die Sicherheit von Build- und Deployment-Pipelines. Wenn es Angreiferinnen oder Angreifern gelingt, diese zu kompromittieren, werden alle folgenden Releases unsicher – unabhängig davon, wie sorgfältig einzelne Pakete geprüft wurden. Die Build-Umgebung sollte nur wohldefinierte Registries verwenden und strikt von der Deployment-Umgebung getrennt sein. So lässt sich verhindern, dass ein kompromittierter Build-Prozess direkt auch das Ausrollen von Schadcode ermöglicht.

Der Umgang mit Geheimnissen ist in CI/CD-Umgebungen besonders heikel. API-Keys, Token und Passwörter dürfen weder in Logs erscheinen noch ungeschützt in Variablen stehen, die von Drittpaketen eingesehen werden könnten. Prinzipien wie Least Privilege sind hier entscheidend: Token sollten ausschließlich die minimal notwendigen Rechte besitzen. Ein reines Lese-Token ist in vielen Szenarien ausreichend und reduziert die Angriffsfläche erheblich.

Hilfreich ist zudem, automatisiert Metadaten zu erzeugen. Am Ende eines Builds kann ein Dependency-Tree erstellt und archiviert werden. Dadurch lässt sich bei Sicherheitsvorfällen nachvollziehen, welche Paketversionen im Einsatz waren. Tools wie npm ls oder pnpm list unterstützen dabei. Der Aufwand ist gering, der Nutzen im Ernstfall sehr groß.

Sicherheit ist (auch) eine kulturelle Frage

Letztlich ist Sicherheit kein Einzelthema, sondern Teil der Teamkultur. Neue Abhängigkeiten sollten genauso sorgfältig geprüft werden wie eigener Code. Pull Requests, die neue Pakete einführen oder bestehende aktualisieren, verdienen besondere Aufmerksamkeit:

• Braucht das Projekt dieses Paket wirklich?
• Wird es aktiv gepflegt?
• Gibt es ungewöhnliche Veränderungen?

Verbindliche Richtlinien sind hier hilfreich. Dokumentieren Sie beispielsweise, welche Registries akzeptiert werden, wie Lockfiles zu verwenden sind, ob Parameter wie --ignore-scripts standardmäßig gesetzt werden und welche Prüfwerkzeuge in der Pipeline laufen müssen. So entstehen feste Standards, die Sicherheit im Alltag erleichtern.

Auch organisatorisch sollte Zeit und Budget für Sicherheitsaufgaben eingeplant werden. Viele Probleme entstehen nicht aus Gleichgültigkeit, sondern aus Termindruck. Regelmäßige Updates, Audits, Schulungen und Verbesserungen der Build-Prozesse brauchen feste Kapazitäten. Ebenso wichtig ist es, informiert zu bleiben: Sicherheitsvorfälle wie Shai-Hulud werden häufig zuerst in Entwickler-Communities oder auf Plattformen wie GitHub bekannt. Wer entsprechende Feeds oder Benachrichtigungen abonniert, kann schneller reagieren.

Was das konkret bedeutet

Die Sicherheit im JavaScript-Ökosystem bleibt somit leider eine Daueraufgabe. GitHub und pnpm haben erste sinnvolle Schritte unternommen, aber sie kommen spät und lösen die grundlegenden Probleme nicht. Das offene, kaum kontrollierbare Netzwerk aus Millionen Paketen macht npm weiterhin anfällig. Wirklich geschützt ist nur, wer selbst Verantwortung übernimmt: Abhängigkeiten reduzieren, Versionen exakt pinnen, Lockfiles einsetzen, Accounts absichern, Monitoring und Auditing etablieren, CI/CD härten und Sicherheit als festen Bestandteil der Entwicklungskultur verankern.

Wer diese Maßnahmen konsequent umsetzt, kann die Risiken deutlich verringern. Angriffe wie Shai-Hulud verschwinden dadurch nicht, treffen jedoch Projekte seltener und weniger hart. So lässt sich schneller reagieren und im besten Fall verhindern, dass Schadcode überhaupt produktiv eingesetzt wird.

(rme)