
Berechnet 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:
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.
Diese Daten werden mit einer Produktionsinstanz des Kritikalitäts-Score-Projekts erzeugt, die in GCP läuft. Details zur Bereitstellung finden Sie im Verzeichnis infra.
HINWEIS: Derzeit werden diese Listen ausschließlich aus Projekten abgeleitet, die auf GitHub gehostet werden. Wir planen, sie in naher Zukunft zu erweitern, um auch Projekte zu berücksichtigen, die auf anderen Quellcodeverwaltungssystemen gehostet werden.
Die Daten sind in Google Cloud Storage verfügbar und können heruntergeladen werden über:
gsutil-Kommandozeilentool: gsutil ls gs://ossf-criticality-score/Diese Daten sind im öffentlichen BigQuery-Dataset verfügbar.
Mit einem GCP-Konto können Sie Abfragen über die Daten ausführen. Hier ist zum Beispiel eine Abfrage, die die 100 wichtigsten Repositories nach Score zurückgibt:
SELECT repo.url, default_score
FROM `openssf.criticality_score_cron.criticality-score-v0-latest`
ORDER BY default_score DESC
LIMIT 100;
Wenn Sie sich einbringen möchten oder Ideen haben, über die Sie sprechen möchten, besprechen wir dieses Projekt in den Treffen der Securing Critical Projects WG.
Die Termine und Einladungen zu den Treffen finden Sie im Community-Kalender.
Siehe die Dokumentation Mitwirken für Hinweise, wie Sie beitragen können.
| 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. |