als Abhängigkeit automatisch runtergeladen wird.
Und der dann im selben Gottvertrauen ohne alle Sicherheitsvorkehrungen sofort benutzt wird.
So etwas ist eine tickende Zeitbombe, und Vorfälle wie der im Artikel erwähnte sind nur ein "accident waiting to happen".
Mich hat diese Gefahr bereits bei der Eclipse IDE davon Abstand nehmen lassen, sie zu verwenden. Denn auch dort werden unzählige Plug-Ins automatisch als Abhängigkeiten von irgendwo her runtergeladen und sofort installiert und benutzt, ohne dass man eine Chance hat vorher zu überprüfen ob sich darunter vielleicht bösartiger Code versteckt.
Die Situation bei Eclipse war sogar insofern noch schlimmer als bei npm, als die Plug-ins nicht einmal als Quelltexte sondern bereits compiliert herunter geladen wurden und es keine (zumutbar einfache) Methode gab zu erzwingen dass sie zumindest am lokalen Rechner automatisch kompiliert wurden.
Weitere prominente Fälle wo ähnliche Gefahr wie bei npm besteht ist der "cargo" Paketmanager von Rust. (Immerhin hat man hier aber zuvor die Gelegenheit die Änderungen am Quellcode zu betrachten - was aber nur etwas bringt wenn man es auch tatsächlich tut.)
Aber auch virtualiserte Container die einfach in binärer Form von irgend einem Repository heruntergeladen und sofort in Dienst genommen werden, stellen dasselbe Risiko dar.
Verallgemeinert gilt die Gefahr für alle Anwendungs-spezifischen Paketmanager, die "an der OS-Distribution vorbei" irgendwelchen Code lokal installieren, ohne dass die Paketmanager dieselben Sicherheitsmaßnahmen treffen wie die Security-Teams von OS-Distributionen um solchen Gefahren vorzubeugen.
Sprich auch CPAN, LuaRocks, ZeroInstall um nur ein paar prominente Beispiele zu nennen.
Bzw. alle Plugin- und Extensions-Repositories allgemein, wie etwa Browser-AddOns.
Und noch allgemeiner sind alle Code-Verbreitungs-Plattformen wie SourceForge oder GitHub von diesem Problem grundsätzlich ebenfalls betroffen.
In alle diesen Fällen muss man sich immer bewusst sein: Niemand hindert den Autor einer neuen Container-Version, eines binären Paket-Updates oder einer neuen Souce-Code-Commits daran, Schadcode hochzuladen.
Da diese Gefahr daher praktisch *immer* besteht wenn man irgend etwas von irgendwo herunterlädt, sind es die Sicherheitsmaßnahmen die man beim Herunterladen trifft welche den Unterschied zwischen akzeptablem Risiko und purem Leichtsinn ausmachen.
Die simpelste Methode ist es die Verantwortung an jemand anderen zu delegieren dem man vertraut.
Das kann z. B. das Security Team der OS-Distribution sein die man verwendet.
Die Security Teams von Debian Linux oder OpenBSD sind z. B. dafür bekannt gute Arbeit zu leisten.
Das Security Team von Google wiederum ist zwar sogar noch viel besser darin Sicherheitslücken zu finden, allerdings muss man bei Google mehr Angst vor vorsätzlich eingebauten Sicherheitsbedrohungen haben als vor irrtümlichen nach denen das Security Team Ausschau hält.
Letztendlich sollte man die Vertrauenswürdigkeit einer Distribution (egal ob von einem OS, von einem Container-Repository, oder von Source-Code Modulen wie eben npm) immer von den folgenden Faktoren abhängig machen:
* Security Track Record - sind in der Vergangenheit schon Vorfälle von bösartig hochgeladenem Code bekannt geworden der dann auch tatsächlich an Benutzer verteilt wurde? Dasselbe gilt aber ebenso auch für allgemeine Sicherheitslücken, wie insbesondere Zero-Day Exploits.
* Ist der Download vom Repository auf den lokalen Rechner ausreichend gegen Manipulationen auf dem Transportweg geschützt? Das können digital signierte Paketprüfsummen sein, oder einfach nur TLS bei dem auch sicher gestellt ist dass die Zertifikate geprüft werden.
* Gibt es eine Testperiode zwischen dem Hochladen ins Repository und dem Zeitpunkt, an dem Endbenutzer die Paket von dort herunterladen können? Und wenn ja, wie lange ist diese?
In der Praxis dürfte der letzte Punkt mit Abstand der wichtigste sein: Angreifer sind in der Regel nicht all zu geduldig, sondern haben ein konkretes Anliegen warum sie den Schadcode hochgeladen haben.
Sie wollen ihn daher baldestmöglich ausnutzen, und warten daher nur so lange bis eine kritische Masse an Anwendern sich den Schadcode herunter geladen hat.
Je länger daher der Zeitpunkt zwischen der Veröffentlichung einer neuen Version und der Verwendung davon ist, desto geringer die Wahrscheinlichkeit dass sich Malware darin versteckt.
Daher sind Distributionen wie Arch Linux welche ständig hochaktuelle Software bereit stellen viel gefährdeter als eine Distribution wie Debian wo die meisten Benutzer den "Stable"-Bezugskanal mit "gut abgelegenen" Software-Versionen benutzen um ihre Updates herunter zu laden.
Diese "gute Abgelegenheit" von Software von Debian ist dabei keine Faulheit der Distro-Maintainer wie etliche Leute zu glauben scheinen, sondern eine direkte Folge der längeren Testperiode welcher neue Paketversionen dort unterzogen werden.
Doch nach der Kritik zu Verbesserungs-Vorschlägen: Was könnten npm, Eclipse, cargo & Co tun um besser zu werden?
Essenziell dafür wäre meiner Ansicht nach die Einrichtung eines Systems unterverschiedlicher Bezugs-Kanäle, genau wie die Branches "sid", "testing", "stable" von Debian.
Dabei muss der Entwickler die Wahl haben welchen Bezugskanal er abonniert, und er bezieht dann seine Updates immer nur aus jenem Kanal.
Wie man die Kanäle nennt und wie viele es gibt ist dabei zweitrangig. Wichtig ist nur dass es eine klar erkennbare Reihenfolge gibt, wie die Pakete aus den "schnelleren" in immer "langsamere" Kanäle weiter wandern - ähnlich wie ein zunächst reißender Strom, der immer wieder in größere Flüsse einmündet bis der letzte Fluss den die meisten Anwender benutzen nur noch ganz gemächlich daher fließt.
Statt der Fließgeschwindigkeit verwenden die Distro-Kanäle dabei die Verweildaueren in den einzelnen Kanälen, bevor Pakete in den jeweils nächsten Kanal weiter wandern.
Dabei sollte es für Security-Updates möglich sein, mehrere Kanäle parallel zu abonnieren.
Denn wenn ein Sicherheitsleck in einem alten Paket bekannt wird, muss das natürlich sofort gefixed werden; für solche Fälle gibt es daher eigene Kanäle die nur für solche Situationen gedacht sind und Priorität gegenüber den normalen haben.
Dieses System hat sich bei Debian über die Jahre hinweg sehr bewährt, und es gibt keinen Grund anzunehmen dass er bei anderen Repositories nicht genau so funktioneren würde.
Es handelt sich daher eher um organisatorische als technische Maßnahmen, die man ergreifen muss um Probleme den im Artikel genannten zu vermeiden.