Soweit zu: „Erstellen und vergessen“ (Schadcode-in-weit-verbreiteter-JavaScript-Bibliothek-UAParser-js)

[Rolf B]

Hallo Raketenwilli,

wenn Du eine Lib von irgendwo her einspielst, ist es deine Verantwortung, diese Lib auf Schadfreiheit zu prüfen. Keiner sagt, dass das einfach ist. Bei uns im Unternehmen ist der Prozess für eine FLOSS-Integration komplex und setzt immer eine Code-Inspektion voraus.

Aber wenn sie dann in der Wilden Weiten Welt im Einsatz ist, kann natürlich immer noch was auffallen. Und ja, entweder schreibst Du in den Vertrag einen ausdrücklichen Disclaimer hinein, dass Du nach bestem Wissen und Gewissen die Korrektheit und Schadfreiheit der genutzten Libraries zusicherst, aber nicht garantierst, und zukünftig auffallende Fehler oder Schadcode dieser Version zu Lasten des Kunden gehen.

Oder Du vereinbarst eine Überwachung als Kosten für Wartung und Pflege. Da kannst Du nur überlegen, wieviel Zeit Du pro Tag/Woche/Monat mit der Lektüre einschlägiger Quellen verbringst und auf deine Kunden umrechnen. Dann bist Du aber auch in der Verantwortung, entsprechende Meldungen zeitnah aufzugreifen. Machst Du 4 Wochen Urlaub und 2 Tage nach Abreise kommt ein Zero-Day Exploit für eine deiner Libs hoch, kannst Du angeschmiert sein. Für eine Einpersonenfirma ist das kaum zu stemmen.

Aber wenn Du das vereinbarst, solltest Du die Reaktion auf solche Meldungen nicht pauschal vereinbaren. Der Aufwand für eine Reaktion kann sehr unterschiedlich sein. Frage ist nur, ob die Kunden da mitspielen… Aber ein Gefühl, wieviel Arbeit der Update einer Lib ist, solltest Du doch haben, oder? Wenn breaking changes drin sind, ist es unkalkulierbar, aber im Normalfall ist es ein Austausch von Dateien. Plus Inspektion der Änderungen zur eingesetzten Version, um zu schauen, ob Schabernack hineingekommen ist. Rechne pro Lib genau ein Update - nicht jede Lib wird auffällig werden und Updates der Libraries sind auch nur dann zwingend nötig, wenn die Betriebsplattform breaking changes mitbringt, die eine Lib abschießen.

Rolf