Halten Sie archivierte RequireJS -Versionen auf dem neuesten Stand, während Sie Ihre Migration planen

Nein. Die OpenJS Foundation führt RequireJS in ihrer Liste der archivierten Projekte auf, und auf requirejs.org wird weiterhin 2.3.7 als aktuellste Version zum Download angeboten. Bei npm ist zwar 2.3.8 verfügbar, es gibt jedoch weder eine Roadmap noch ein Sicherheitsteam, und der Sicherheitspatch von 2024 war die erste Veröffentlichung des Projekts seit sechs Jahren. TuxCare ELS deckt ältere Versionen ab, die noch in der Produktion im Einsatz sind.

Verwenden Sie einen mit Sicherheitspatches versehenen Ersatz für die von uns unterstützte Version, die Sie bereits einsetzen. TuxCare ELS stellt gepflegte RequireJS-Pakete über seine npm-Registry bereit. Fügen Sie die Registry zu Ihrer .npmrc hinzu, verweisen Sie in der Datei package.json manuell oder mithilfe des TuxCare Patcher auf das ELS-Paket und führen Sie anschließend „npm install“ aus. Es sind keine Änderungen an AMD-Modulen oder der Loader-Konfiguration erforderlich.

ELS deckt RequireJS 2.1.22 und 2.3.6 ab, beides langlebige Versionen, die in ausgereiften AMD-Anwendungen zum Einsatz kommen. Die Abdeckung ist versionsspezifisch, sodass das von Ihnen installierte Paket mit der Version übereinstimmt, die Ihr Build bereits erwartet. Falls Ihre Anwendung eine andere Version festlegt, wenden Sie sich bitte an TuxCare, um die Abdeckungsoptionen zu besprechen.

Wenn möglich, ja. Die Behebung für CVE-2024-38999 besteht aus einer einzigen Schutzmaßnahme innerhalb des Loaders, und die Umstellung auf die Patch-Level 2.3.6 bis 2.3.8 erfordert keine Änderungen seitens AMD. ELS ist für Builds gedacht, die durch Validierung, Herstellerzertifizierung oder eine festgelegte Toolchain eingefroren sind, sowie für Teams, die eine SLA-gestützte Abdeckung für alle zukünftigen Entwicklungen wünschen.

Bei CVE-2024-38999 handelt es sich um eine Prototyp-Verunreinigung über `s.contexts._.configure`, die alle RequireJS-Versionen bis einschließlich 2.3.6 betrifft. Der Upstream-Entwickler hat das Problem in Version 2.3.7 behoben. ELS stellt diese Korrektur für die betroffenen Versionen für Teams bereit, bei denen ein Wechsel auf Version 2.3.7 oder höher nicht möglich ist.

Ja. ELS-Pakete stammen aus der TuxCare-npm-Registry und werden überall dort aufgelöst, wo eine abgedeckte RequireJS-Version in Ihrem Verzeichnisbaum vorkommt – einschließlich Kopien, die von Paketen eingebunden wurden, über die Sie keine Kontrolle haben. npm-Überschreibungen in der Datei „package.json“ leiten jede Instanz auf das gepflegte Äquivalent um.

Nein. ELS behält die betroffene Version und ihr erwartetes Ladeverhalten bei. Bestehende „define“- und „require“-Aufrufe, die Loader-Konfiguration, Pfade und die Shim-Konfiguration sowie die r.js-Build-Schritte bleiben unverändert, während das Paket die entsprechenden Sicherheitskorrekturen erhält.

Ja. ELS-Pakete werden über npm aus dem TuxCare-Registry geladen, sodass sie sich für Docker-Builds, CI/CD-Pipelines und Deployment-Workflows eignen, bei denen RequireJS bereits über npm installiert wird. Das Registry-Token wird aus der Datei .npmrc Ihres Projekts ausgelesen.

ELS wurde entwickelt, um die Anforderungen zur Behebung von Sicherheitslücken im Rahmen von Rahmenwerken wie SOC 2, PCI DSS, HIPAA, NIS2, DORA und CRA zu unterstützen. Es sorgt nicht allein dafür, dass eine Anwendung konform ist. Was es bietet, sind ein namentlich genannter Anbieter, ein vertraglich festgelegtes SLA und ein dokumentierter Patch-Verlauf, den Auditoren überprüfen können.

Das hängt von der Anwendung und den Migrationskosten ab. Der Wechsel von AMD- zu ES-Modulen kann Auswirkungen auf Moduldefinitionen, die Loader-Konfiguration, die Bündelung und die Browserunterstützung haben. ELS sorgt dafür, dass die abgedeckten Versionen auf dem neuesten Stand bleiben, während Sie die Modernisierung schrittweise vorantreiben oder eine Anwendung weiterbetreiben, bei der eine Migration nur sehr geringe Vorteile bringt.