
Вычисляет оценку критичности проектов с открытым исходным кодом на основе метрик репозитория, участников и зависимостей для расстановки приоритетов в улучшении безопасности.
Этот проект поддерживается участниками Securing Critical Projects WG.
Генерировать оценку критичности для каждого проекта с открытым исходным кодом.
Создать список критических проектов, от которых зависит сообщество открытого исходного кода.
Использовать эти данные для упреждающего повышения уровня безопасности этих критических проектов.
Оценка критичности проекта определяет влияние и важность проекта. Это число в диапазоне 0 (наименее критичный) и 1 (наиболее критичный). Она основана на следующем алгоритме автора Роба Пайка:
Мы используем следующие параметры по умолчанию для определения оценки критичности проекта с открытым исходным кодом:
ПРИМЕЧАНИЕ:
$ 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
Оценку можно изменить с помощью параметра -scoring-config и указания другого файла конфигурации для определения способа расчёта оценки.
По умолчанию для расчёта оценки используется конфигурация original_pike.yml. Однако можно указать другие файлы конфигурации для получения иных оценок. Подробнее см. в config/scorer.
Не стесняйтесь копировать одну из конфигураций и настраивать веса и пороговые значения по своему усмотрению.
Перед запуском оценки критичности необходимо:
GITHUB_AUTH_TOKEN. Это помогает избежать ограничений скорости API GitHub для неаутентифицированных запросов.# For posix platforms, e.g. linux, mac:
export GITHUB_AUTH_TOKEN=<your access token>
# For windows:
set GITHUB_AUTH_TOKEN=<your access token>
В настоящее время существует три формата: text, json и csv. В будущем могут быть добавлены другие.
Их можно указать с помощью флага -format.
Проект criticality score также содержит другие команды для генерации и работы с данными оценки критичности.
enumerate_github: инструмент для точного сбора набора репозиториев GitHub с минимальным количеством звёздcollect_signals: воркер для сбора необработанных сигналов в масштабе с использованием инфраструктуры проекта Scorecard.scorer: инструмент для пересчёта оценок критичности на основе входного CSV-файла.Если вам интересно посмотреть список критических проектов с их оценкой критичности, мы публикуем их в формате csv и в наборе данных BigQuery.
Эти данные генерируются с помощью рабочего экземпляра проекта criticality score, запущенного в GCP. Подробности о его развёртывании можно найти в каталоге infra.
ПРИМЕЧАНИЕ: В настоящее время эти списки формируются только на основе проектов, размещённых на GitHub. В ближайшем будущем мы планируем расширить их с учётом проектов, размещённых в других системах контроля версий.
Данные доступны в Google Cloud Storage, их можно загрузить через:
gsutil: gsutil ls gs://ossf-criticality-score/Эти данные доступны в публичном наборе данных BigQuery.
С помощью учётной записи GCP вы можете выполнять запросы по данным. Например, вот запрос, возвращающий 100 лучших репозиториев по оценке:
SELECT repo.url, default_score
FROM `openssf.criticality_score_cron.criticality-score-v0-latest`
ORDER BY default_score DESC
LIMIT 100;
Если вы хотите принять участие или у вас есть идеи, которыми вы хотели бы поделиться, мы обсуждаем этот проект на встречах Securing Critical Projects WG.
Расписание и приглашения на встречи смотрите в Community Calendar.
Инструкции по участию см. в документации Contributing.
| Параметр (Si) | Вес (αi) | Макс. порог (Ti) | Описание | Обоснование |
|---|
| created_since | 1 | 120 | Время с момента создания проекта (в месяцах) | У более старого проекта выше вероятность широкого использования или наличия зависимостей от него. |
| updated_since | -1 | 120 | Время с момента последнего обновления проекта (в месяцах) | У не сопровождаемых проектов без недавних коммитов выше вероятность меньшей зависимости от них. |
| contributor_count | 2 | 5000 | Количество участников проекта (с коммитами) | Вовлечённость разных участников указывает на важность проекта. |
| org_count | 1 | 10 | Количество различных организаций, к которым относятся участники | Показывает межорганизационные зависимости. |
| commit_frequency | 1 | 1000 | Среднее количество коммитов в неделю за последний год | Более высокая интенсивность изменений кода немного указывает на важность проекта. Также повышает подверженность уязвимостям. |
| recent_releases_count | 0.5 | 26 | Количество релизов за последний год | Частые релизы указывают на зависимость пользователей. Меньший вес, поскольку используется не всегда. |
| closed_issues_count | 0.5 | 5000 | Количество проблем, закрытых за последние 90 дней | Указывает на высокую вовлечённость участников и внимание к закрытию проблем пользователей. Меньший вес, поскольку зависит от участников проекта. |
| updated_issues_count | 0.5 | 5000 | Количество проблем, обновлённых за последние 90 дней | Указывает на высокую вовлечённость участников. Меньший вес, поскольку зависит от участников проекта. |
| comment_frequency | 1 | 15 | Среднее количество комментариев на одну проблему за последние 90 дней | Указывает на высокую активность и зависимость пользователей. |
| dependents_count | 2 | 500000 | Количество упоминаний проекта в сообщениях коммитов | Указывает на использование репозитория, обычно при обновлении версий. Этот параметр работает для всех языков, включая C/C++, у которых нет графов зависимостей пакетов (хотя это и несколько грубый способ). Планируется добавить деревья зависимостей пакетов в ближайшем будущем. |