Das Ende des Supportzyklus für LoopBack 3 und die immer umfangreichere API-Migration

Wichtigste Erkenntnisse

• LoopBack 3 hat im Dezember 2020 das Ende seines Lebenszyklus in der Community erreicht und erhält keine Upstream-Korrekturen mehr.
• Falls LoopBack im Lieferumfang von IBM API Connect enthalten war, überprüfen Sie zunächst den Lebenszyklus dieses Produkts.
• Da es sich bei LoopBack 4 um eine Neuprogrammierung handelt, gilt der übliche Upgrade-Plan mit Versionssprung und Fehlerbehebung hier nicht.
• Ein Großteil des Risikos liegt in eingeschränkten transitiven Abhängigkeiten, die npm audit fix kann nicht erreichen.

LoopBack 3 ermöglichte eine schnelle Entwicklung komplexer APIs durch die Kombination von Modellen, Konnektoren, Zugriffskontrollen und generierten Endpunkten. Genau diese Abstraktionen sind der Grund dafür, dass die Migration zu LoopBack 4 eher ein Architekturprojekt als eine einfache Aktualisierung der Abhängigkeiten ist.

Der Community-Support endete im Dezember 2020. Die einzige dokumentierte Ausnahme bildeten kritische Fehlerbehebungen und Sicherheitspatches, die über IBM API Connect bereitgestellt wurden; dieser Kanal wurde inzwischen jedoch ebenso geschlossen wie die Produktversionen, für die er galt. Mittlerweile befindet sich ein Großteil dessen, was ein Scanner bei einem LoopBack-3-Projekt meldet, eher im Abhängigkeitsbaum als im Framework-Paket selbst.

In diesem Beitrag geht es darum, was zu tun ist, wenn LoopBack 3 das Ende seiner Lebensdauer erreicht hat, der Migrationspfad einer Neuprogrammierung gleichkommt und die API eine tragende Rolle spielt.

Das API-Framework, das das Geschäft kodierte

LoopBack 3 war in einer Sache gut, die sich als äußerst wichtig herausstellte. Man definierte Modelle, verband Konnektoren und legte Zugriffskontrollen fest, und LoopBack generierte daraus funktionierende REST-Endpunkte. Schnell. Im Laufe einiger Jahre können diese Modelldefinitionen still und leise zur Integrationsschicht des Unternehmens werden, ohne dass dies irgendwo festgehalten wird. Das Schwierige beim Abschied von LoopBack 3 ist selten der Framework-Code. Es ist die Geschäftslogik, die sich in Modelldefinitionen, Hooks und ACLs angesammelt hat.

Stellen Sie sich ein Logistikunternehmen vor, das über 60 REST-Endpunkte verfügt, die aus LoopBack-3-Modellen generiert wurden. Zwei interne Anwendungen sind davon abhängig. Eine Partnerintegration greift nach einem Zeitplan auf diese Endpunkte zu, den der Partner selbst steuert. Das Ganze läuft auf Node.js 12 in einer VM, die niemand neu aufsetzen möchte, da die letzte Person, die die Startsequenz verstanden hat, das Unternehmen schon vor Jahren verlassen hat.

Bei einem solchen System ist eine Versionserhöhung keine Migrationsstrategie, und das hat Auswirkungen auf jede nachfolgende Entscheidung. Tut man so, als wäre es anders, führt dies höchstwahrscheinlich zu einer ins Stocken geratenen Migration, bei der eine nicht gepatchte API weiterhin im Produktivbetrieb verbleibt.

Was das Ende des Supportzyklus von LoopBack 3 tatsächlich bedeutet

Da die Unterstützung durch die Community wegfällt, erhält LoopBack 3 keine neuen Funktionen mehr und es gibt keine aktive Fehlerbehebung durch die Community. Die README-Datei des Projekts macht in Bezug auf den Rest keine Umschweife: keine Pull-Anfragen mehr und kein Support für Community-Nutzer. Die Richtlinie zum Langzeit-Support ist etwas milder und lässt den Betreuern Spielraum, von der Community eingereichte Korrekturen für kritische Fehler zu prüfen. Beide Dokumente verweisen auf dieselbe eng gefasste Ausnahme für kritische Korrekturen über IBM API Connect, und beide wurden verfasst, als dieses Produkt noch Support bot.

Dahinter verbirgt sich zudem eine leicht zu übersehende Support-Richtlinie. Die Langzeit-Support-Richtlinie von LoopBack knüpfte „Maintenance LTS“ an die Node.js-LTS-Versionen, die zum Zeitpunkt des Eintritts einer Version in diese Phase unterstützt wurden. Sobald diese Node.js-Versionen das Ende ihrer Wartungsphase erreichten, endete auch die Wartungsphase der entsprechenden LoopBack-Version. Die Aufnahme neuer Hauptversionen von Node.js in den Support war in „Maintenance LTS“ ausdrücklich nicht erlaubt – was umschreibend bedeutet, dass die unterstützte Node.js-Generation bereits vor Jahren festgelegt wurde.

Insider-Tipp: Wenn Ihr LoopBack im Lieferumfang von IBM API Connect v5 oder v2018 enthalten war, überprüfen Sie den Produktlebenszyklus, bevor Sie davon ausgehen, dass ein IBM-Fallback vorhanden ist. Der Basis-Support für v5 endete am 30. April 2022 und für v2018 am 30. April 2023; der erweiterte Support für beide Versionen endete am 31. Dezember 2023, und IBM gibt nun an, dass für keine der beiden Versionen mehr Code- oder Sicherheitsupdates bereitgestellt werden. Dieser Weg ist versperrt, was bedeutet, dass nicht nur die Open-Source-EOL-Frist bereits abgelaufen ist.

Ein Hinweis lässt sich direkt aus dem öffentlichen Paketverlauf ablesen. Die letzte Version von LoopBack 3, [email protected], wird nach wie vor von npm bereitgestellt, und die neuen Entwicklungen auf Upstream-Ebene konzentrieren sich auf die LoopBack-4-Pakete. Dort liegt derzeit der Schwerpunkt des Projekts.

Warum LoopBack 4 nicht einfach nur LoopBack 3 mit einer neuen Versionsnummer ist

LoopBack 4 ist die aktuelle, aktiv weiterentwickelte Version. Auch hier handelt es sich um eine komplette Neuprogrammierung. Der Kern basiert auf TypeScript und stützt sich auf Dependency Injection sowie einen IoC-Container, wobei Controller und Repositories den Ansatz mit Modellen und Boot-Skripten ersetzen, der LoopBack 3 geprägt hat. Auch das Erweiterungsmodell hat sich geändert. Es handelt sich um ein neues Programmiermodell und nicht um ein Ziel, das man über einen Paketmanager erreicht.

Daher entfällt der Großteil der Arbeit auf die Teile der Anwendung, die auf den eigenen Konventionen von LoopBack 3 basieren. Das umfasst in der Regel Boot-Skripte und die davon abhängige Abfolge, Remote-Methoden und die damit verbundenen Operations-Hooks, ACL-Definitionen, die Ihr Berechtigungsmodell kodieren, Mixins und die Konfiguration von Connectors, alles, was auf den JSON-Konventionen für Modelle basiert, sowie die generierten Client-SDKs, die nachgelagerte Nutzer bereits einsetzen.

Schätzen Sie den Arbeitsaufwand realistisch ein. Ein normales Framework-Upgrade lässt sich oft in Sprints bemessen. Eine Migration auf LoopBack 3 kann leicht mehrere Quartale in Anspruch nehmen, und die Schätzung hängt davon ab, wie viel Logik in den Modelldefinitionen enthalten ist und nicht in Anwendungscode, den Sie sauber portieren können.

Realitätscheck: Die Annahme „Es ist doch nur ein Upgrade“ ist genau das, was diese Projekte zum Scheitern bringt. Zwölf Endpunkte mit einfacher Logik ergeben ein überschaubares Projekt für ein kleines Team. Zweihundert generierte Endpunkte mit ACLs, die ein Berechtigungsmodell kodieren, ergeben ein Architekturprogramm mit einer eigenen Budgetlinie – und das zu Recht.

Falls die API Integrationen versorgt, auf die Sie keinen Einfluss haben, sollten Sie die Sicherheitsfrist von der Frist für die Neuprogrammierung trennen, bevor Sie weitere Entscheidungen treffen. Es handelt sich um zwei unterschiedliche Zeitrahmen, und wenn Sie diese miteinander vermischen, führt dies zu einer überstürzten Neuprogrammierung, für die Sie aufgrund Ihrer Verpflichtungen gegenüber Ihren Partnern den Preis zahlen müssen.

Woher die Erkenntnisse tatsächlich stammen

Öffnet man den Abhängigkeitsbaum eines LoopBack-3-Projekts, erkennt man meist schnell ein Muster. Der Code des Frameworks selbst macht nur einen Teil der Risikofläche aus. Die Namen, die immer wieder auftauchen, befinden sich mehrere Ebenen tiefer und umfassen – je nach Ihren Konnektoren und Ihrer Lockdatei – in der Regel qs, lodash, body-parser, nodemailer, strong-remoting, strong-globalize, das veraltete shortid, glob, inflightund underscore.string. Einige sind direkte Abhängigkeiten von LoopBack-Paketen. Viele sind transitiv und werden von den übergeordneten Paketen mit einbezogen.

Das Rahmenwerk hat seine eigene Beratungsgeschichte, und beide Seiten dieser Geschichte sind aufschlussreich. Das LoopBack-Sicherheitshinweis vom 30. November 2020 berichtete über ein Problem mit einem Prototyp in Bezug auf Umweltverschmutzung in @loopback/rest, wo JSON-Daten, die constructor wurden akzeptiert. Die als CVE-2020-4988 erfasste Schwachstelle betraf Version 8.0.0 und frühere Versionen; der Fix wurde in Version 9.0.0 bereitgestellt. Es handelt sich dabei um LoopBack-4-Code, was auch der springende Punkt ist, da Korrekturen auf Framework-Ebene mittlerweile dort vorgenommen werden. Die Mitteilung vom 6. August 2022 ist ein Muss für alle, die PostgreSQL einsetzen, da darin eine kritische SQL-Injection über die erweiterte contains Filter ein loopback-connector-postgresql 5.5.0 und darunter. Es gibt Probleme, wenn dieser Filter auf den Konnektor zugreifen kann, einschließlich Datenquellen, die mit allowExtendedProperties: true sowie Code, der Connector-Methoden direkt aufruft. In Version 5.5.1 wurde die Eingabevalidierung hinzugefügt, und in den Hinweisen werden Workarounds für Teams aufgeführt, die noch kein Upgrade durchführen können.

Was genau Sie sehen, hängt von Ihrer Lockfile-Datei, Ihrer Node.js-Version und Ihren eigenen direkten Abhängigkeiten ab. Was jedoch projektübergreifend gilt, ist die Struktur. Einige dieser Versionen unterliegen Einschränkungen durch die Paketbereiche von LoopBack oder durch die darüber liegenden Pakete, was verhindert, dass die automatisierte Korrektur eine kompatible, korrigierte Version auswählt.

Vorsicht: Behandeln npm audit fix --force als risikoreiche Änderung an einem LoopBack-3-Projekt. Einfach npm audit fix installiert nur Updates, die in die von Ihnen angegebenen Bereiche passen. Wenn eine Metasicherheitslücke-Kette das Stammprojekt erreicht, können zur Behebung Änderungen außerhalb dieser Bereiche erforderlich sein. An diesem Punkt verlangt npm --force, was gemäß der eigenen Dokumentation installiert Module außerhalb des von Ihnen angegebenen Abhängigkeitsbereichs, einschließlich größerer Änderungen gemäß SemVer. Bei einem so alten Verzeichnisbaum führt das dazu, dass aus einem ruhigen Nachmittag eine App wird, die sich nicht mehr starten lässt. Führen Sie folgenden Befehl aus: npm audit fix --dry-run --json Zunächst einmal sollten Sie lesen, was darin vorgeschlagen wird.

Die praktische Erkenntnis daraus ist, zwei Listen zu führen. Die eine enthält Befunde, die Sie beheben können, indem Sie eine untergeordnete Abhängigkeit aktualisieren. Die andere enthält Befunde, die durch Einschränkungen weiter oben in der Hierarchie blockiert sind. Diese Listen erfordern völlig unterschiedliche Vorgehensweisen, und wenn man sie vermischt, verschwendet man einen Sprint. Das ist auch der Grund, warum die transitive Abdeckung hier wichtiger ist als bei fast allen anderen Fällen, in denen Sie Korrekturen vornehmen – denn ein Behebungsplan, bei dem eine betroffene, anfällige Abhängigkeit bestehen bleibt, hat diesen Befund nicht geschlossen.

Den richtigen Weg wählen

Es gibt keinen einzig richtigen Weg, aber die realistischen Optionen sind begrenzt. Bauen Sie kleinere, bewährte Dienste auf LoopBack 4 neu auf, wenn die Logik so schlank ist, dass die Arbeit tatsächlich bewältigt werden kann. Stellen Sie die APIs auf eine neue Plattform um, deren Architektur den geschäftlichen Anforderungen nicht mehr gerecht wird, denn wenn Sie ein schlechtes Design in ein neues Framework übertragen, haben Sie am Ende nur das gleiche Problem in TypeScript.

Setzen Sie „Secure LoopBack 3“ ein, wenn eine überstürzte Migration ein unmittelbareres Betriebsrisiko darstellen würde als die Schwachstellen, die tatsächlich für Ihre Bereitstellung gelten. Das verschafft Ihnen Zeit, ohne so zu tun, als käme eine Neuprogrammierung nicht in Frage.

Für die tragenden APIs ist das „Strangler“-Muster die konkrete Umsetzung dieses Ansatzes. Man setzt eine Kompatibilitätsfassade vor die LoopBack-3-API, damit die externen Verträge stabil bleiben, und verlagert dann die Funktionen nacheinander hinter diese Fassade. Die Partner greifen weiterhin auf dieselbe URL zu, während man das, was dahinter liegt, neu aufbaut.

Diese Sicherheitslücke muss noch geschlossen werden, und was dafür angeboten wird, hängt davon ab, welche Version Sie verwenden. TuxCare's Endless Lifecycle Support (ELS) Derzeit werden LoopBack 1.10.0 und 2.42.0 dokumentiert, die als direkt einsetzbare Ersatzversionen über eine von TuxCare verwaltete npm-Registry bereitgestellt werden. Die dazugehörige Überschreibungsliste ist für jeden, der einen Scan-Bericht liest, besonders interessant, da sie bis in die Tiefe reicht qs, body-parser, underscore.string und den Rest der Baumstruktur, anstatt bei dem Paket der obersten Ebene anzuhalten. Wenn die Fassade einen LoopBack 2-Dienst anbindet, wird die Sicherheitsüberprüfung während des Rebuilds durchgeführt. Bei Version 3.x sollten Sie sich über die Abdeckung für Ihre konkrete Version erkundigen, bevor Sie diese in den Plan aufnehmen.

Die Kurzfassung lautet wie folgt: Eine einfache Logik und eine geringe Anzahl von Endpunkten bedeuten, dass ein Neuaufbau auf LoopBack 4 und die Festlegung eines Termins erforderlich sind. Modellgesteuerte Berechtigungen und Partnerintegrationen erfordern eine schrittweise Neuprogrammierung hinter einer Fassade, wobei die alte Oberfläche so lange sicher gehalten wird, wie ihr Release abgedeckt ist. Und falls LoopBack über IBM API Connect eingeführt wurde, sollte vor allem anderen die Frage des Produktsupports geklärt werden.

Wie TuxCare mit LoopBack umgeht

TuxCare verfolgt das Framework und dessen Abhängigkeitsbaum und ermittelt anschließend, ob jeder Sicherheitshinweis tatsächlich auf die betreffende Version zutrifft, bevor Patches installiert werden. Zuerst die Anwendbarkeit, dann der Rausch – das ist wichtig, wenn so vieles, was man vor sich hat, transitiv ist.

Korrekturen werden in die unterstützten Versionen zurückportiert, anstatt als Framework-Upgrade bereitgestellt zu werden, und die Pakete werden als direkte Ersatzversionen für die nicht mehr unterstützten Originale veröffentlicht. Dieser Unterschied ist von Bedeutung, da generierte Endpunkte eine Vereinbarung darstellen, auf die sich andere Teams verlassen, und eine „Korrektur“, die die Form der Antwort verändert, für alle nachgelagerten Teams einen Rückschritt bedeutet.

Das Support-Modell ist dokumentiert und nicht improvisiert. Die veröffentlichten Zielvorgaben lauten: 14 Tage ab der öffentlichen Bekanntgabe für hohe und kritische Befunde nach CVSS 7.0 und höher, 60 Tage für mittlere und 90 Tage für niedrige, wobei eine erste Reaktion auf ein gemeldetes Problem innerhalb von drei Tagen erfolgen soll – alles im Rahmen wirtschaftlich angemessener Bemühungen und nicht als vertragliche Garantie. Jedes von TuxCare erstellte Paket wird mit einer SBOM ausgeliefert, und CycloneDX-VEX-Dokumente werden zusammen mit jeder Paketversion veröffentlicht und bei jeder neuen Version aktualisiert, sodass der Prüfpfad festhält, welche bekannten CVEs eine bestimmte Artefaktversion betreffen und welche nicht. Diese Rückverfolgbarkeit macht sich in regulierten Umgebungen bezahlt, die einen schriftlichen Nachweis benötigen, und die ticketbasierte schriftliche Eskalation stellt einen solchen bereit. TuxCare ist nicht das Upstream-Projekt und gibt auch nicht vor, dies zu sein. Die Arbeit besteht in einem disziplinierten Backporting für Produktionssysteme, nachdem sich die Aufmerksamkeit im Upstream-Projekt bereits auf LoopBack 4 verlagert hat.

Um den aktuellen CVE-Status aller abgedeckten Pakete in Echtzeit zu erfahren, ist der TuxCare CVE-Tracker die richtige Anlaufstelle.

Die Rolle von LoopBack im OpenJS-Ökosystem

LoopBack ist ein At-Large-Projekt der OpenJS Foundation. StrongLoop, ein Unternehmen von IBM, hat es im Juni 2021 der Stiftung zur Verfügung gestellt, und im folgenden Jahr wurde es aus der Inkubationsphase in den At-Large-Status überführt. Das „Ecosystem Sustainability Program“ ( ESP) der Stiftung wurde ins Leben gerufen, damit auslaufende und ältere Versionen kommerziell abgesichert werden können, wobei ein Anteil der Partnerumsätze die teilnehmenden Betreuer und die Arbeit der Stiftung unterstützt. TuxCare trat als Gold-Mitglied und ESP-Partner bei. Da das Programm nicht exklusiv ist, hindert die kommerzielle Absicherung die Betreuer nicht daran, jede Version öffentlich zu unterstützen, einschließlich derjenigen, die von einem Partner abgedeckt werden.

LoopBack 4 könnte durchaus das richtige Ziel sein. Aber wenn man den Weg dorthin als eine Art „Paket-Update“ betrachtet, entstehen in guten Teams schlechte Pläne.

Zusammenfassung

Artikel Name

Das Ende des Lebenszyklus von LoopBack 3 und was dies für Ihre API bedeutet

Beschreibung

LoopBack 3 wurde 2020 eingestellt, und LoopBack 4 ist eine komplette Neuprogrammierung, kein Upgrade. Informieren Sie sich über die tatsächlichen Migrationskosten und erfahren Sie, wie TuxCare Ihnen helfen kann.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers