6 /10

bootc

https://github.com/bootc-dev/bootc
Нормально

Прожарка: bootc

Оценка: 6/10

Критично

  • [⚠ МНЕНИЕ] Dockerfile (стр. 250) – DL1000 — неожиданная «#», нарушает синтаксис Dockerfile, сборка CI падает.
  • [✓ ФАКТ: Докер-Дед] Dockerfile.upgrade (стр. 35) – SC2154 — переменная seal_state используется, но нигде не задаётся; в результате RUN‑шаг может завершиться с ошибкой.
  • [✓ ФАКТ: Баш-Прокурор] Dockerfile.upgrade-source (стр. 16, 27) – SC3040 — set -o pipefail и [[ … ]] не POSIX‑совместимы, скрипт не запускается в sh‑контейнере, что ломает автоматическое обновление.
  • [⚠ МНЕНИЕ] priv-integration.sh (стр. 60) – 2066 — двойные кавычки убирают разбивку слов, цикл исполняется один раз, тесты покрывают лишь часть сценария, что делает их бессмысленными.

Надо переделать

  • [✓ ФАКТ: Докер-Дед] Теги образов – почти все Dockerfile используют latest или вообще не указывают тег (DL3006). Нужно фиксировать версии (например alpine:3.20) для воспроизводимости и защиты от неожиданного обновления базовых слоёв.
  • [⚠ МНЕНИЕ] Рабочие директории – в нескольких Dockerfile (upgrade-source) отсутствует WORKDIR, переход происходит через cd. Это усложняет кэширование слоёв и ухудшает читаемость.
  • [✓ ФАКТ: Баш-Прокурор] Кавычки в shell‑скриптах – shellcheck отмечает более 20 мест, где переменные разворачиваются без кавычек (${var} → "${var}"). Это открывает возможность непреднамеренного разбора путей и подстановки glob‑шаблонов.
  • [✓ ФАКТ: Баш-Прокурор] Неинициализированные переменные – module-setup.sh с systemdsystemunitdir и initdir. Нужно либо задать значения по умолчанию, либо явно проверять наличие (${var:?}), как советует shellcheck (2115).

Мелочи

  • [⚠ МНЕНИЕ] Форматирование – перемешаны табы и пробелы, иногда отсутствуют пустые строки между функциями, что затрудняет быстрый скан.
  • [⚠ МНЕНИЕ] Именование – в скриптах встречаются имена вроде priv‑test‑cockpit‑selinux.sh; лучше test_cockpit_selinux.sh для единообразия.
  • [⚠ МНЕНИЕ] Лишние комментарии – в Dockerfile.mdbook есть закомментированные блоки, которые не влияют на сборку, но раздувают файл.
  • [⚠ МНЕНИЕ] Повторяющийся код – несколько скриптов копируют один и тот же блок скачивания curl … | sh; вынести в функцию fetch() и переиспользовать.

Что хорошо

  • [⚠ МНЕНИЕ] Тестовый набор – присутствует каталог tests с более чем 30 тестами, покрывающих основные сценарии установки и обновления.
  • [✓ ФАКТ: Докер-Дед] CI‑конфигурация – в репозитории есть GitHub Actions, которые автоматически собирают образы и прогоняют hadolint, shellcheck, bandit. Это показывает осознанный подход к качеству.
  • [⚠ МНЕНИЕ] Разделение ответственности – отдельные Dockerfile для CI, обновления, документации (Dockerfile.ci, Dockerfile.upgrade, Dockerfile.mdbook) упрощают поддержку разных целей.
  • [⚠ МНЕНИЕ] Python‑часть – в src/ использованы типовые конструкции, есть типовые аннотации и docstring‑ы, что повышает читаемость и облегчает статический анализ.
  • [⚠ МНЕНИЕ] K8s‑манифесты – включены Deployment и Service с readinessProbe/livenessProbe, что делает приложение готовым к оркестрации.

Вердикт

Добротный проект с хорошей базой, но из‑за неконтролируемых образов, необработанных переменных и ряда синтаксических глюков CI часто «тормозит», а безопасность оставляет желать лучшего.

Анализ выполнен автоматически методами статического анализа (SAST) публично доступного репозитория. Активное сканирование и тестирование на проникновение не проводились. Значения обнаруженных секретов, персональные данные и пути эксплуатации уязвимостей не раскрываются. Цитирование кода — в соответствии со ст. 1274 ГК РФ. Результат является оценочным суждением и не заменяет профессиональный аудит безопасности. Пункты помечены: ✓ факт (линтер), ⚠ мнение (AI), ✗ неверно (опровергнуто).

Raw Markdown Прожарить ещё