Softwareentwickler, die Open-Source-Bibliotheken verwenden, waren Anfang dieser Woche fassungslos, als sie erfuhren, dass zwei Hilfspakete in den GitHub- und NPM-Bibliotheken seltsamen Code generierten, der angeblich vom Ersteller des Projekts erstellt wurde, um gegen das Versäumnis zu protestieren, nicht für die Weiterarbeit bezahlt zu werden.

Ein Branchenexperte, den wir befragten, bezeichnete die Aktion als „bösartig“, während ein anderer sie als „rachsüchtig“ bezeichnete.

Unabhängig von der Ursache sagt Sandy Carielli von Forrester Research, Anwendungssicherheits- und Risikoanalyst, dass der Vorfall viele Fragen über die Wartung und Sicherheit von Open-Source-Anwendungen aufwirft sowie darüber, was Entwickler und kommerzielle Benutzer von Open-Source-Code einander schulden.

Sie fügte hinzu, es sei auch eine Warnung an Entwickler, kein Update für ein Open-Source-Projekt zu installieren, ohne es vorher zu testen.

„Es ist wichtig, wenn Sie sie mitnehmen, um zu sehen, wie der Rest der Community sie verwendet. [open source packages]. Suchen Sie nach Community-Kommentaren und prüfen Sie, ob jemand zurückgehen musste [to an earlier version] aufgrund von Problemen, und stellen Sie sicher, dass Sie die richtigen Tests durchführen, bevor Sie es einfach abholen und installieren.

Carielli gab zu, dass sie „überrascht, vielleicht ein wenig entsetzt“ war, als sie von dem Vorfall erfuhr.

„Manchmal stoßen Sie auf Probleme mit böswilligen Entwicklern, die bösartige Projekte herunterladen oder versuchen, die Abhängigkeitsverwirrung auszunutzen, indem sie ein gutes Projekt durch ein bösartiges ersetzen. Aber die Idee, dass ein Entwickler aus einem bekannten und vertrauenswürdigen Projekt plötzlich Schadcode einschleust, habe ich noch nie gehört.

„Es wird immer dieses ‚Vertrauen, aber verifizieren‘-Element geben“, sagte sie, „um sicherzustellen, dass Sie die notwendigen Kontrollen haben, um bösartige Pakete zu blockieren und sie zu scannen, um sicherzustellen, dass Sie die richtige Version verwenden Quellsoftware Dies sind wichtige Elemente der Verwaltung von Unternehmenssoftware.

Wenn die Behauptung zutrifft, dass es sich um einen Protest handelt, wirft der Vorfall – erneut – Fragen darüber auf, wie Entwickler von Open-Source-Projekten entschädigt werden sollten, sagte sie. Aber, fügte Carielli hinzu, es stellt sich auch die Frage: „Was ist ethisch vertretbar, wenn man weiß, dass sich eine große Gemeinschaft auf das Projekt verlässt?“

Ein Dienstprogramm, bekannt als “Farben”, ermöglicht es einer Anwendung, in Farbe zu drucken, während das andere, bekannt als “false”, gefälschten Code generiert, um die Anwendung zu testen.

Mais laut dem Nachrichtendienst Bleeping Computer, das den Vorfall zuerst gemeldet hat, zwingen die neuesten “Farb”-Versionen Anwendungen, die das Dienstprogramm verwenden, eine amerikanische Flagge dauerhaft auf dem Bildschirm anzuzeigen. Laut Sonotype, wurde der Funktionscode von ‘faker’ gelöscht.

Es wird nicht angenommen, dass es sich bei den neuen Versionen um einen Drittanbieter-Hack handelt, sondern um die Kreation des Entwicklers beider Pakete, der offenbar Protest eingelegt hat.

Zu diesem Schluss kamen Rezensenten aufgrund einer Notiz, die angeblich im Jahr 2020 vom Entwickler veröffentlicht wurde. Er schrieb: „Bei allem Respekt, ich werde die Fortune 500 (und andere kleine Unternehmen) nicht länger mit meiner kostenlosen Arbeitskraft unterstützen. Mehr gibt es nicht zu sagen… Nutzen Sie die Gelegenheit, mir einen sechsstelligen Jahresvertrag zu schicken oder schmieden Sie das Projekt und lassen Sie jemand anderen daran arbeiten.

In Bibliotheken wie Github, NPM und Maven legen Open-Source-Entwickler von ihnen erstellte Projekte ab, z. B. Dienstprogramme, damit andere sie herunterladen und in ihre eigenen Anwendungen implementieren können. Normalerweise sind diese Projekte kostenlos. Sicherheits- und Funktionsupdates werden nach Ermessen des Entwicklers veröffentlicht.

Wenn die Protesttheorie richtig ist, weist der Vorfall einige Ähnlichkeiten mit der Kontroverse vom letzten Monat auf, als Schwachstellen in den log4j2-Bibliotheken von Apache entdeckt wurden, sagte Carielli.

„Eines der Dinge, die bei log4j in den Vordergrund gerückt sind – und ich sage, es ist nicht das erste Mal, dass dies passiert ist – ist die Tatsache, dass es kritische Open-Source-Komponenten gibt, die von unzähligen Entwicklern auf der ganzen Welt verwendet und aufgerufen werden , [but] werden oft von einem oder zwei Entwicklern gepflegt. Sie erledigen die ganze Arbeit und erhalten weder Unterstützung noch finanzielle Unterstützung oder zusätzliche Hilfe von anderen Entwicklern, um sich die ganze Zeit um sie kümmern zu können.

Es gebe “ein gewisses Maß an Missbrauch und Ungeduld gegenüber den Entwicklern” von log4j, bemerkte sie, obwohl sie versuchten, ihre Bibliotheken so schnell wie möglich zu aktualisieren und zu reparieren. “Diese Reaktion hat die Frage aufgeworfen, wie wir kritische Projekte in der Open-Source-Community schützen und unterstützen.”

Die gleiche Frage werde über den Entwickler der „Colors“/„Faker“-Bibliotheken gestellt, sagte sie.

Zufälligerweise veröffentlichte die Apache Software Foundation eine Position vor dem Software-Sicherheitstreffen im Weißen Haus am Donnerstag, das sich teilweise darüber beschwerte, dass Unternehmen, die Open Source zu ihren Produkten hinzufügen, sich selten an der laufenden Wartung beteiligen.

Die Frage der Notwendigkeit, diejenigen zu entschädigen, die Open-Source-Anwendungen erstellen, wurde viel diskutiert in einem Bericht von 2016 für die Ford Foundation. „Ohne effektive Unterstützung für die Arbeit von Programmierern an öffentlich zugänglichen Projekten wird ihre Arbeit nicht nur unbezahlt bleiben, sondern die digitale Welt riskiert Sicherheitsverletzungen, Dienstunterbrechungen und verlangsamte Innovationen“, heißt es in einer Zusammenfassung des Berichts.

Auch die Frage nach der Nachhaltigkeit von Open Source wurde gestellt in diesem Blog 2019 angesprochen vom Open-Source-Produktmanager von GitHub. Und vor einem Jahr der Softwareentwickler James Turner warf einen Blick auf die Finanzierungsfrage in diesem Blog.

DevSecOps wird im Jahr 2022 ein großes Gesprächsthema sein, da Unternehmen beginnen, die Bedeutung des Einbaus von Sicherheit in Anwendungen viel früher im Entwicklungsprozess zu verstehen, Justin Stolz, DRegisseur von vsyber ichIntelligenz u einAnalytik bei Darktrace, sagte ITWorldCanada. “Die Risiken, die sich aus der Abhängigkeit von Open Source ergeben, werden Entwicklungsteams in den Vordergrund stellen, insbesondere nach Log4J. Dieses Problem erfordert Cyber-Abwehrtechnologie, um Schwachstellen zu erkennen, wenn Bedrohungsakteure sie ausnutzen. Unternehmen müssen in der Lage sein, sich gegen jedes potenzielle Risiko zu verteidigen, das sie durch Drittanbieter und Plattformen einführen.“

App-Entwickler, die befürchten, von Problemen mit Open-Source-Code gebissen zu werden, verfügen über eine breite Palette von Tools zur Analyse der Softwarezusammensetzung (SCA), die Softwarecode auf Schwachstellen untersuchen können, stellte Carielli fest , und JFrog,

Ron Bash, Vizepräsident der Technischen Forschung bei aDolus Corp., ein Hersteller einer Lösung, die Softwarekomponenten scannt und bewertet, aus Victoria, B.C., sagte, der „Color“/„Faux“-Entwickler scheine es – wie andere – leid zu sein, in seiner Freizeit kostenlos an einem Open-Source-Projekt zu arbeiten.

„Ich entschuldige dieses Verhalten nicht“, fügte er hinzu. „Was ich sagen will, ist, dass es sicherlich verständlich und für ein breiteres Publikum von Open-Source-Paketen zugänglich ist.“

Was Entwickler betrifft, die sich jetzt Sorgen um Open-Source-Code machen, war Bash unsympathisch. „Softwareentwickler glauben normalerweise nicht, dass Sicherheit für sie gilt“, sagte er. „Sie sind sich dessen bewusst, aber sie denken, es ist das Cybersicherheitsteam, es ist das Testteam [responsibility] … Software-Ingenieure müssen auch bewusst Risiken eingehen … anstatt blind eine Bibliothek zu importieren oder Code zu kopieren und einzufügen und seine Abhängigkeiten zu akzeptieren. Sie sollten sich der Komponenten von Drittanbietern bewusst sein, den Code nach Möglichkeit überprüfen, Updates verzögern und überprüfen, bevor sie ihren Apps hinzugefügt werden.

Dies ist nicht das erste Mal, dass das Temperament eines Open-Source-App-Entwicklers andere verletzt, bemerkte Mei Nagappan, Assistenzprofessorin an der University of Waterloo. Cheriton School of Computing.

Im Jahr 2016 funktionierten Hunderte von Apps plötzlich nicht mehr, angeblich weil ein Entwickler gebeten wurde, den Namen einer JavaScript-Bibliothek zu ändern, die er erstellt und auf NPM veröffentlicht hatte. Offenbar unzufrieden mit der Anfrage hat der Entwickler die Veröffentlichung der Codemodule rückgängig gemacht. Dies sei unabhängig von der Anzahl der Schwachstellen in NPM-Paketen, die letztes Jahr entdeckt wurden, fügte Nagappan hinzu.

“Obwohl solche Probleme auftreten”, sagte er in einer E-Mail, “sind sie zumindest an der Öffentlichkeit. Die Lösung ist schnell. Wenn Sie genauer lesen, haben Unternehmen möglicherweise abgezweigt [the ‘colors’ and ‘faker’ code] und benutzte stattdessen die Gabel.

„Menschen, die etwas zu verlieren haben, müssen möglicherweise auch in das investieren, was sie verwenden“, fügte er hinzu.

Zu der Frage, ob dieser Vorfall das Vertrauen in Open-Source-Code mindert, merkte Nagappan an, dass auch kommerzielle Software ihren Anteil an Problemen habe.

Ein Beispiel sei die jüngste Kompromittierung des Orion-Update-Mechanismus von SolarWinds.