Позиция по OpenSSF Scorecard
Целевой показатель OpenSSF Scorecard для Apothem и поверхности доказательств, используемые для того, чтобы оценка продолжала улучшаться.
Apothem стремится к максимальной оценке OpenSSF Scorecard, сохраняя при этом честность публичного фасада относительно того, что Scorecard может и не может вывести из нового репозитория с единственным сопровождающим. Этот документ перечисляет каждую проверку, поверхность доказательств, которая её подкрепляет, и контроль, поддерживающий позицию в актуальном состоянии.
Текущая оценка доступна в просмотрщике Scorecard; значок находится в заголовке README.
Матрица доказательств по проверкам
| Проверка | Поверхность доказательств | Примечания |
|---|---|---|
| Binary-Artifacts | binary-artifacts-sweep.md | В исходном коде не отслеживается ни одного исполняемого бинарного файла; сгенерированные архивы дистрибутивов остаются в dist/. |
| Branch-Protection | branch-protection-ruleset.md | main защищена до продвижения публичного релиза; force-push и удаления блокируются после того, как попадает свежий коммит релиза. |
| CI-Tests | .github/workflows/ci.yml | Матрица Pytest, ruff, mypy, Trivy, сборка документации и дымовые проверки упаковки. |
| CII-Best-Practices | Регистрация в OpenSSF Best Practices | Требует регистрации со стороны сопровождающего на сайте OpenSSF Best Practices; это нельзя выполнить одними лишь файлами репозитория. |
| Code-Review | Защита веток + CODEOWNERS | Pull request обязательны для main для всех, кроме администраторов репозитория, а защита веток требует 0 одобряющих рецензий, пока у проекта один сопровождающий (см. branch-protection-ruleset.md); история Scorecard остаётся ограниченной, пока не появятся отрецензированные PR. |
| Contributors | AUTHORS | Новый проект с одним сопровождающим не может сфабриковать историю вкладов нескольких организаций; это естественным образом улучшится по мере присоединения участников. |
| Dangerous-Workflow | Аудит рабочих процессов | Нет pull_request_target; Actions закреплены по SHA и ограничены явными разрешениями. |
| Dependency-Update-Tool | .github/dependabot.yml | Dependabot предлагает сгруппированные еженедельные обновления для закреплённых версий GitHub Actions, веб-сайта, lock-файла упаковщика vsce, pip для CI с фиксацией по хешам и хуков pre-commit, а также ежемесячные обновления для lock-файла channel-smoke; обновления безопасности Dependabot охватывают каждый обнаруженный манифест, кроме полных наборов зависимостей и инструментов CI в scripts/ci/: их пересоздаёт scripts/dev/refresh_ci_locks.py, когда оповещение называет зафиксированный пакет. .gitattributes сохраняет этот единственный файл в архивах исходного кода GitHub, которые читает сканирование в стандартном для action режиме архива; рабочий процесс Scorecard работает в режиме git и читает этот файл из клона. |
| Fuzzing | tests/property/ | Тесты свойств Hypothesis проверяют инварианты парсера и фронтматтера; вышестоящий Scorecard может не засчитать Hypothesis как интеграцию фаззера. |
| License | LICENSE | Лицензия MIT в корне репозитория. |
| Maintained | История Git | Текущий коммит релиза и активный ритм рабочих процессов подтверждают сопровождение; очень новые репозитории могут получить предупреждение о возрасте. |
| Packaging | .github/workflows/ | Рабочие процессы релиза, Pages и npmjs.com, производящие sdist, wheel, SBOM, происхождение SLSA и подписи Sigstore. |
| Pinned-Dependencies | Аудит рабочих процессов + требования, зафиксированные по хешам | Actions закреплены по SHA; релизный инструментарий, обновление pip в CI, зависимости проекта и тестов в CI и инструменты CI (ruff, bandit, pip-audit, pip-licenses, pre-commit) устанавливаются с --require-hashes. Установки проекта, тестов и инструментов читают девять lock-файлов в scripts/ci/; обновление pip и релизный инструментарий читают каждый свой lock-файл, а сам пакет устанавливается с --no-deps -e .. |
| SAST | .github/workflows/codeql.yml | Запросы CodeQL security-extended по Python и Actions. |
| Security-Policy | SECURITY.md | Политика скоординированного раскрытия, матрица поддерживаемых версий и сроки реагирования. |
| Signed-Releases | .github/workflows/release.yml | Бесключевые подписи Sigstore, происхождение SLSA, SBOM, контрольные суммы и артефакты релиза. |
| Token-Permissions | Аудит рабочих процессов | Рабочие процессы по умолчанию используют разрешения только на чтение; области записи локальны для задания и привязаны к операциям развёртывания и пакетов. |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | Еженедельное сканирование уязвимостей и сканирование в CI с загрузкой SARIF; шлюз dependency-review блокирует pull request, которые вводят уязвимые зависимости или зависимости с недопустимыми лицензиями. Сама проверка ищет в OSV зависимости, которые находит в манифестах репозитория, поэтому pip-audit.yml тоже обращается к OSV (pip-audit -s osv), и находка там соответствует находке проверки. |
Интерпретация оценки
Scorecard оценивает каждую проверку по шкале от 0 до 10, а общая оценка — это взвешенное среднее. Контроли, зависящие от истории репозитория, сторонней регистрации или разнообразия участников, отслеживаются явно, а не завышаются. Дрейф по любой проверке, контролируемой файлами, запускает немедленное исправление.
Рабочий процесс Scorecard запускает action с file_mode: git, так что Scorecard читает клон репозитория. Архивы исходного кода не содержат .github/ (export-ignore в .gitattributes), поэтому в режиме архива, который action использует по умолчанию, рабочие процессы были бы скрыты от Dangerous-Workflow, Token-Permissions, Pinned-Dependencies и Packaging.
Pinned-Dependencies намеренно остаётся ниже 10, по двум причинам. На генератор SLSA ссылаются по тегу релиза — это единственное исключение из закрепления по SHA, потому что его происхождение привязано к этому тегу. Рабочий процесс evals устанавливает CLI Claude Code через npm install --global в версии, которая выбирается при каждом запуске. Установки Python в рабочих процессах, которые сканирует Scorecard, зафиксированы по хешам либо являются локальными установками самого пакета или wheel-пакетов, собранных в том же запуске.
Ритм обновления
- При каждом push: рабочий процесс Scorecard перезапускается при каждом push в
main. - Еженедельно: по понедельникам в 02:30 UTC — улавливает изменения в вышестоящей методологии оценки + новые уязвимости, раскрытые в существующих закреплённых зависимостях.
- При каждом релизе: перед публичным продвижением сопровождающий проверяет действующую поверхность просмотрщика Scorecard и фиксирует любые ограничения, связанные с состоянием платформы.
Ссылки
- OpenSSF Scorecard — вышестоящий проект
- Справочник проверок Scorecard — семантика каждой проверки
ossf/scorecard-action— обёртка для GitHub Actions- Фреймворк SLSA — уровни цепочки поставок (apothem поставляется на уровне SLSA-3)