Abhängigkeits-Advisories stellt eine enge, überprüfbare Frage: Tauchen die Abhängigkeitsversionen, zu denen dieses Repository tatsächlich auflöst, in veröffentlichten Sicherheitshinweisen auf?
Die Metrik trägt 20% der Kategorie Sicherheit, neben der Sicherheitslage mit 80%.
Das Gewicht ist bewusst zurückhaltend. Eine Kalibrierung an sechzehn weit verbreiteten Paketen fand fünfzehn ganz ohne bekannte Advisories: gut gepflegte Projekte liefern tatsächlich keine verwundbaren Abhängigkeiten aus, ein sauberes Ergebnis ist hier also die Regel und keine Auszeichnung.
Was gemessen wird: was ein Konsument installiert
Für ein Repository, das ein Paket veröffentlicht, ist der bewertete Satz dessen Laufzeit-Abhängigkeitshülle – jedes Paket, das eine Installation tatsächlich nach sich zieht, direkt und transitiv –, aufgelöst aus dem offenen Index deps.dev. Der Bericht nennt das exakt bewertete Paket und dessen Version.
Nur wo ein Repository nichts veröffentlicht, greift die Prüfung auf den eigenen Abhängigkeitsgraphen des Repositorys zurück. Dieser Graph ist etwas anderes: er enthält zusätzlich Entwicklungs- und Test-Pins, die kein Installer je herunterlädt. Berichte in diesem Bereich weisen das aus.
Der Unterschied ist nicht akademisch. Flasks Graph enthält alte Werkzeug- und Jinja-Versionen, die das Projekt bewusst zum Testen pinnt; sie tragen Advisories, und keine davon erreicht jemanden, der Flask installiert. Die veröffentlichte Hülle umfasst sechs Pakete, keines betroffen.
Hüllen sind derzeit für Pakete aus npm, PyPI, crates.io und Maven auflösbar. Repositories, die nach Go, NuGet, RubyGems, Packagist oder Hex veröffentlichen, werden gegen ihren Repository-Graphen bewertet, bis der Index sie abdeckt – eine Grenze der Datenquelle, kein Urteil über diese Ökosysteme.
Woher die Daten stammen
Jede Prüfung liest den aufgelösten Abhängigkeitssatz des Repositorys – die direkten Abhängigkeiten plus die transitive Hülle darunter – aus dem Abhängigkeitsgraphen, den die Hosting-Plattform ohnehin aus eingecheckten Manifesten und Lock-Dateien berechnet.
Dieser Satz wird mit OSV abgeglichen, der offenen Advisory-Datenbank der Open Source Security Foundation, die GitHub Security Advisories, PYSEC, RUSTSEC, die Go-Schwachstellendatenbank und weitere unter einem Schema zusammenführt. OSV ist kostenlos, öffentlich und versioniert – dieselben Eigenschaften, die die Scorecard zu einer vertretbaren Grundlage für die Sicherheitslage machen.
Dieselbe Abfrage liefert auch Pakete zurück, die als schädlich gemeldet sind. Das sind keine Schwachstellen, und hier werden sie nicht gezählt: Sie tragen weder einen Schweregrad noch eine korrigierte Version und werden getrennt als schädliche Abhängigkeiten ausgewiesen und bewertet. Ein Paket, das dort erscheint, taucht nicht zusätzlich in den Zahlen dieser Seite auf.
Was ausgewiesen wird
Für jedes betroffene Paket: die aufgelöste Version, ob es sich um eine direkte oder indirekte Abhängigkeit handelt, der schwerste Schweregrad unter seinen Advisories, wie viele Advisories greifen, deren Kennungen und – sofern das Advisory sie nennt – die Version, in der das Problem behoben wurde.
Der Schweregrad stammt aus der Kennzeichnung der Advisory-Datenbank selbst. Datensätze ohne eine solche Angabe, bei PYSEC-Einträgen häufig, werden als unbekannt ausgewiesen statt mit einem geratenen Wert versehen.
Wie bewertet wird
Drei Komponenten:
| Komponente | Gewicht |
|---|---|
| Direkte Abhängigkeiten ohne bekannte Advisories | 35 |
| Indirekte Abhängigkeiten ohne bekannte Advisories | 25 |
| Keine offen gebliebenen Advisories | 40 |
Direkte wiegen schwerer als transitive, weil sie die erklärte eigene Wahl des Projekts sind; transitive kommen mit ihnen mit.
Der Schweregrad ist der veröffentlichte CVSS-Basiswert, keine grobe Kennzeichnung. Jedes betroffene Paket steuert seinen Wert auf einer Skala von 0 bis 1 bei. Die datenbankeigenen Bezeichnungen dienen nur dort, wo ein Advisory keinen CVSS-Vektor veröffentlicht.
In den ersten beiden Komponenten dominiert der schlechteste Einzelfund, das verbleibende Volumen wiegt zunehmend weniger. Eine Abhängigkeit kritischen Schweregrads kostet rund drei Viertel ihrer Komponente; acht niedrigen Grades etwa ein Drittel. Diese Ordnung ist gewollt – hundert triviale Advisories sind nicht ein kritisches wert – und der Volumenterm treibt eine Komponente nie auf null, sodass ein Projekt mit 300 Funden weiterhin unter einem mit 30 liegt, statt mit ihm gleichzuziehen.
Die dritte Komponente fragt etwas anderes: wie lange ist die Behebung schon verfügbar? Von einem letzte Woche veröffentlichten Advisory getroffen zu werden, ist Pech. Weiterhin auf eine Version aufzulösen, die von einem vor einem Jahr veröffentlichten betroffen ist, ist ein Versäumnis in der Abhängigkeitspflege. Ein Paket zählt hier, sobald sein ältestes Advisory die 90 Tage überschreitet. Trägt kein Advisory ein Veröffentlichungsdatum, wird die Komponente ausgeschlossen und ihr Gewicht renormalisiert – nie als sauber unterstellt.
Ein Satz ohne bekannte Advisories erhält in allen dreien die volle Punktzahl.
Abdeckung wird ausgewiesen, nie unterstellt
Manche Einträge eines Abhängigkeitsgraphen tragen keine erfasste Version. Ein Paket ohne Version lässt sich nicht gegen einen Versionsbereich prüfen, wird also übersprungen und gezählt – jeder Bericht nennt, wie viele Abhängigkeiten bewertet wurden und wie viele nicht.
Repositories, deren Abhängigkeitsgraph nicht verfügbar oder abgeschaltet ist, werden nicht bestraft. Die Metrik wird ausgeschlossen und das verbleibende Sicherheitsgewicht renormalisiert, genau wie bei jeder anderen nicht verfügbaren Eingabe – siehe der Gesundheitsindex.
Was diese Metrik nicht behauptet
Ein Advisory bedeutet hier genau eines: die im Abhängigkeitsgraphen erfasste Version fällt in den betroffenen Bereich eines Advisories.
Es bedeutet nicht, dass der verwundbare Codepfad aus diesem Projekt heraus erreichbar ist, und nicht, dass das Projekt ausnutzbar ist. Die meisten Advisories in einer großen transitiven Hülle sind im jeweiligen Kontext nicht ausnutzbar.
Ebenso wenig unterscheidet sie, was ein Projekt ausliefert, von dem, womit es sich baut und testet. Ein Abhängigkeitsgraph enthält Entwicklungs- und Test-Pins, und ein Repository, das bewusst gegen eine alte Bibliotheksversion testet, wird diese Version hier zeigen. Die Aufteilung direkt/indirekt ist der beste verfügbare Näherungswert und wird je Fund ausgewiesen – ein Näherungswert bleibt sie dennoch.
Zu lesen zusammen mit Signale, keine Garantien: ein sauberes Ergebnis ist keine Sicherheitsgarantie, und ein Fund ist ein Anlass hinzusehen, kein Urteil.
Warum getrennt von der Sicherheitslage
Scorecards eigene Vulnerabilities-Prüfung fragt dieselbe Advisory-Datenbank ab und fließt bereits in die Sicherheitslage ein. Ein zweites aus OSV abgeleitetes Signal innerhalb derselben Metrik zu bewerten würde denselben Befundkörper doppelt zählen.
Die Trennung hält beide auch ehrlich hinsichtlich ihrer unterschiedlichen Granularität. Die Sicherheitslage fragt, ob ein Projekt überhaupt bekannte verwundbare Abhängigkeiten trägt – als eine Prüfung unter neunzehn. Diese Metrik fragt, welche Pakete, mit welchem Schweregrad und in welcher Version behoben: die Form, die eine Antwort annehmen muss, bevor jemand danach handeln kann.