Die Methodik ist als Ganzes versioniert. Jede Änderung an einer Formel, einem Gewicht oder einem Stufen-Schwellwert erhöht die Metrikversion, und jeder veröffentlichte Bericht verzeichnet die Version, unter der er erstellt wurde (metrics.metrics_version). Das macht Ergebnisse über die Zeit auditierbar: Ein historischer Wert lässt sich unter genau den Regeln neu herleiten, die ihn erzeugt haben.
Die aktuelle Version ist 2.10.0. Ihre Implementierung ist unter inspect-software/scanner veröffentlicht. metrics.metrics_version in einem Bericht lässt sich mit METRICS_VERSION in der Repository-Historie abgleichen, um den für die Berechnung verwendeten Code zu bestimmen.
Jeder Eintrag benennt die genaue Änderung, ihren Geltungsbereich und ob bestehende Ergebnisse vergleichbar bleiben. Die Daten sind Teil des öffentlichen Methodikprotokolls.
Versionshistorie
2.10.0 — 2026-08-22
Eine Schnittstelle wird nur von Software erwartet, der sie sinnvoll fehlen kann. Die Metrik für maschinenlesbare Schnittstellen prüfte jedes zugelassene Repository gegen alle drei Kriterien — ein examples/-Verzeichnis, das nahezu jede Bibliothek mitbringt, genügte also, um ein fehlendes OpenAPI-Schema und einen fehlenden MCP-Server bescheinigt zu bekommen. Gut ein Viertel des Registers gelangte allein über Beispiele in die Metrik. Ein Maintainer brachte es auf den Punkt: Er wusste nicht, wie eine der beiden Prüfungen auf seinen Datenbanktreiber zutreffen sollte — zu Recht. Ein API-Schema wird nun nur noch von Netzwerkdiensten und Chatbots erwartet, ein MCP-Server nur von Netzwerkdiensten, ausführbare Beispiele von allem; alles Übrige wird ausgeschlossen und die verbleibenden Gewichtungen renormalisiert. Vorhandene Belege zählen weiterhin überall. Kein Repository gelangt neu in die Metrik, und keine Bewertung sinkt.
2.9.0 — 2026-08-22
Eine Registry, die für alles Veröffentlichte Dokumentation hostet, zählt als Dokumentationsseite. Version 2.7.0 akzeptierte eine über die Registry deklarierte Dokumentations-URL. crates.io geht weiter: Sie erzeugt und liefert für jede aufgenommene Crate eine Dokumentationsseite, unabhängig davon, ob das Manifest eine nennt — eine Crate, die den optionalen Schlüssel schlicht ausließ, verlor die Punkte dennoch, was Formalitäten statt Dokumentation maß. Die Prüfung greift nun auf diese gehostete Seite zurück, nachdem alle deklarierten URLs berücksichtigt wurden. Derzeit qualifiziert sich nur crates.io; ein Ökosystem kommt hinzu, wenn sein Hosting gemessen wurde, nicht wenn es ähnlich wirkt. Werte können nur steigen, und die Korrektur greift ohne erneuten Scan.
2.8.0 — 2026-08-22
Die verifizierte Domain einer Organisation wird endlich ausgelesen, und „nicht ausgelesen" heißt nicht mehr „nicht verifiziert". Die Prüfung der verifizierten Domain in Trägerschaft las das Kennzeichen vom Benutzer-Endpunkt von GitHub, der Organisationen zwar ausliefert, das Verifizierungsfeld aber gar nicht enthält — nur der Organisations-Endpunkt führt es. Jede Organisation im Register fiel damit unabhängig vom tatsächlichen Status durch eine 20-Punkte-Prüfung, und 59% des Registers sind organisationseigen. Ein Maintainer entdeckte es beim Lesen seines eigenen Berichts. Die Erhebung fragt nun ausschließlich für Organisationen den Organisations-Endpunkt ab. Die Bewertung ändert sich mit: ein nicht ausgelesenes Kennzeichen — in jedem zuvor erstellten Bericht und bei jedem fehlgeschlagenen Abruf — wird jetzt ausgeschlossen und die übrigen Gewichtungen renormalisiert, statt als „nicht verifiziert" gewertet zu werden: eine Anfrage, die nie stattfand, ist kein Beleg für eine unverifizierte Domain.
2.7.0 — 2026-08-20
Über die Registry deklarierte Dokumentation zählt. Die Dokumentationssite-Prüfung der Dokumentations-Metrik akzeptierte nur das GitHub-Homepage-Feld. Rust-Bibliotheken dokumentieren auf docs.rs, deklarieren das mit dem documentation-Schlüssel des Manifests — den crates.io spiegelt — und setzen selten eine GitHub-Homepage, sodass die Bibliotheken eines ganzen Ökosystems diese Punkte verloren; ein Maintainer, der einen Badge-Pull-Request erhielt, fand den Fehler in seinem eigenen Report, und syn und serde trugen denselben. Die Prüfung greift nun ersatzweise auf eine über die Paket-Registry deklarierte Dokumentations- oder Homepage-URL zurück: documentation und homepage auf crates.io, project_urls auf PyPI, documentation_uri bei RubyGems, die Doku-Links bei Hex, die Homepage bei npm und Packagist, projectUrl bei NuGet. Eine auf github.com gehostete Homepage wiederholt den Repository-Link und wird ignoriert. Werte können nur steigen, und nur dort, wo eine Registry deklariert, was das Repository bereits veröffentlicht. Bestehende Reports erhalten die Korrektur beim erneuten Scan, da die Registry-Deklaration zum Zeitpunkt der Erhebung erfasst wird.
2.6.0 — 2026-08-19
Adoptionsnachweise müssen zurückverweisen. Ökosystem-Adoption zählt Downloads und Registry-Abhängige nur noch von Paketen, deren Registry-Eintrag das geprüfte Repository als eigenes ausweist. Ein in den Manifesten des Repositories deklarierter Paketname, dessen Registry-Eintrag kein Repository angibt, behält den Vertrauensvorschuss für die Existenz, leiht dem Repository aber keine Download-Zahlen mehr: Diese Regel ließ die 25 Downloads/Monat eines fremden npm-Pakets anstelle der ~14 Mio./Monat des Projekts auf PyPI in einem Bericht stehen — entdeckt vom Maintainer des Projekts selbst. Ausgeschlossene Pakete werden nun in den Eingaben der Metrik benannt. Repositories, deren einzige Zahlen unverifiziert waren, zeigen die Metrik als „keine Daten" und renormalisieren. Werte verschieben sich nur dort, wo unverifizierte Zahlen gezählt wurden; verifizierte Nachweise bleiben unverändert.
2.5.0 — 2026-08-04
Die Klassifikation berührt zum ersten Mal einen Wert: Die Lockdatei-Erwartung des Sicherheitslage-Fallbacks gilt wieder für veröffentlichte Anwendungen. Die Veröffentlichung allein hob den Check bisher auf — und befreite damit genau die Repositories, um die es in der Anleitung geht: ruff, black und poetry sind veröffentlichte Anwendungen, und die Paketmanager selbst raten Anwendungen, die Lockdatei einzuchecken. Ein veröffentlichtes Paket, dessen Manifest eine ausführbare Datei erklärt, behält die Erwartung nun.
Zwei Leitplanken begleiten die Änderung. Die stehende Regel, der jede künftige Anbindung folgen wird: Bewertung liest ausschließlich Manifest-Erklärungen — ein aus Dateistruktur, Topics oder Beschreibung abgeleitetes Label wird angezeigt, bewegt aber nie einen Wert. Und der Wirkungsradius wurde vor der Freigabe gemessen: Die Lockdatei-Komponente existiert nur im Fallback, der greift, wenn OpenSSF Scorecard nicht verfügbar ist (472 von 49.846 gespeicherten Berichten), und darin ändern sich genau vier Berichte — einer gewinnt Punkte, drei verlieren. Die Änderung wirkt praktisch prospektiv: Sie regelt künftige Scans ohne Scorecard und lässt die Methodik ihren eigenen Worten folgen.
2.4.0 — 2026-08-04
Das Vokabular der Klassifikation wird ein expliziter zweistufiger Baum — Bibliothek · Anwendung · Host-Erweiterung · Notebook, mit Untertypen unter Anwendung und Host-Erweiterung — und ersetzt die flache Liste aus neunzehn Labels. Kein Wert ist betroffen.
Drei strukturelle Änderungen. Fünf Labels gehen in Bibliothek auf: Framework, SDK, API-Client, Middleware und Treiber hatten keine haltbaren Grenzen — axios ist API-Client und Bibliothek, flask ist Framework und Bibliothek —, und kein Konsument machte aus der Unterscheidung irgendetwas. Die Antwort darf auf der obersten Ebene stehen bleiben: Ein Cargo-Binary-Target und Gos cmd/-Layout beweisen eine ausführbare Datei, ohne zu sagen, welcher Art, und solche Repositories werden nun schlicht als Anwendung klassifiziert, statt mit reduziertem Gewicht in „Kommandozeilenwerkzeug" gezwungen zu werden. Host-Erweiterungen sind nach Host-Klasse untergliedert — Plugin, Browser-Erweiterung, Editor-Erweiterung, Theme —, denn die Klasse bestimmt die geerbte Vertrauensfläche, während der Namensunterschied zwischen WordPress und Chrome nichts bestimmte.
2.3.2 — 2026-08-04
Drei Korrekturen an der Klassifikation rund um Go-Repositories und Code-Qualitätswerkzeuge, gefunden bei der Durchsicht von go-critic — einem Go-Linter, dessen Bericht Bibliothek auswies, gestützt auf eine einzige Tatsache: Sein Modul ist über den Go-Proxy auflösbar. Kein Wert ist betroffen.
Der Go-Modul-Proxy zählt nicht mehr als Veröffentlichung. Jede andere Registry hält eine bewusste Handlung fest; der Proxy indexiert jedes Repository mit einer go.mod, sobald irgendjemand es anfragt — Server und Kommandozeilenwerkzeuge tragen den Eintrag genauso wie Bibliotheken. Wie das MCP-Signal in 2.3.1 bestätigt er nun, statt zu entscheiden: Repositories, deren einziger Bibliotheksbeleg der Proxy-Eintrag war, verlieren das Label, bis stärkere Belege vorliegen.
Gos Dateibaum wird als die Erklärung gelesen, die er ist. Die Sprache hat kein Manifestfeld für das, was sie baut; das cmd/-Layout und die vom Compiler durchgesetzte internal/-Regel sind ihre Art, es zu sagen. Jede Quelldatei in einem cmd/-Verzeichnis markiert nun ein Binary — zuvor tat das nur eine wörtlich main.go genannte Datei, was go-critics zweites Kommando verbarg —, und Pakete, die die internal/-Regel nicht versiegelt, zählen zur Bibliothek und bestätigen den Proxy-Eintrag.
Linter- und Formatter-Tags tragen die Kommandozeilen-Lesart — außer bei Host-Erweiterungen. Ein mit linter oder formatter getaggtes Repository liefert fast immer einen ausführbaren Prüfer. Die Ausnahme ist systematisch: Über den Bestand gemessen sind 42 von 256 linter-getaggten Repositories Regelpakete oder Konfigurationen für einen Host-Linter, und dort ist das ausführbare Werkzeug der Host. Der Beitrag wird vollständig zurückgezogen, sobald unabhängige Belege das Repository als Plugin, Erweiterung, Theme oder Editor-Werkzeug ausweisen.
2.3.1 — 2026-08-03
Eine Korrektur an der Stunden zuvor veröffentlichten Klassifikation: Das Model-Context-Protocol-Signal weist ein Repository nicht mehr im Alleingang als MCP-Server aus. Kein Wert ist betroffen.
Das Signal spricht auf .mcp.json an — die Datei, mit der ein Editor konfiguriert wird, MCP-Server aufzurufen — und auf jede Abhängigkeit, deren Name auf mcp endet, was ein Client genauso deklariert wie ein Server. Es hält fest, dass ein Projekt auf die Arbeit mit Coding-Agenten eingerichtet ist, nicht dass es einer der Server ist, die sie aufrufen. Über den gesamten Bestand gemessen ging es allein auf 1.746 der 3.115 Repositories mit diesem Label zurück, darunter freeCodeCamp. Es benötigt nun eine Bestätigung; ein echter Server wird weiterhin über sein Topic oder seine Abhängigkeit klassifiziert.
2.3.0 — 2026-08-03
Jeder Bericht benennt nun, was ein Repository baut: ob die Software als Code eingebunden, als Programm ausgeführt oder in einen Host installiert wird, der ihr Vertrauensmodell vorgibt. Kein Wert ändert sich in dieser Version — die Klassifikation wird als Datum veröffentlicht und ist noch in keine Metrik eingebunden.
Bisher stand ein einziger Näherungswert für diese Frage: Veröffentlicht das Repository ein Paket in einer Registry? Damit liest sich jedes Kommandozeilenwerkzeug auf PyPI als Bibliothek, und jede Anwendung, die nebenbei ein Hilfspaket ausliefert, ebenso — obwohl die daraus folgenden Erwartungen erheblich auseinandergehen. Von einer veröffentlichten Bibliothek wird erwartet, dass sie keine Lockdatei einträgt; von der Anwendung daneben im Katalog, dass sie es tut.
Die Klassifikation trägt jede Lesart, die die Belege stützen, nicht eine. Software, die zugleich veröffentlichte Bibliothek und ausführbares Werkzeug ist, ist der Normalfall und kein Widerspruch, und ein solches Repository schuldet die Pflichten beider Lesarten statt der nachsichtigsten. Belege sind nach ihrer Belastbarkeit geordnet: Was ein Build-Manifest ausdrücklich erklärt — ein OutputType, ein Composer-type, ein npm-bin-Eintrag, ein Console-Script-Einstiegspunkt — wiegt schwerer als Dateibaumstruktur, deklarierte Abhängigkeiten und selbst vergebene Topics, und kein einzelnes schwaches Signal trägt eine Lesart allein. Wo die Belege die Frage nicht beantworten, hält der Bericht genau das fest, statt zu raten.
Die Anbindung der Klassifikation an die Metriken, die von ihr abhängen — zuerst die Lockdateien, wo die geltende Regel für veröffentlichte Werkzeuge nachweislich falsch ist —, erfolgt in einer eigenen, datierten Version.
2.2.0 — 2026-08-02
Der Klassifikator für Hochrisikojurisdiktionen liest eine Verneinung nicht länger als Erklärung und behandelt einen genannten Ort außerhalb des Geltungsbereichs nun als widersprechenden Beleg.
Beide Fehler traten bei der Prüfung des Nordkorea-Geltungsbereichs an echten Profilen zutage. Standorte wie „not north korea“, „def not north korea“ und „Seoul, Korea (not DPRK)“ ergaben durchweg einen eindeutigen Treffer: Das Land wurde genannt, um es gerade von sich zu weisen, und die Richtlinie verbuchte das als Selbsterklärung. Eine Verneinung zählt nun — aber nur dort, wo sie neben dem Treffer steht; „No. 5 Lenin St, Moscow, Russia“ erklärt weiterhin Russland und nimmt nichts zurück.
Der zweite Fehler war struktureller Art. Das mitgelieferte Ortsverzeichnis enthält ausschließlich russische, iranische und nordkoreanische Orte, sodass eine ausländische Stadt neben einem Treffer unsichtbar blieb und der Treffer als unwidersprochen galt: „Seoul, North Korea“ und „New Dehli / Beijing / Hong Kong / Pyongyang“ zählten beide als eindeutig. Hauptstädte, Großstädte und Technologiezentren außerhalb des Geltungsbereichs machen einen Standort nun mehrdeutig — genau wie ein ausländischer Ländername zuvor —, und US-Bundesstaaten gelten für jedes Richtlinienland statt nur für Russland.
Vor der Freigabe über den gesamten Bestand gemessen: Von 358 eindeutigen Standorten ändern sich zwei — einer lautet „London, Munich, St. Petersburg“, also eine Standortliste und keine Erklärung, der andere „Amsterdam, Netherlands / Leningrad, Russia“. Ein einziges Repository verliert seine Flagge. Bewertungen können unter dieser Änderung nur steigen.
2.1.0 — 2026-08-02
Die Reaktionsfähigkeit erhält die Komponente „Annahme von Erstbeiträgen" (Gewicht 13). Von den Pull Requests, die in den letzten 30 Tagen entschieden wurden und deren Verfasser zuvor keinen gemergten Pull Request in diesem Repository hatte, bewertet die Komponente den Anteil der gemergten. Von Automatisierung verfasste Pull Requests werden vor jeder Zählung ausgeschlossen. Die beiden Lebenszeitkomponenten wurden neu gewichtet, um Platz zu schaffen — Issue-Erledigung 46,75 → 42, PR-Annahme 38,25 → 30 —, und die OpenSSF-Scorecard-Komponente Code-Review bleibt bei 15.
Die bestehende PR-Annahme ist eine Lebenszeitquote und bewegt sich bei einem etablierten Projekt kaum: Ein Repository mit Tausenden gemergter Pull Requests kann sie innerhalb eines Jahres nicht verschieben, gleich was es heute tut. Sie kann auch nicht unterscheiden zwischen einem Projekt, das die Arbeit seiner Stammbeitragenden zügig mergt, und einem, das nichts von außerhalb dieses Kreises aufnimmt. Die beiden Quoten fallen häufig genug auseinander, dass nur die zweite beschreibt, was Erstbeitragende erwarten dürfen.
Die Komponente wird ausgeschlossen und die verbleibenden Gewichte der Metrik werden renormalisiert, wenn im Zeitfenster kein Pull Request eines Erstbeitragenden entschieden wurde. Dass niemand anklopft, ist nicht dieselbe Tatsache wie dass niemand eingelassen wird, und nur die zweite geht auf das Projekt selbst zurück. Der Nenner sind die entschiedenen Pull Requests der Erstbeitragenden und nicht ihr Anteil an allen Merges, sodass ein reifes Projekt, in dem Stammbeitragende den Großteil der Arbeit landen, nicht dafür abgewertet wird, Stammbeitragende zu haben.
Die Evidenz wird während der Prüfung erhoben und erscheint daher nur in Berichten, die nach dieser Version erstellt wurden. Frühere Berichte enthalten die Eingabe nicht und renormalisieren ohne sie; die Änderung wirkt sich also schrittweise mit der erneuten Prüfung der Repositories aus und nicht auf einen Schlag über das gesamte Register. Wo die Komponente vorhanden ist, können sich Bewertungen in beide Richtungen bewegen.
Die Community-Gesundheit weist die Status-Badges der README aus, ohne sie zu bewerten. Wie viele Badges eine README anzeigt und von welchen Diensten sie stammen, wird nun als Beobachtung ohne Gewicht im Bericht geführt. Jede Tatsache, die ein Badge behauptet — dass CI läuft, dass Testabdeckung besteht, dass ein Release veröffentlicht ist —, wird bereits unmittelbar am Repository gemessen, und ein Badge ist eine Zeile Markdown, bei der nichts überprüft, ob sie auf das Projekt verweist, in dem sie steht.
2.0.0 — 2026-08-02
Die erste große Revision der Skala selbst, in drei zusammenhängenden Teilen. Das gesamte Register wurde darunter neu bewertet; Bewertungen, die vor und nach dieser Version veröffentlicht wurden, sind nicht Punkt für Punkt vergleichbar — über diese Grenze hinweg sind Stufen, nicht Punkte, die Einheit des Vergleichs.
Der Gesamtindex wird auf das öffentliche Register kalibriert. Das gewichtete Kategorienmittel nutzte den Bereich 1–100 schlecht: Über alle 47.516 geprüften Repositories gemessen lag die Hälfte des Registers zwischen 50 und 69, und das oberste Dezil von Open Source erreichte nur die hohen 70er — der größte Teil der Skala unterschied also nichts. Der veröffentlichte Index wendet nun eine feste monotone Kurve auf das rohe gewichtete Mittel an, verankert an gewählten Perzentilen der empirischen Verteilung des Registers zu einem datierten Snapshot. Die Stufen tragen dadurch Perzentilbedeutung, und das rohe Mittel bleibt zur Prüfbarkeit in jedem Bericht (overall.inputs.weighted_overall_raw). Die Kurve ist eine Konstante dieser Version, kein live berechnetes Perzentil: Eine Bewertung bewegt sich nur, wenn sich die Evidenz des Repositorys selbst bewegt. Die Kurve sättigt am oberen Ende der Skala — ein rohes Mittel von 91 oder mehr wird als 100 veröffentlicht —, weil die letzten rohen Punkte oberhalb dieser Linie nichts unterschieden, worauf Lesende reagieren sollten. Kategorie- und Metrikwerte werden unkalibriert veröffentlicht.
Aus fünf Stufen werden sieben. Schwach (35–49) liegt nun zwischen Gefährdet und Mittel, und Außergewöhnlich (93–100) oberhalb von Exzellent. Neue Schwellwerte: Kritisch 1–19, Gefährdet 20–34, Schwach 35–49, Mittel 50–64, Gut 65–79, Exzellent 80–92, Außergewöhnlich 93–100 — so gewählt, dass die kalibrierten Stufen das Register in vergleichbar große Populationen teilen, wo zuvor allein das alte Mittel rund die Hälfte davon hielt. Jede Stufe trägt zudem eine Buchstabennote, C bis AAA. Die Obergrenzen der Negativbefunde wanderten mit den Stufen, die sie benennen: Die Obergrenzen für Hochrisikojurisdiktionen und wahrscheinliche Verwaisung liegen nun bei 34 (oberes Ende von Gefährdet, zuvor 49), die Obergrenzen für schädliche Abhängigkeiten und erklärte Verwaisung bei 19 (oberes Ende von Kritisch, zuvor 29), und die Richtlinien auf den Gesamtwert wirken nun auf den kalibrierten Index, sodass die im Bericht genannte Obergrenze die Zahl ist, die die Seite anzeigt.
AI Readiness tritt mit 4 % in das gewichtete Mittel ein. Die Kategorie wurde seit ihrer Einführung mit Gewicht 0 gemessen und veröffentlicht; Agenten-Tooling ist inzwischen ein gewöhnliches Pflegesignal und trägt nun reales — bewusst kleines — Gewicht. Die übrigen Kategorien geben je einen Punkt ab: Nachhaltigkeit & Governance 23 %, Vitalität 21 %, Engineering-Qualität 19 %, Community & Verbreitung 17 %, Sicherheit 16 % (unverändert). Das Gewicht ist zusammen mit dem Sättigungspunkt der Kalibrierungskurve so bemessen, dass ein Repository ohne jedes AI-Readiness-Signal weiterhin 100/100 erreichen kann — die Kategorie kann einen Index leicht verschieben, den oberen Rand der Skala aber nie versperren.
1.14.0 — 2026-08-02
Die Richtlinie für Hochrisiko-Jurisdiktionen verlangt nun, dass ein Treffer auf Mitwirkenden-Seite Commit-Gewicht trägt, bevor er eine Flagge auslöst: mindestens 50 Commits oder mindestens 10 % der erfassten menschlichen Commits. Treffer auf den Eigentümer bleiben unberührt.
Die bisherige Regel markierte ein Repository bei jedem eindeutigen Standorttreffer unter den angezeigten Top-Mitwirkenden, unabhängig von der Größe ihres Beitrags. Auf dem Produktionsbestand gemessen trugen 1.763 Repositories die Flagge und nur 199 davon über das Eigentümerkonto; vom Rest beruhten 56 % auf einem Mitwirkenden mit weniger als zehn Commits und 70 % auf einem unter 5 % der Commit-Historie des Projekts. Weit verbreitete Projekte wurden wegen einzelner niedrig platzierter Mitwirkender nahe 1 % ihrer Historie markiert. Ein Standorttreffer bei einem beiläufigen Mitwirkenden ist Offenlegung, keine Exponierung, und eine Flagge darauf sagt einem Prüfer nichts darüber, wer die Software betreut.
Treffer unterhalb beider Schwellen bleiben als erfasste, nur zur Prüfung bestimmte Belege im Bericht; sie lösen keine Flagge aus und bewegen keine Bewertung. Bewertungen können unter dieser Änderung nur steigen, und nur bei Repositories, deren Flagge ausschließlich auf Treffern unterhalb der Schwellen beruhte. Die Schwellwerte stehen in jedem Bericht, und die Commit-Zahlen, die die Regel liest, waren bereits erhoben — bestehende Berichte wurden daher ohne erneuten Scan neu bewertet.
1.13.0 — 2026-07-22
Zwei Korrekturen, beide ausgelöst durch den ersten Befund einer schädlichen Abhängigkeit, den dieses Register je veröffentlicht hat.
Negativbefunde multiplizieren sich nicht mehr auf. Jede Richtlinie multiplizierte bisher, was die vorherige übrig ließ, sodass ein Repository mit zweien beim Produkt aus beiden landete. Ein Projekt fiel von gewichteten 50 auf 18 unter dem Multiplikator für schädliche Abhängigkeiten und dann auf 11 unter der Verwaisung — eine Zahl, die keine Richtlinie gewählt hat und auf die zur Erklärung auch keine verweisen könnte. Ein Multiplikator sagt aus, wie schwer ein Befund wiegt; er ist kein Kostenposten, der aufsummiert wird. Die strengste Richtlinie bestimmt nun allein, und die übrigen werden ausgewiesen, ohne den Wert erneut zu bewegen. Werte können unter dieser Änderung nur steigen, und nur bei Repositories mit mehr als einem Negativbefund.
Ein zurückgezogenes Paket wird nicht länger wie lebende Schadsoftware bewertet. Jeder Schadsoftware-Befund fragt nun bei der Registry nach, ob sie genau diese Version noch ausliefert. Ist das nicht der Fall, bleibt nichts Installierbares: Der Befund bleibt im Bericht stehen, weil das Projekt an einem Namen hängt, der kompromittiert war, aber er löst keinen Negativbefund aus und kostet keine Punkte.
Die Prüfung fragt nach der aufgelösten Version und nicht nach der neuesten des Pakets, und die Unterscheidung entscheidet reale Fälle. Nach einer Entfernung lässt npm ein Platzhalter-Release als neueste Version des Pakets zurück, was alle schützt, die einen Versionsbereich auflösen, und niemanden, der die schlechte Version exakt festgeschrieben hat. Die neueste Version zu lesen hätte genau das Repository freigesprochen, bei dem dieser Befund zuerst anschlug — es pinnt das kompromittierte Paket auf die Version, die die Registry weiter ausliefert. Wo die Frage überhaupt nicht beantwortet werden kann, 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.
1.12.0 — 2026-07-22
Die Stufe erklärt der Richtlinie zur Verwaisung schlug zu häufig auf Registry-Belege an, die gar nicht zu dem Repository gehörten, über das sie urteilte.
Diese Stufe existiert, um die Betreuung zu zitieren statt irgendetwas zu folgern: Ein Projekt gilt als erklärt unbetreut, wenn es archiviert ist oder wenn jedes Paket, das es veröffentlicht, eingestellt wurde. Zwei Fehler weiteten sie aus. Ein Paket zählte als eigenes Paket des Projekts, solange die Registry nicht ausdrücklich das Gegenteil sagte — was Einträge zuließ, die überhaupt kein Repository angeben, genau die Form, die ein besetzter Name annimmt. Und ein zurückgezogenes neuestes Release zählte als Einstellung, obwohl das Zurückziehen eines Releases meist ein misslungener Build ist, dessen Korrektur unmittelbar folgt.
Zusammen brachten sie ein mit 68 bewertetes Projekt auf 27, gestützt auf einen PyPI-Platzhalter, den es gar nicht veröffentlicht. Ein Paket muss nun dieses Repository angeben und ausdrücklich als veraltet markiert sein; ein zurückgezogenes Release trägt nicht mehr bei. Von 403 Repositories in der Stufe erklärt ruhten 391 auf GitHubs eigenem Archiv-Flag und standen nie in Frage.
1.11.0 — 2026-07-21
Verwaisung wird zu einem Negativbefund über den gesamten Bericht.
Jedes Werkzeug in diesem Feld beantwortet die Frage „ist dieses Projekt 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. Sie für tot zu erklären kostet ein öffentliches Register seine Glaubwürdigkeit genau bei der Software, die das meiste Vertrauen verdient.
Die Bewertung beruht deshalb auf einer anderen Frage — Verwaisung ist eine unerfüllte Pflicht, nicht die Abwesenheit von Lärm. Die Stille wird ab dem letzten menschlichen Commit gemessen und ist für sich allein nie ein Befund; sie wird erst dann zu einem, wenn sichtbar Arbeit eintrifft und nicht bearbeitet wird: 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, ein einziger Betreuer, der im gesamten Fenster fehlt. Lesarten, die die Stille erklären, halten das Ergebnis bei ruhend, was keine Abwertung nach sich zieht — Stille ist bereits in der Entwicklungsaktivität eingepreist, und sie zweimal zu berechnen würde genau die fertigen Bibliotheken bestrafen, zu deren Schutz die Unterscheidung existiert.
Befunde multiplizieren den Gesundheitsindex: 85% gefährdet, 60% wahrscheinlich verwaist mit einer Obergrenze Gefährdet von 49, 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, ist als veraltet markiert oder zurückgezogen. Repositories, die nicht bewertet werden können, lesen sich als nicht verifiziert und werden nicht abgewertet. Siehe Verwaisung.
Vergleichbarkeit: Werte können gegenüber 1.10.0 nur fallen, und nur bei Repositories, bei denen eine Dürre durch unerfüllte Pflichten erhärtet wird. Stille, gut gepflegte Projekte sind konstruktionsbedingt nicht betroffen.
1.10.0 — 2026-07-21
Als schädliche Pakete gemeldete Abhängigkeiten werden zu einem eigenen sicherheitsbezogenen Negativbefund, getrennt von Schwachstellen-Advisories.
Die Belege trafen ohnehin schon ein. OSV.dev liefert den OpenSSF-Korpus schädlicher Pakete neben gewöhnlichen Advisories aus, auf derselben Abfrage, die dieses Register bereits stellte — doch die Meldung eines schädlichen Pakets trägt weder eine Schweregradangabe noch eine korrigierte Version, fiel also auf „unbekannter Schweregrad“ durch und wurde wie eine moderate Schwachstelle bewertet. Ein als Schadsoftware befundenes Paket zählte etwas weniger als ein durchschnittlicher CVE.
Schädliche Pakete werden nun aus den Advisory-Befunden entfernt und nach eigenen Maßstäben bewertet: ein Multiplikator von 35% auf die Sicherheitslage und auf den gewichteten Gesundheitsindex, mit einer Obergrenze Kritisch von 29 auf beiden. Das ist eine Stufe strenger als die Obergrenze für Hochrisikojurisdiktionen, denn eine schädliche Abhängigkeit ist eine bestätigte Kompromittierung 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 aufgelösten Graphen.
Der Befund dürfte selten sein: Vor der Freigabe über eine Stichprobe von 300 Repositories mit 46.889 aufgelösten Abhängigkeiten laufen gelassen, fand er nichts. Registries entfernen schädliche Pakete binnen Tagen, sodass eine Lock-Datei, die noch zu einem auflöst, ungewöhnlich ist. Siehe schädliche Abhängigkeiten.
Vergleichbarkeit: unverändert für jedes Repository ohne schädliche Abhängigkeit, also für nahezu alle. Wo eine gefunden wird, sind Sicherheit und Gesundheitsindex mit keiner früheren Version vergleichbar.
1.9.0 — 2026-07-21
Der in 1.6.0 eingeführte Faktor für menschliche Autorschaft schlägt bei Projekten, die schlicht gut automatisieren, nicht mehr an.
Starke Automatisierung für sich genommen erwies sich als schlechtes Signal. Unter den Repositories, in denen Maschinen den Großteil des Commit-Aufkommens verfassen, waren die gesündesten allein am Anteil nicht von den aufgegebenen zu unterscheiden: Ein Projekt mit 59.000 Stars führt rund drei Viertel seiner Commits über einen Abhängigkeits-Bot und hatte vor zwei Tagen einen menschlichen Commit, und eine Paket-Registry, deren ganzer Zweck automatisierte Versionsanhebungen sind, liegt bei 93%. Beide wurden abgewertet.
Der Abschlag setzt nun eine zweite Bedingung voraus: Die Maschinen müssen zudem seit mehr als 90 Tagen allein committet haben. Der Abstand wird innerhalb des erfassten Commit-Fensters gemessen und nicht gegen die Uhr, sodass ein gespeicherter Bericht stets zum selben Wert neu bewertet wird. Repositories mit einem jüngeren menschlichen Commit sind bei keinem Automatisierungsgrad mehr betroffen; wirklich von Automatisierung getragene Projekte behalten ihren Abschlag.
Vergleichbarkeit: Werte können gegenüber 1.8.0 nur steigen, und nur in der Vitalität.
1.8.0 — 2026-07-21
Ein Signal wird zurückgezogen. Der Ausschlag vor Substanz der Wachstumsauthentizität beanspruchte, dass ein Schub, der vor dem ersten Release eines Projekts eintraf, ein Beleg für irgendetwas sei. Gemessen an 795 gewöhnlichen Repositories, schlug er in jedem einzelnen der fünf Befunde an, die die Richtlinie erzeugte — und jeder einzelne dieser fünf war ein gewöhnlicher Launch. Veröffentlichen, Aufmerksamkeit gewinnen, später ein Release herausgeben: So arbeiten Projekte.
Der Vergleich war in einer zweiten Hinsicht unsauber. Die Release-Liste, die ein Bericht führt, ist auf ihre 100 neuesten Einträge begrenzt; bei jedem Projekt jenseits dieser Grenze ist der früheste Eintrag daher nicht sein erstes Release, und jeder Schub scheint ihm vorauszugehen.
Was an seine Stelle tritt, keine Releases veröffentlicht, behält nur den absoluten Fall: Das Projekt hat überhaupt nie ein Release veröffentlicht. Es ist bewusst schwächer und erhärtet, statt zu entscheiden. Die Befunde in der gewöhnlichen Grundgesamtheit gehen auf null zurück, und beide bestätigten Befunde in der Evaluationsstichprobe bleiben bestehen.
Eine veröffentlichte Methodik, die ein Signal nicht zurückziehen kann, sobald sie es nicht mehr vertreten kann, ist keine Methodik. Dafür ist die Versionshistorie da.
1.7.0 — 2026-07-21
Wachstumsauthentizität erhält ein fünftes Signal, die Star-Konzentration: Die fünf stärksten Tage vereinen 80% oder mehr aller vom Scan erfassten Stars.
Ergänzt wurde es nach der ersten Auswertung der Richtlinie im Live-Betrieb, die sie als präzise, aber nahezu blind auswies — über 714 gewöhnliche Repositories hinweg markierte sie keines, und über 45 Repositories, die nach der Form gekaufter Aufmerksamkeit ausgewählt wurden, markierte sie eines. Der Schwellwert ist am Datenbestand abgelesen und nicht vorab gewählt: Unter 502 gewöhnlichen Repositories im Band von 100 bis 1.500 Stars entfallen im Median 6,9% der Stars auf die fünf stärksten Tage, und keines erreichte 80%.
Das Signal erhärtet einen Schub; es entscheidet nie für sich allein. Ein legitimes, ankündigungsgetriebenes Release nähert sich derselben Form — die Veröffentlichung eines Forschungsmodells wurde mit 73,7% gemessen —, und ein Signal, das beides nicht auseinanderhalten kann, darf nicht allein entscheiden.
Werte können unter dieser Änderung nur fallen, und nur bei Repositories, die ohnehin bereits einen Schub zeigten. Sonst bewegt sich nichts.
1.6.0 — 2026-07-21
Eingangsdaten, die sich aufblähen lassen, zählen nicht länger zum Nennwert.
Ergänzt um Wachstumsauthentizität. Der für jeden Bericht erhobene Tagesverlauf von Stars und Forks wird nun auf Wachstum gelesen, dessen Form organische Aufmerksamkeit nicht hervorbringt, und die Richtlinie zu unorganischem Wachstum wertet die Komponenten Stars und Forks der Popularität um 40% bei einem bestätigten Fenster und um 70% bei mehreren ab. Ein Schub allein ist nie ein Befund: Eine Bestätigung erfordert mindestens zwei unabhängige erhärtende Signale, sodass Launches und Titelseiten-Tage sich als organisch lesen. Repositories, deren erhobener Verlauf die Frage nicht beantworten kann, lesen sich als nicht verifiziert und werden nicht abgewertet. Die Richtlinie trägt kein additives Gewicht, ein sauberer Verlauf kann einen Wert also nie erhöhen.
Entwicklungsaktivität erhält einen Faktor für den menschlichen Anteil an der Autorschaft über ihre Komponenten Commit-Rhythmus und Commit-Volumen. Ein Projekt, das ausschließlich von den eigenen Robotern getragen wird, liest sich nicht länger als aktiv entwickelt; die volle Punktzahl gilt ab einem menschlichen Anteil von 40% aufwärts, sodass umfangreiche, aber echte Automatisierung unberührt bleibt. Maintainer-Resilienz zählt nun ausschließlich Menschen — Automatisierungskonten wurden zuvor unter die Maintainer eines Projekts gereiht, was ausgerechnet die Projekte begünstigte, die am meisten automatisieren.
Bestehende Werte bleiben vergleichbar, ausgenommen bei Community & Verbreitung für Repositories mit einem bestätigten Wachstumsbefund sowie bei Vitalität und Nachhaltigkeit & Governance für Repositories, deren Liste der Beitragenden weitgehend aus Automatisierung besteht. Werte können unter diesen Änderungen nur fallen, nie steigen.
1.5.0 — 2026-07-20
Ergänzt um Abhängigkeits-Advisories. Der aufgelöste Abhängigkeitssatz, der ohnehin für jeden Bericht erhoben wird – direkte Abhängigkeiten plus transitive Hülle –, wird nun mit der Advisory-Datenbank OSV abgeglichen; betroffene Pakete werden mit ihrem Schweregrad und der Version ausgewiesen, in der das jeweilige Problem behoben wurde.
Sicherheit wird zum gewichteten Mittel aus Sicherheitslage mit 80% und der neuen Metrik mit 20%. Der Multiplikator der Richtlinie für Hochrisikojurisdiktionen bleibt unverändert: er gilt weiterhin für die Sicherheitslage und für den gewichteten Gesamtwert und trägt kein eigenes additives Gewicht.
Die neue Metrik wird ausgeschlossen und das verbleibende Gewicht renormalisiert, sobald der Abhängigkeitsgraph oder die Advisory-Abfrage nicht verfügbar war – kein Repository wird dafür bestraft, dass sein Abhängigkeitsgraph abgeschaltet ist. Bestehende Werte bleiben vergleichbar, außer bei Sicherheit: jedes Repository mit Abhängigkeitsgraph wird nun anhand von Belegen bewertet, die zuvor nicht berücksichtigt wurden.
1.4.0 — 2026-07-19
Neu ist die Exposition gegenüber Hochrisikojurisdiktionen für eindeutige selbst veröffentlichte Standorte in Russland, Iran oder Nordkorea. Hierarchie-Multiplikator: Inhaber 20%, Top-Contributor 50%, öffentliche Organisationszugehörigkeit 75%. Ein Treffer multipliziert und begrenzt Sicherheitslage und nach der Gewichtung den Gesamtwert auf 49. Sicherheit spiegelt die angepasste Lage ohne doppelte Multiplikation. Fehlende, mehrdeutige oder trefferfreie Daten werten nicht. Das Signal priorisiert eine vertiefte Prüfung; es bestimmt weder Nationalität, Sanktionsstatus, Absicht noch persönliche Vertrauenswürdigkeit.
1.3.0 — 2026-07-18
Das Lizenzsignal der Community-Gesundheit wurde zu einer dreistufigen Abstufung — Standard, eigen oder keine — und ersetzt damit eine einzelne Vorhanden/Fehlend-Prüfung. Ein Repository, dessen Lizenzdatei existiert, deren Text aber keine anerkannte Lizenz ist, erhält nun drei Viertel des Lizenzgewichts statt entweder der vollen Anrechnung oder gar keiner.
Auch die Erkennung hat sich geändert: Der Zustand wird aus allen drei Lizenzquellen gemeinsam aufgelöst (den Lizenz-Metadaten des Repositorys, dem Community-Profil von GitHub und dem License-Check der Scorecard), statt allein der Scorecard den Vorrang zu geben. Die Präsenz ist ein logisches ODER, sodass eine Datei zählt, die auch nur eine einzige Quelle erkennt. Die Quellen weichen bei rund 1% der Repositories voneinander ab.
Eigene Lizenzen wurden bereits vor dieser Version geringfügig niedriger bewertet als Standardlizenzen, weil Scorecard sie mit 9 von 10 statt mit 10 bewertet. Dieser Abstand war vom Werkzeug übernommen und nicht als Position ausgesprochen; er ist nun bewusst gesetzt und dokumentiert.
Vergleichbarkeit: Bestehende Ergebnisse wurden unter 1.3.0 aus den in jedem Bericht bereits gespeicherten Daten neu berechnet — kein Repository wurde erneut gescannt, sodass sich nichts aus einem anderen Grund als dieser Änderung bewegt hat. Die Bewegung ist gering: Die Lizenz-Zeile trägt 22,5 von 100 Punkten innerhalb der Community-Gesundheit, die ihrerseits 35% von Community & Verbreitung ausmacht, was wiederum 18% des Index sind.
1.2.0 — 2026-07-14
Registry-Adapter für veröffentlichte Pakete wurden für Go (den Modul-Proxy), Maven Central und NuGet hinzugefügt, und die PyPI-Paketidentifikation wurde auf ältere setup.py-Manifeste erweitert. Repositories, die in diesen Ökosystemen veröffentlichen, tragen nun Registry-Evidenz in der Paketpflege — Aktualität der Veröffentlichungen, Versionshistorie, Deprecation-Status — und NuGet speist zusätzlich über die Gesamtzahl aller Downloads die Ökosystem-Verbreitung. Go und Maven Central veröffentlichen keinerlei Download-Statistiken und liefern daher kein Verbreitungssignal. Keine Formeln oder Gewichte wurden geändert — nur, für welche Repositories Registry-Evidenz verfügbar ist.
1.1.0 — 2026-07-14
Community-Gesundheit erkennt eine Lizenz nun einmal. Zuvor enthielt sie zwei überlappende Lizenzkomponenten — ein Flag aus dem GitHub-Community-Profil und eine separate License-Karte geteilter Evidenz. Diese sind zu einer einzigen License-Zeile zusammengeführt, die über den License-Check der OpenSSF Scorecard erkannt wird; das Community-Profil-Flag bleibt nur als Fallback für Repositories ohne Scorecard erhalten. Scorecards eigener License-Check bleibt eine vollwertige Komponente der Sicherheitslage. Die Zusammenführung beseitigt Doppelzählung und folgt bei Abweichungen der beiden Quellen der zuverlässigeren Erkennung durch Scorecard. Dieses Release ändert betroffene community_health-Werte; Berichte bleiben über ihre verzeichnete metrics_version reproduzierbar.
1.0.0 — 2026-07-13
OpenSSF-Scorecard-Checks liefern nun geteilte Evidenz, wo eine Sicherheitspraktik zugleich eine andere Gesundheitsdimension belegt. Scorecard bleibt in der Sicherheitslage vollständig risikogewichtet; sieben ausgewählte Checks erhalten zusätzlich kleine, dokumentierte Gewichte in ihren Zielmetriken: Maintained, Signed-Releases, Contributors, Code-Review, License, CI-Tests und Pinned-Dependencies.
Dies ist beabsichtigter kategorienübergreifender Einfluss, keine Wiederverwendung der Sicherheitsrisiko-Gewichte von Scorecard. Ein als n/a gemeldeter Check oder nicht verfügbare Scorecard-Daten werden aus der Zielmetrik ausgeschlossen, und die verbleibenden Komponenten werden renormalisiert. Dieses Release ändert betroffene Repository-Werte; Berichte bleiben über ihre verzeichnete metrics_version reproduzierbar.
0.9.0 — 2026-07-07
Der Fallback der Sicherheitslage behandelt eine fehlende Abhängigkeits-Lockdatei bei veröffentlichten Bibliotheken nicht mehr als Mangel. Lockdateien sind eine Praxis auf Anwendungsebene; viele Bibliotheken und Gems lassen sie zu Recht weg. Für diese Repositories wird die Fallback-Komponente nun ausgeschlossen, und die verbleibenden Komponenten renormalisieren. Der OpenSSF-Scorecard-Pfad blieb unverändert.
0.8.0 — 2026-06-30
Die Kategorie KI-Bereitschaft mit vier Metriken hinzugefügt (Agentenkontext, Verifikationsschleife, Code-Lesbarkeit, Schnittstellen), die bewerten, ob ein Repository verlässliche KI-gestützte Entwicklung unterstützt. Die Kategorie trägt das Gewicht 0,0: Sie ist ein unabhängiges, additives Badge und ändert den gesamten Gesundheitsindex nie. Bestehende Repository-Formeln blieben unverändert.
0.7.0 — 2026-06-20
Unterstützte Ökosysteme erweitert. Ökosystem-Verbreitung greift auf die Gesamtzahl aller Downloads zurück, wenn eine Registry keine Monatszahl veröffentlicht (RubyGems), sodass Ruby- und Hex-Pakete nun Verbreitungswerte erhalten. Registry-Adapter für RubyGems und Hex hinzugefügt; das Parsen deklarierter Abhängigkeiten auf Go, Maven, RubyGems, NuGet und Hex erweitert. Siehe unterstützte Ökosysteme.
0.6.0 — 2026-06-09
Sicherheitslage neu aufgebaut auf der OpenSSF Scorecard: werkzeugneutrale, risikogewichtete Checks, die Projekte nicht mehr für Tooling außerhalb von GitHub bestrafen; ergebnislose Checks werden ausgeschlossen statt als null gewertet. Grobe Dateibaum-Checks bleiben als Fallback erhalten. Nur die Kategorie Sicherheit betroffen.
0.5.0 — 2026-05-29
Paket-Ökosystem-Metriken hinzugefügt: Ökosystem-Verbreitung (Registry-Downloads) in Community & Verbreitung und Paketpflege (Aktualität der Veröffentlichungen, Deprecation) in Nachhaltigkeit & Governance. Beide sind null für Repositories, die kein Paket veröffentlichen. Innere Kategoriegewichte neu austariert; Kategoriegewichte und übrige Formeln unverändert.
0.4.0 — 2026-05-18
Metriken in fünf gewichtete Kategorien mit aggregierten Werten neu gruppiert. Vier neue Repository-Metriken: Release-Disziplin, Popularität, Trägerschaft und Dokumentation. activity umbenannt in Entwicklungsaktivität. Der Gesamtindex aggregiert nun Kategorien statt einzelner Metriken.
0.3.0 — 2026-05-06
Organisationsmetriken hinzugefügt — Profilvollständigkeit, Portfolio-Aktivität, Community-Reichweite und ein Organisations-Gesamtwert (siehe Organisationsbewertung). Repository-Formeln unverändert.
0.2.0 — 2026-04-25
Ergebnisse je Komponente zu jeder Metrik hinzugefügt, sodass ein Bericht genau zeigt, welche Kriterien erfüllt, teilweise erfüllt oder ausgeschlossen wurden. Formeln, Gewichte und Stufen-Schwellwerte unverändert gegenüber 0.1.0.
0.1.0 — 2026-04-15
Erste Methodik.
Was Versionierung garantiert
- Reproduzierbarkeit — Berichte verzeichnen ihre Eingaben und die Methodikversion; die entsprechende Bewertungsimplementierung ist veröffentlicht. Die dokumentierte Datenschutzausnahme für Profile Beitragender gilt weiterhin.
- Vergleichbarkeit — zwei unter derselben Version geprüfte Repositories werden nach identischen Regeln gemessen.
- Rechenschaft — Methodikänderungen sind öffentlich, datiert und begründet; es gibt keine stillen Anpassungen.
Verwandt: der Gesundheitsindex · Bewertungsstufen · Scan-Konfiguration