Кратко

  • OpenSSF Scorecard автоматически оценивает выбранные проверки по шкале от нуля до десяти и строит взвешенный по риску итог.
  • Сам проект называет проверки эвристиками, допускает ложные срабатывания и пропуски и не считает результат универсальным окончательным отчётом.
  • Сканирование может быть входным доказательством, но не устанавливает приемлемость конкретной зависимости, владельца риска, исключение или обязательное действие.

Число, которому намеренно отведена узкая роль

OpenSSF Scorecard превращает ряд доступных для автоматики признаков открытого репозитория в результаты отдельных проверок и в общий балл. Это удобно: сопровождающий видит, где стоит улучшить практику, а потребитель зависимости — что стоит исследовать прежде всего.

Однако описание инструмента не позволяет превращать балл в вердикт. Отбор проверок, их вес и способ расчёта содержат оценочные решения. Эвристика способна показать ложный сигнал или не увидеть существующую практику. Проект прямо исключает цель быть окончательным отчётом или единым требованием для всех проектов. Итоговое число не раскрывает, какие именно условия дали такой результат, и может измениться после изменения самих эвристик.

Это не ослабляет измерение, а очерчивает его честное значение. Балл — это наблюдение конкретной цели в конкретный момент при доступных данных. Он не является полной характеристикой исходного кода, всех релизов, цепочки поставки или среды, в которой иной оператор будет использовать компонент.

Среднее не несёт чужую ответственность

Один показатель легко переносится на панель, в значок или список поставщиков. Из-за этого появляется соблазн установить автоматический порог. Но Scorecard использует разновесные по риску проверки. Два репозитория могут получить одинаковый итог при противоположных результатах именно там, где для конкретного потребителя находится важное условие.

Документация проверок показывает пределы такого вывода. Maintained использует видимую активность за ограниченный период и одновременно предупреждает, что малая активность сама по себе не делает программу рискованной. SBOM ищет наличие перечня компонентов в определённых местах исходного кода, конвейера или релиза. Найденный перечень полезен как признак наличия, но не доказывает полноту, соответствие развёрнутому бинарному файлу или достаточность для анализа уязвимости потребителя.

Важен и способ получения данных. У публичных еженедельных сканов есть заявленный охват; API ради масштабирования не включает некоторые проверки; запуск с иным доступом способен увидеть другую картину. Разрешённая ссылка, время, версия инструмента, доступные данные, отдельные результаты и детали должны сохраняться вместе с итогом. Иначе сегодняшнее число ошибочно станет свидетельством о старом релизе или другом артефакте.

Пояснение сопровождающего не является независимой проверкой

Низкий результат не доказывает уязвимость, небрежность, инцидент или прекращение поддержки. Он означает лишь, что заданный автоматический способ не получил ожидаемого сигнала. Scorecard подчёркивает, что существующая практика может не быть обнаружена.

Механизм аннотаций сопровождающего позволяет добавить контекст: test-data, remediated, not-applicable, not-supported, not-detected. Это полезно, поскольку делает видимой неполноту общей проверки. Но такая аннотация остаётся утверждением сопровождающего, а не независимым аудитом и не приказом другому потребителю принять зависимость.

Поэтому нельзя смешивать три записи: наблюдение инструмента, контекст от сопровождающего и решение потребителя. Последнее должно относиться к фактически используемому пакету, коммиту или артефакту, к правам, данным, альтернативам, компенсирующим мерам, ответственному лицу и сроку пересмотра.

Решение начинается за пределами скана

Организация может использовать опубликованный пакет, закреплённый коммит, внутреннее зеркало или результат собственной сборки. Она может дать компоненту другие привилегии, данные и сетевой доступ, чем даёт другой пользователь. Она может временно принять исключение, изолировать компонент, запросить дополнительные доказательства, следить за условием, заменить его или отказаться от него. Взвешенное среднее не выбирает ни один из этих шагов.

Полезная запись «сканирование—решение о зависимости» сохраняет в первой части идентификатор репозитория и разрешённую ссылку, версию и время Scorecard, ограничения доступа к данным, итог, существенные проверки, детали и аннотации. Во второй части она указывает точную зависимость или релиз, контекст использования, независимые доказательства, владельца решения, основание для порога или исключения, выбранное действие и условие следующего пересмотра.

Такой подход не превращает Scorecard в программу сертификации. Он не даёт автоматическому наблюдению незаметно присвоить полномочие, которым обладает только сторона, принимающая риск.

Источники

  1. OpenSSF Scorecard README
  2. Документация проверок OpenSSF Scorecard
  3. Аннотации сопровождающего OpenSSF Scorecard