Eine verwundbare Abhängigkeit ist ein Fehler. Eine schädliche Abhängigkeit ist ein Angriff. Das sind nicht dieselben Befunde, und dieses Register bewertet sie nicht auf dieselbe Weise.
Schädliche Abhängigkeiten stellt eine einzige Frage: Enthält der Abhängigkeitsgraph, zu dem dieses Repository auflöst, ein Paket, das als Schadsoftware gemeldet wurde?
Woher die Belege stammen
Die Quelle ist der OpenSSF-Korpus malicious-packages – ein offen lizenziertes, von der Community gepflegtes Verzeichnis von Paketen, die in öffentlichen Registries als schädlich befunden wurden: Typosquats, Kontoübernahmen, Dependency-Confusion-Angriffe und Pakete, die vorgefertigte schädliche Binärdateien ausliefern.
OSV.dev übernimmt diesen Korpus und liefert ihn unter MAL--Kennungen neben gewöhnlichen Sicherheitshinweisen aus. Da dieses Register OSV ohnehin für Abhängigkeits-Advisories abfragt, treffen schädliche Pakete auf einer Abfrage ein, die bereits gestellt wurde. Der Befund kostet keine zusätzliche Anfrage, keine zusätzliche Wartezeit und keine zusätzliche Abhängigkeit von einem Dritten.
Warum getrennt von den Advisories bewertet wird
Bis zur Methodikversion v1.10.0 wurden diese Meldungen als gewöhnliche Advisories gezählt, und das war auf eine Weise falsch, die klar benannt gehört.
Die Meldung eines schädlichen Pakets trägt keinen CVSS-Vektor und keine Schweregrad-Kennzeichnung – es gibt nichts zu bewerten, denn Schadsoftware hat keinen Schweregrad, sondern nur einen Zustand. Als Advisory bewertet, fiel sie auf den Schweregrad unknown durch, der wie eine moderate Schwachstelle gewichtet wird. Ein Paket, von dem festgestellt worden war, dass es Zugangsdaten stiehlt, zählte damit etwas weniger als ein durchschnittlicher CVE.
Die drei Eigenschaften, die eine Schwachstelle bewertbar machen, fehlen sämtlich:
- Keine korrigierte Version. Es gibt kein korrigiertes Release desselben Artefakts, auf das aktualisiert werden könnte. Die Abhilfe ist das Entfernen oder der Wechsel weg vom kompromittierten Namen.
- Keine teilweise Exposition. Eine Schwachstelle kann in einem nicht erreichbaren Codepfad liegen. Eine beim Installieren ausgeführte Nutzlast läuft, sobald das Paket installiert wird.
- Keine Abstufungen. Ein Paket ist entweder als schädlich gemeldet oder nicht.
Eine schädliche Abhängigkeit wird daher vollständig aus den Advisory-Befunden entfernt und als Negativbefund behandelt: als Multiplikator und Obergrenze statt als Punktabzug. Sie wendet einen Multiplikator von 35% auf den Wert der Sicherheitslage und auf den gewichteten Gesundheitsindex an und begrenzt beide auf 29 – die Obergrenze der Stufe Kritisch. Das ist eine Stufe strenger als die Grenze von 49 bei Hochrisikojurisdiktionen, denn hier liegt eine bestätigte Kompromittierung der Software vor und nicht die Exposition gegenüber einem Risiko.
Ein Paket, das sowohl eine Schadsoftware-Meldung als auch gewöhnliche CVEs trägt, erscheint allein unter diesem Befund. Seine Schwachstellen sind gegenstandslos.
Zurückgezogene Artefakte werden ausgewiesen, nicht bewertet
Eine Registry, die ein schädliches Paket entfernt, klärt die Frage: Es bleibt nichts Installierbares, und ein Repository, das darauf auflöst, liefert heute keine Schadsoftware aus. Jeder Befund prüft daher, ob die Registry genau diese aufgelöste Version noch ausliefert. Ist das nicht der Fall, bleibt der Befund im Bericht stehen – das Projekt hängt an einem Namen, der kompromittiert war, und das gehört gesehen –, aber er löst keinen Negativbefund aus und kostet keine Punkte.
Die Prüfung fragt bewusst nach der aufgelösten Version und nicht nach der neuesten des Pakets. Nach einer Entfernung lässt npm ein Platzhalter-Release, gekennzeichnet mit -security, als neueste Version des Pakets zurück. Das schützt alle, die einen Versionsbereich auflösen, und niemanden, der die schlechte Version exakt festgeschrieben hat. Die neueste Version zu lesen hätte das erste Repository freigesprochen, bei dem dieser Befund je anschlug – es pinnt das kompromittierte Paket genau auf die Version, die die Registry weiter ausliefert.
Wo die Frage nicht beantwortet werden kann – ein Ökosystem, das die Prüfung nicht abdeckt, oder eine Registry, die nicht antwortete –, wird der Befund bewertet, als wäre das Paket weiterhin verfügbar. Eine Registry nicht zu erreichen ist kein Beleg dafür, dass Schadsoftware zurückgezogen wurde.
Direkte und indirekte zählen gleich
Die Abhängigkeitsbewertung dieses Registers unterscheidet sonst weitgehend zwischen einer erklärten direkten Abhängigkeit und einer transitiv hereingezogenen, weil ein Maintainer die erste gewählt und die zweite geerbt hat.
Diese Unterscheidung greift hier nicht. Das Installationsskript eines Pakets läuft in jeder Tiefe, in der das Paket im aufgelösten Graphen sitzt; ein Zugangsdaten-Dieb vier Ebenen tiefer kompromittiert die Maschine genauso gründlich wie einer, der im Manifest steht. Beide werden ausgewiesen, beide werden bewertet, und der Bericht nennt, welches von beidem vorliegt, damit erkennbar bleibt, wo das Paket eingetreten ist.
Was der Befund nicht behauptet
Er ist kein Vorwurf gegen die Maintainer. Die Meldung betrifft das Paket in seiner veröffentlichten Form, von wem auch immer es veröffentlicht wurde. Ein Repository löst zu Tausenden von Paketen auf, die es nie geprüft hat; ein kompromittiertes zu erben, ist der normale Hergang und sagt nichts über Absicht oder Kompetenz der Menschen aus, die das geprüfte Repository pflegen.
Er ist keine Behauptung, dass der Code ausgeführt wurde. Der Befund sagt, dass der aufgelöste Abhängigkeitsgraph das Paket enthält. Ob irgendwer genau diesen Graphen installiert hat und was die Nutzlast dann getan hat, liegt außerhalb dessen, was ein öffentliches Register beobachten kann.
Er ist nicht unsere Feststellung. Die Einstufung ist die des OpenSSF-Korpus, erreicht über dessen eigenes Verfahren und dessen eigene Quellen; dieses Register weist sie aus, statt sie nachzuvollziehen. Eine stromaufwärts zurückgezogene Meldung verschwindet mit dem nächsten Scan.
Wie oft er anschlägt
Selten – konstruktionsbedingt und nachgemessen. Vor der Einführung dieser Metrik wurde sie über eine Stichprobe von 300 Repositories mit 46.889 aufgelösten Abhängigkeiten laufen gelassen und fand nichts.
Das ist das erwartete Ergebnis und kein Zeichen dafür, dass die Prüfung nutzlos wäre. Registries entfernen schädliche Pakete innerhalb von Stunden bis Tagen nach der Entdeckung, sodass eine Lock-Datei, die noch zu einem auflöst, ungewöhnlich ist. Der Wert dieses Befunds liegt nicht darin, dass er häufig anschlägt; er liegt darin, dass er, wenn er anschlägt, die mit Abstand wichtigste Tatsache des Berichts ist – und nicht länger in einen Schwachstellenwert eingemittelt wird.
Wann er nicht bewertet wird
Wie Abhängigkeits-Advisories wird diese Metrik ausgeschlossen – nicht mit null bewertet –, sobald der Abhängigkeitsgraph oder die OSV-Abfrage nicht verfügbar war. Ein Repository wird nie dafür bestraft, dass GitHubs Abhängigkeitsgraph abgeschaltet ist; der Bericht sagt, dass die Prüfung nicht lief, statt ein sauberes Ergebnis zu suggerieren.