Methodik

Diese Seite ist die menschenlesbare Spezifikation, wie jeder Wert im öffentlichen Register berechnet wird. Die Methodik ist als Ganzes versioniert – aktuell v1.13.0 –, und jeder Bericht vermerkt die Version, die ihn erzeugt hat. Die Details je Metrik stehen im Wiki; diese Seite beschreibt das System.

Die standardisierte Skala

Jede Messung – Komponente, Metrik, Kategorie, Gesamtwert – ist eine ganze Zahl in 1–100, höher ist besser, abgebildet auf fünf standardisierte Bewertungsstufen: exzellent (85–100), gut (70–84), mittel (50–69), gefährdet (30–49), kritisch (1–29). Die Stufengrenzen sind Teil der versionierten Methodik.

Die dreistufige Hierarchie

Werte aggregieren sich transparent: Komponenten → Metriken → Kategorien → Gesamtwert (im Detail im Gesundheitsindex).

1. Eine Metrik ist eine gewichtete Summe von Komponenten; die Komponentengewichte summieren sich zu 100. Jede Komponente wird mit erreichten und maximalen Punkten sowie einem Status ausgewiesen – erfüllt, teilweise erfüllt, verfehlt oder ausgeschlossen. Vier dokumentierte Richtlinien bilden die Ausnahme: eine als schädliches Paket gemeldete Abhängigkeit multipliziert und begrenzt die Sicherheitslage, bestätigte Exposition gegenüber einer Hochrisikojurisdiktion tut dasselbe bei einer lockereren Obergrenze, ein bestätigter Befund unorganischen Wachstums wertet die Komponenten Stars und Forks der Popularität ab, und ein Verwaisungsbefund multipliziert den Gesundheitsindex selbst.
2. Eine Kategorie ist normalerweise das gewichtete Mittel ihrer verfügbaren Metriken. Alle vier Richtlinien sind reine Abzugsmultiplikatoren – keine kann die Metrik verbessern, auf die sie wirkt, und keine trägt ein eigenes additives Gewicht.
3. Der Gesamt-Gesundheitsindex beginnt als gewichtetes Kategorienmittel. Wo eine Richtlinie greift, wendet sie ihren Multiplikator an, und einige setzen zusätzlich eine Obergrenze: 29 (kritisch) bei einer schädlichen Abhängigkeit oder einer erklärten Verwaisung, 49 (gefährdet) bei Exposition gegenüber einer Hochrisikojurisdiktion oder einer wahrscheinlichen Verwaisung. Greifen mehrere, gilt allein die strengste – sie multiplizieren sich nie auf.

Fehlende Daten sind niemals eine Null

Sind die zugrunde liegenden Daten einer Komponente nicht verfügbar, wird sie ausgeschlossen und die verbleibenden Gewichte werden renormalisiert – ein Projekt wird nur an dem gemessen, was beobachtet werden kann. Dieselbe Regel gilt für ganze Metriken und Kategorien, und jede Renormalisierung wird im Hinweis der betroffenen Metrik vermerkt.

Negativbefunde

Die meiste Evidenz in dieser Methodik wird bewertet: Sie bringt Punkte, diese Punkte summieren sich zu einer Metrik, und die Metrik geht als Mittel in eine Kategorie ein. Ein Negativbefund ist die Ausnahme – ein Befund, der nicht in einen Wert einfließt, sondern ihn anpasst, und den der Bericht als benannte Warnung ausweist statt als Zahl.

Diese Klasse existiert, weil sich manche Befunde nicht redlich wegmitteln lassen. Eine als schädlich gemeldete Abhängigkeit sind nicht acht Punkte Engineering-Praxis; sie ist ein Zustand. Stars, die nach einem Lieferplan eintrafen, sind kein niedriger Popularitätswert; sie sind ein Grund, dem Zähler nicht länger zu glauben. Beides als Punktabzug zu verbuchen, hieße, dass ein starkes Abschneiden an anderer Stelle es aufsaugen kann – genau das falsche Ergebnis.

Jeder Negativbefund dieser Methodik gehorcht denselben fünf Regeln:

1. Er bewegt einen Wert ausschließlich nach unten. Kein Negativbefund trägt additives Gewicht, und ein sauberes Ergebnis erhöht nie etwas. Das Ausbleiben eines Befunds ist kein Ausweis.
2. Er wird benannt, nicht bloß abgezogen. Der Befund erscheint als Warnung im Bericht, benennt seine Evidenz und verweist auf den Leitfaden, der ihn definiert. Es muss erkennbar sein, warum sich eine Bewertung verschoben hat.
3. Er beschreibt eine Beobachtung, nie eine Absicht. Jeder ist eine Aussage über öffentliche Evidenz – ein Standort, den ein Profil veröffentlicht hat, ein Paket, das eine Advisory-Datenbank benennt, der zeitliche Verlauf von Star-Ereignissen. Keiner belegt Motiv, Verantwortlichkeit oder Fehlverhalten irgendeiner Person.
4. Unbeantwortbar ist nicht sauber. Wo die Evidenz, die ein Befund benötigt, nie erhoben wurde, sagt der Bericht das. Ein Repository, das nicht bewertet werden konnte, wird nie als eines dargestellt, das bestanden hat.
5. Nur der strengste gilt. Wo mehr als ein Negativbefund greift, bestimmt der schwerwiegendste den Wert allein, und die übrigen werden ausgewiesen, ohne ihn erneut zu bewegen. Ein Multiplikator sagt aus, wie schwer ein Befund wiegt; mehrere miteinander zu multiplizieren erzeugt eine Zahl, die keine Richtlinie gewählt hat.

Derzeit definiert sind die Richtlinie zu unorganischem Wachstum, die Richtlinie zur Verwaisung, die Richtlinie zu schädlichen Abhängigkeiten und die Richtlinie für Hochrisikojurisdiktionen, jeweils weiter unten spezifiziert. Wie häufig jede im gesamten Register auftritt, wird in den aggregierten Statistiken veröffentlicht.

Repository-Kategorien und Gewichte

Richtlinie zu unorganischem Wachstum

Ein GitHub-Star ist das meistgelesene Vertrauenssignal in Open Source und das einzige ohne Aussteller: Stars und Forks werden offen und in großen Mengen verkauft. Der für jeden Bericht erhobene Tagesverlauf von Stars und Forks wird daher auf Wachstum gelesen, dessen Form organische Aufmerksamkeit nicht hervorbringt – ein Schub, der nach Zeitplan eintraf, keine Forks mit sich brachte, keinen Ausläufer hinterließ oder allem vorausging, was das Projekt veröffentlicht hatte.

Ein Schub allein ist nie ein Befund; reale Projekte starten und liegen im Trend. Ein Fenster gilt erst dann als bestätigt, wenn mindestens zwei unabhängige Signale es erhärten. Ein bestätigtes Fenster wertet die Komponenten Stars und Forks der Popularität um 40% ab, zwei oder mehr um 70%. Watcher und alle anderen Kategorien bleiben unberührt, und ein sauberer Verlauf erhöht einen Wert nie.

Repositories, deren erhobener Verlauf die Frage nicht beantworten kann – kein Verlauf, weniger als 100 Stars oder ein Fenster von weniger als 60 Tagen –, lesen sich als nicht verifiziert und werden nicht abgewertet. Die Erhebung ist auf ein jüngeres Fenster begrenzt, sodass ältere Manipulation für die Richtlinie unsichtbar bleibt; nicht verifiziert bedeutet unbeantwortbar, nicht sauber. Der vollständige Leitfaden zur Wachstumsauthentizität nennt die Schwellwerte, die vier Zustände und die Grenzen der Evidenz.

Das ist eine Aussage über den zeitlichen Verlauf öffentlicher Ereignisse. Sie belegt weder, dass Aufmerksamkeit gekauft wurde, noch, dass die Maintainer eines Repositorys daran beteiligt gewesen wären.

Richtlinie zur Verwaisung

Ein Projekt ist nicht verwaist, weil es still ist. Jedes Werkzeug in diesem Feld beantwortet die Frage „ist das tot?“ mit Tagen seit dem letzten Commit, und jedes irrt sich bei denselben Projekten: Eine kleine, vollständige Bibliothek, die seit drei Jahren keinen Commit brauchte, ist fertig, nicht verwaist.

Der Befund beruht deshalb auf einer anderen Frage – Verwaisung ist eine unerfüllte Pflicht, nicht die Abwesenheit von Lärm. Ein stilles Repository ohne Offenes schuldet niemandem etwas. Ein stilles Repository mit fünfzehn ungeprüften Pull Requests oder einem jahrealten Advisory, dessen Patch in derselben Woche erschien, ruht nicht.

Stille ist notwendig und nie hinreichend. Eine Dürre wird ab dem letzten menschlichen Commit gemessen und wird erst dann zum Befund, wenn unerfüllte Pflichten sie erhärten: eine unbeantwortete Beitragswarteschlange, Issues, auf die nie eine Betreuung antwortete, ein nicht behobenes Advisory in einer direkten Abhängigkeit, ein an der eigenen Taktung des Projekts gemessener Release-Stillstand, eine fehlschlagende oder jahrealte CI, oder ein einziger Betreuer, der im gesamten Commit-Fenster fehlt. Lesarten, die die Stille erklären – eine Betreuung, die im Tracker antwortet, nichts Offenes zu beantworten, ein Release innerhalb des Jahres, saubere Abhängigkeiten –, halten das Ergebnis bei ruhend, und ruhend zieht überhaupt keine Abwertung nach sich. Stille ist bereits in der Entwicklungsaktivität eingepreist; sie zweimal zu berechnen würde genau die fertigen, stabilen Bibliotheken bestrafen, die Vertrauen verdienen.

Befunde multiplizieren den Gesundheitsindex: 85% gefährdet, 60% wahrscheinlich verwaist mit einer Obergrenze Gefährdet von 49 und 40% erklärt mit einer Obergrenze Kritisch von 29. Erklärt ist die zitierte eigene Aussage der Betreuung statt einer Folgerung – das Repository ist archiviert, oder jedes Paket, das es veröffentlicht, wurde als veraltet markiert oder zurückgezogen. Repositories ohne Commit-Stichprobe, mit unlesbarem Tracker oder mit weniger als 180 Tagen Historie lesen sich als nicht verifiziert und werden nicht abgewertet. Der vollständige Leitfaden zur Verwaisung nennt jeden Schwellwert, jedes Signal und jeden Schutzgrund.

Richtlinie zu schädlichen Abhängigkeiten

Eine verwundbare Abhängigkeit ist ein Fehler; eine schädliche ist ein Angriff. Jeder Bericht gleicht den aufgelösten Abhängigkeitsgraphen mit dem OpenSSF-Korpus schädlicher Pakete ab, den OSV.dev neben gewöhnlichen Advisories ausliefert – die Prüfung kostet also keine Anfrage, die der Bericht nicht ohnehin gestellt hätte.

Ein schädliches Paket trägt weder eine Schweregradangabe noch eine korrigierte Version, weil es beides nicht hat: Es ist ein Zustand, keine Abstufung, und die Abhilfe ist das Entfernen oder der Wechsel weg vom kompromittierten Namen statt eines Upgrades. Hat die Registry die genaue Version, auf die ein Repository auflöst, inzwischen entfernt, bleibt nichts Installierbares: Der Befund wird fürs Protokoll ausgewiesen und nicht bewertet. Es als Advisory zu bewerten, hat es daher untertrieben; stattdessen wird es aus den Advisory-Befunden entfernt und als Negativbefund behandelt. Jede bestätigte Meldung wendet einen Multiplikator von 35% und eine Obergrenze Kritisch von 29 auf die Sicherheitslage und auf den gewichteten Gesamtwert an – eine Stufe strenger als die Jurisdiktions-Obergrenze, denn hier liegt eine bestätigte Kompromittierung vor und keine Exposition gegenüber einem Risiko. Direkte und indirekte Abhängigkeiten zählen gleich: Eine beim Installieren ausgeführte Nutzlast läuft in jeder Tiefe des Graphen.

Der Befund ist konstruktionsbedingt selten – Registries entfernen schädliche Pakete binnen Tagen, und ein Lauf über 46.889 aufgelöste Abhängigkeiten vor der Freigabe fand keinen einzigen. Er betrifft das Paket in seiner veröffentlichten Form, nicht die Maintainer des geprüften Repositorys, das es womöglich unwissentlich aufgelöst hat. Der vollständige Leitfaden zu schädlichen Abhängigkeiten nennt die Quelle, die Bewertung und die Grenzen der Aussage.

Richtlinie für Hochrisikojurisdiktionen

Ein eindeutiger selbst veröffentlichter Profilstandort im aktuellen Umfang Russland, Iran und Nordkorea löst die Richtlinie für Hochrisikojurisdiktionen aus: Inhaber 20%, Top-Contributor 50%, öffentliche Organisationszugehörigkeit 75%. Mehrdeutige oder fehlende Daten werten nicht und leiten weder Nationalität, Sanktionen noch Absicht ab.

Jeder bestätigte Treffer multipliziert und begrenzt sowohl die Sicherheitslage als auch den gewichteten Gesamtwert auf 49. Sicherheit spiegelt den angepassten Wert ohne doppelte Multiplikation. Die Basiswerte bleiben im Bericht. Der vollständige Governance-Leitfaden erklärt Anwendungsfälle, Evidenzschutz und angemessene Prüfmaßnahmen.

Das effektive Gewicht einer Metrik im Gesamtindex ist normalerweise Kategoriengewicht × Gewicht innerhalb der Kategorie – ausgewiesen auf jeder Metrikkarte eines Berichts. Die Richtlinien zu unorganischem Wachstum, zur Verwaisung, zu schädlichen Abhängigkeiten und für Hochrisikojurisdiktionen sind die multiplikativen Ausnahmen, und keine von ihnen trägt ein eigenes additives Gewicht. AI Readiness trägt das Gewicht 0: ein unabhängiges, additives Badge, das den Gesundheitsindex niemals verändert.

Die registry-gestützten Metriken (Verbreitung im Ökosystem, Paketpflege) gelten nur für Repositories, die ein Paket veröffentlichen – siehe unterstützte Ökosysteme.

Abhängigkeits-Advisories

Die Abhängigkeiten eines Repositorys werden mit OSV abgeglichen, der offenen Advisory-Datenbank, die GHSA, PYSEC, RUSTSEC und weitere zusammenführt. Betroffene Pakete werden mit ihrem Schweregrad, den zugehörigen Advisories und der Version ausgewiesen, in der das jeweilige Problem behoben wurde.

Gemessen wird, was ein Konsument installiert. Für ein Repository, das ein Paket veröffentlicht, ist der bewertete Satz dessen Laufzeit-Abhängigkeitshülle – das, was eine Installation tatsächlich nach sich zieht. Nur wo ein Repository nichts veröffentlicht, wird stattdessen sein eigener Abhängigkeitsgraph bewertet, der zusätzlich Entwicklungs- und Test-Pins enthält, die nie ausgeliefert werden. Jeder Bericht nennt, welchen der beiden er bewertet hat, und benennt das Paket.

Der Unterschied verändert Ergebnisse erheblich. Flasks Repository-Graph trägt Advisories gegen alte Werkzeug- und Jinja-Versionen, die das Projekt für seine eigene Testmatrix pinnt; die Installation von Flask zieht sechs Pakete nach sich, keines davon betroffen. Nur die zweite Tatsache handelt von der Software, von der jemand abhängt.

Laufzeithüllen sind derzeit für npm, PyPI, crates.io und Maven auflösbar. Anderswo veröffentlichte Pakete werden gegen den Repository-Graphen bewertet, bis der Index sie abdeckt.

Das ist bewusst eine eigene Metrik neben der Sicherheitslage. Scorecards eigene Vulnerabilities-Prüfung fragt bereits dieselbe Datenbank ab und fließt bereits in die Sicherheitslage ein; ein zweites daraus abgeleitetes Signal innerhalb derselben Metrik würde denselben Befundkörper doppelt zählen. Beide beantworten unterschiedliche Fragen: die Sicherheitslage fragt, ob das Projekt überhaupt bekannte verwundbare Abhängigkeiten trägt, diese Metrik fragt welche, wie schwer und was sie behebt.

Was sie nicht behauptet: ein Advisory bedeutet hier, dass die im Abhängigkeitsgraphen erfasste Version in den betroffenen Bereich eines Advisories fällt. Erreichbarkeit wird nicht analysiert, und ein Abhängigkeitsgraph trennt Entwicklungs- und Test-Abhängigkeiten nicht von dem, was ein Projekt tatsächlich ausliefert – ein Fund kann also das Werkzeug betreffen und nicht die ausgelieferte Software. Jeder Bericht weist seine Abdeckung aus: wie viele Abhängigkeiten bewertet wurden und wie viele nicht.

Repositories ohne Abhängigkeitsgraphen werden nicht bestraft: die Metrik wird ausgeschlossen und das verbleibende Gewicht renormalisiert, wie bei jeder anderen nicht verfügbaren Eingabe.

Gemeinsam genutzte Scorecard-Belege

Sicherheit bleibt die vollständige risikogewichtete OpenSSF-Scorecard-Bewertung. Sieben Checks belegen zusätzlich die anderen Dimensionen, die sie offenkundig beschreiben: Wartung, signierte Releases, Beitragende, Code-Review, Lizenz, CI-Tests und gepinnte Abhängigkeiten. Sechs davon erscheinen in ihrer Zielmetrik als kleine additive Karten und behalten zugleich ihren Sicherheitsbeitrag. Der siebte, die Lizenz, ist anders gelagert: Er ist ein Eingangswert für das Lizenzsignal in der Community-Gesundheit, nicht dessen Gesamtheit – siehe unten. Dieser beabsichtigte kategorienübergreifende Einfluss ist je Metrik dokumentiert; Scorecard-Ergebnisse mit n/a oder ohne Verfügbarkeit werden überall ausgeschlossen.

Lizenzierung

Die Lizenz eines Repositorys wird auf einen von drei Zuständen aufgelöst, aus allen verfügbaren Quellen gemeinsam – den Lizenz-Metadaten des Repositorys selbst, dem Community-Profil von GitHub und dem License-Check der OpenSSF Scorecard. Eine Datei, die auch nur eine einzige Quelle erkennt, gilt als vorhanden; ein einzelner nicht verfügbarer Endpunkt kann eine Lizenz somit nicht als fehlend ausweisen.

Eine eigene Lizenz ist eine echte Lizenz und erhält den größten Teil des Gewichts. Sie erhält nicht das gesamte Gewicht: Eine Lizenz, die automatisierte Werkzeuge nicht identifizieren können, ist ein tatsächliches Hindernis für die Übernahme, denn Policy-Werkzeuge, unternehmensinterne Prüfungen und Paket-Registries stützen sich sämtlich auf anerkannte Kennungen, und ohne eigene Lektüre des Textes lässt sich nicht feststellen, was erlaubt ist.

Vor v1.3.0 wurden eigene Lizenzen bereits geringfügig niedriger bewertet – als Artefakt der Bewertung durch Scorecard, nicht als ausgesprochene Position. Die obige Abstufung ist bewusst gesetzt und bildet nun das gesamte Lizenzsignal.

Organisationsbewertung

Organisationen werden auf derselben Skala und mit denselben Stufen bewertet, in zwei Kategorien – Aktivität & Reichweite (75%) und Governance & Profil (25%) –, im Detail beschrieben in der Organisationsbewertung. Der Bericht eines Repositorys bettet zudem das Profil des Eigentümerkontos ein, das die Metrik Trägerschaft speist.

Konfiguration

Ein Scan kann eine Komponente, Metrik oder Kategorie deaktivieren; der Ausschluss wirkt genau wie fehlende Daten und ist im Bericht eingebettet, sodass jedes Ergebnis wie veröffentlicht reproduzierbar ist. Die Konfiguration verändert niemals eine Formel, ein Gewicht oder einen Schwellenwert – siehe Scan-Konfiguration.

Versionierung

Jede Änderung an einer Formel, einem Gewicht oder einer Stufengrenze erhöht die Metrik-Version. Die vollständige datierte Historie – von 0.1.0 bis zur aktuellen 1.13.0 – steht in Methodik-Versionen.

Durchgerechnetes Beispiel

pallets/flask (im Eigentum einer Organisation), geprüft am 2026-07-16 nach Methodik 1.4.0 – die aktuellen Werte stehen stets im vollständigen Bericht:

AI Readiness liegt bei 58 und trägt das Gewicht 0, geht also nicht in die Summe ein.

Dasselbe Repository unter einem persönlichen Konto mit derselben Gefolgschaft würde die Marge für Organisationsrückhalt und die Komponente der verifizierten Domain in der Trägerschaft verlieren und damit die Governance-Kategorie mit nach unten ziehen. Dieser Einfluss der Eigentumsform ist bewusst gesetzt, ausgewiesen und prüfbar.

Alle genannten Werte sind eine Momentaufnahme. Sie ändern sich mit der Evidenz und mit der Versionierung der Methodik; der verlinkte Bericht führt stets die aktuellen.

Roadmap (noch nicht gemessen)

• Latenz-Perzentile für Issues und PRs, zeitfensterbezogen statt über die gesamte Lebensdauer.
• Aktualität von Abhängigkeiten: wie viele davon upstream als veraltet markiert, archiviert oder seit Jahren ohne Release sind. Bekannte Advisories werden inzwischen gemessen – siehe Abhängigkeits-Advisories –, Aktualität ist jedoch ein eigenes Signal und wird noch nicht bewertet.
• Popularitätsnormalisierte Erwartungen (ein Repository mit 50 Sternen wird nicht am Maßstab eines Repositorys mit 50.000 Sternen gemessen).
• Signale zu Testabdeckung und CI-Erfolgsquote.

Jede dieser Änderungen erscheint mit einer Versionserhöhung, niemals still.