ossf/criticality_scoreBerechnet einen Kritikalitäts-Score für Open-Source-Projekte aus Repository-, Beitragenden- und Abhängigkeitsmetriken, um Sicherheitsverbesserungen zu priorisieren.
Dieses Projekt wird von Mitgliedern der Securing Critical Projects WG gepflegt.
Einen Kritikalitäts-Score für jedes Open-Source-Projekt generieren.
Eine Liste kritischer Projekte erstellen, von denen die Open-Source-Community abhängt.
Diese Daten nutzen, um die Sicherheitslage dieser kritischen Projekte proaktiv zu verbessern.
Der Kritikalitäts-Score eines Projekts definiert den Einfluss und die Bedeutung eines Projekts. Er ist eine Zahl zwischen 0 (am wenigsten kritisch) und 1 (am kritischsten). Er basiert auf dem folgenden Algorithmus von Rob Pike:
Wir verwenden die folgenden Standardparameter, um den Kritikalitäts-Score für ein Open-Source-Projekt abzuleiten:
| Parameter (Si) | Gewicht (αi) | Max. Schwellenwert (Ti) | Beschreibung | Begründung |
|---|---|---|---|---|
| created_since | 1 | 120 | Zeit seit der Erstellung des Projekts (in Monaten) | Ein älteres Projekt hat eine höhere Wahrscheinlichkeit, weit verbreitet zu sein oder als Abhängigkeit zu dienen. |
| updated_since | -1 | 120 | Zeit seit der letzten Aktualisierung des Projekts (in Monaten) | Ungepflegte Projekte ohne aktuelle Commits haben eine höhere Wahrscheinlichkeit, weniger als Abhängigkeit verwendet zu werden. |
| contributor_count | 2 | 5000 | Anzahl der Projektmitwirkenden (mit Commits) | Die Beteiligung verschiedener Mitwirkender weist auf die Bedeutung des Projekts hin. |
| org_count | 1 | 10 | Anzahl der verschiedenen Organisationen, denen die Mitwirkenden angehören | Weist auf organisationsübergreifende Abhängigkeit hin. |
| commit_frequency | 1 | 1000 | Durchschnittliche Anzahl der Commits pro Woche im letzten Jahr | Eine höhere Code-Änderungsrate ist ein schwacher Hinweis auf die Bedeutung des Projekts. Außerdem besteht eine höhere Anfälligkeit für Schwachstellen. |
| recent_releases_count | 0.5 | 26 | Anzahl der Veröffentlichungen im letzten Jahr | Häufige Veröffentlichungen weisen auf eine Nutzerabhängigkeit hin. Geringeres Gewicht, da dies nicht immer verwendet wird. |
| closed_issues_count | 0.5 | 5000 | Anzahl der in den letzten 90 Tagen geschlossenen Issues | Weist auf hohes Engagement der Mitwirkenden und den Fokus auf das Schließen von Nutzer-Issues hin. Geringeres Gewicht, da es von den Projektmitwirkenden abhängt. |
| updated_issues_count | 0.5 | 5000 | Anzahl der in den letzten 90 Tagen aktualisierten Issues | Weist auf hohes Engagement der Mitwirkenden hin. Geringeres Gewicht, da es von den Projektmitwirkenden abhängt. |
| comment_frequency | 1 | 15 | Durchschnittliche Anzahl der Kommentare pro Issue in den letzten 90 Tagen | Weist auf hohe Nutzeraktivität und -abhängigkeit hin. |
| dependents_count | 2 | 500000 | Anzahl der Projekterwähnungen in den Commit-Nachrichten | Weist auf die Repository-Nutzung hin, normalerweise bei Versions-Upgrades. Dieser Parameter funktioniert über alle Sprachen hinweg, einschließlich C/C++, die keine Paketabhängigkeitsgraphen haben (wenn auch etwas hacky). Es ist geplant, in naher Zukunft Paketabhängigkeitsbäume hinzuzufügen. |
HINWEIS:
$ go install github.com/ossf/criticality_score/v2/cmd/criticality_score@latest
$ export GITHUB_TOKEN=... # requires a GitHub token to work
$ gcloud auth login --update-adc # optional, add -depsdev-disable to skip
$ criticality_score -gcp-project-id=[your projectID] https://github.com/kubernetes/kubernetes
repo.name: kubernetes
repo.url: https://github.com/kubernetes/kubernetes
repo.language: Go
repo.license: Apache License 2.0
legacy.created_since: 87
legacy.updated_since: 0
legacy.contributor_count: 3999
legacy.watchers_count: 79583
legacy.org_count: 5
legacy.commit_frequency: 97.2
legacy.recent_releases_count: 70
legacy.updated_issues_count: 5395
legacy.closed_issues_count: 3062
legacy.comment_frequency: 5.5
legacy.dependents_count: 454393
default_score: 0.99107
Der Score kann geändert werden, indem der Parameter -scoring-config verwendet und eine andere Konfigurationsdatei bereitgestellt wird, die festlegt, wie der Score berechnet wird.
Standardmäßig wird die Konfiguration original_pike.yml verwendet, um den Score zu berechnen. Es können jedoch andere Konfigurationsdateien angegeben werden, um unterschiedliche Scores zu erzeugen. Weitere Informationen finden Sie unter config/scorer.
Sie können gerne eine der Konfigurationen kopieren und die Gewichte und Schwellenwerte an Ihre Bedürfnisse anpassen.
Bevor Sie den Kritikalitäts-Score ausführen, müssen Sie:
GITHUB_AUTH_TOKEN setzen.
Dies hilft, die
API-Ratenbegrenzungen
von GitHub bei nicht authentifizierten Anfragen zu vermeiden.# For posix platforms, e.g. linux, mac:
export GITHUB_AUTH_TOKEN=<your access token>
# For windows:
set GITHUB_AUTH_TOKEN=<your access token>
Derzeit gibt es drei Formate: text, json und csv. Weitere können in Zukunft hinzugefügt werden.
Diese können mit dem Flag -format angegeben werden.
Das Kritikalitäts-Score-Projekt enthält auch weitere Befehle zum Generieren und Arbeiten mit Kritikalitäts-Score-Daten.
enumerate_github: ein Werkzeug zum präzisen Erfassen einer Menge von GitHub-Repositories mit einer Mindestanzahl an Sternencollect_signals: ein Worker zum Sammeln von Rohsignalen in großem Maßstab unter Nutzung der Infrastruktur des Scorecard-Projekts.scorer: ein Werkzeug zur Neuberechnung von Kritikalitäts-Scores basierend auf einer eingegebenen CSV-Datei.Wenn Sie daran interessiert sind, eine Liste kritischer Projekte mit ihrem Kritikalitäts-Score zu sehen, veröffentlichen wir diese im csv-Format und als BigQuery-Dataset.