OpenSSF Scorecard

Для чего

Scorecard автоматически оценивает практики безопасности репозитория open-source проекта и выставляет числовые баллы (0–10) по набору эвристик: есть ли code review, защищён ли branch, подписаны ли релизы, нет ли бинарных артефактов в дереве, как быстро чинятся уязвимости, используются ли pinned-зависимости, fuzzing, SAST и т.д. Это не сканер уязвимостей и не SBOM-генератор — это оценка гигиены и зрелости апстрима, помогающая решить, можно ли вообще доверять зависимости как поставщику.

Сигнал риска поставщика, а не уязвимости в коде SCA говорит «в этой версии есть CVE». Scorecard отвечает на смежный вопрос — «насколько ответственно сопровождается проект, от которого мы зависим». Низкий балл по Maintained, Branch-Protection или Dangerous-Workflow — это ранний индикатор риска цепочки поставки до того, как из проекта прилетит инцидент.

Как применяют

Оценка конкретного репозитория с машиночитаемым выводом:

export GITHUB_AUTH_TOKEN=<token>
scorecard --repo=github.com/<github-owner>/<repository> --format=json --show-details

Фрагмент вывода — баллы по отдельным проверкам, которые можно завести в policy:

{
  "score": 6.7,
  "checks": [
    { "name": "Branch-Protection", "score": 8, "reason": "branch protection on default branch" },
    { "name": "Maintained",        "score": 10, "reason": "30 commits in last 90 days" },
    { "name": "Signed-Releases",   "score": 0, "reason": "no signed releases found" },
    { "name": "Dangerous-Workflow","score": 10, "reason": "no dangerous patterns detected" }
  ]
}

Также доступен публичный API/датасет (api.securityscorecards.dev) для уже посчитанных популярных проектов и запуск отдельных проверок через --checks=Branch-Protection,Signed-Releases.

Сильные стороны

• Переводит «качество апстрима» из субъективного впечатления в воспроизводимые числовые сигналы, пригодные для policy и приоритизации.
• Покрывает практики, которые SCA и SBOM не видят в принципе: защита веток, опасные workflow, подпись релизов, наличие бинарей в репозитории.
• Машиночитаемый JSON и публичный датасет позволяют массово оценивать дерево зависимостей, а не один проект.
• Часть экосистемы OpenSSF — проверки и трактовки развиваются открыто и согласованно со смежными практиками.

Ограничения

• Это прокси-метрика, а не гарантия: высокий балл не означает отсутствия уязвимостей, низкий — не означает компрометации; цифры легко переинтерпретировать.
• Большинство проверок завязано на платформу (преимущественно GitHub) и требует API-токена и сетевого доступа; вне GitHub покрытие неполное.
• Часть эвристик чувствительна к структуре проекта и даёт ложные сигналы (монорепо, форки, проекты без релизов).
• Оценивает процесс вокруг кода, но не сам код — это вход в анализ риска поставщика, а не вывод о безопасности конкретной версии.

Offline / on-premise

Нет (в общем случае). Основные проверки обращаются к GitHub API и внешним источникам (deps.dev и др.), что требует сети и токена. Локальный режим (--local <path> для уже клонированного репозитория) покрывает лишь подмножество проверок, не зависящих от API платформы, и не заменяет полный прогон. Для закрытого контура реалистично использовать только эти локальные проверки либо заранее выгруженный публичный датасет оценок.

Связанные темы

• М08. Защита цепочки поставки и OSA — оценка зрелости апстрима как сигнал риска на входе.
• М06. Поиск уязвимостей и VDR/VEX — Scorecard дополняет CVE-картину контекстом сопровождаемости.
• П17. OSA controlled repository policy — где балл проекта может стать критерием допуска/карантина зависимости.
• OpenSSF Scorecard (нормативная карточка) — роль сигналов зрелости в evidence-базе курса.
• Смежные карточки: SLSA (зрелость сборки, тогда как Scorecard — зрелость проекта), in-toto и Cosign (доверие к артефакту, тогда как Scorecard — доверие к поставщику), GitHub Security Advisory (источник advisory для тех же проектов).