5 /10

emailflare

https://github.com/0xdps/emailflare
Плохо

Прожарка: emailflare

Оценка: 5/10

Критично

  • [⚠ МНЕНИЕ] Dockerfile (стр. 6, 15, 54) – пакеты устанавливаются без фиксированных версий. При каждом билде образ может «раздуться» и, что хуже, в продакшн‑окружении может появиться уязвимая библиотека.
  • [⚠ МНЕНИЕ] Dockerfile (стр. 22‑34) – вместо WORKDIR используется цепочка cd … && …. При падении любой команды текущая директория теряется, а последующие RUN работают в корне, что ломает кэширование и усложняет отладку.
  • [⚠ МНЕНИЕ] start.sh (стр. 5‑11, 111) – переменные без кавычек, что открывает путь к неожиданному разбору glob‑ов и подстановке слов. При передаче пользовательского пути скрипт может выполнить лишние команды.
  • [✓ ФАКТ: Код-Рентген] Уязвимости npm‑зависимостей – axios, fast-uri и hono содержат CVE с высоким и средним уровнем риска (прототип‑поллюция, обход ограничений тела запроса, XSS в JSX). Ни один из пакетов не обновлён до безопасных версий, а автоматическое обновление отключено.

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

  • [⚠ МНЕНИЕ] Pin‑версий – добавить apk add <pkg>=<ver> и npm install <pkg>@<ver> во всех Dockerfile, чтобы гарантировать воспроизводимость и отсутствие известных уязвимостей.
  • [⚠ МНЕНИЕ] WORKDIR – вынести WORKDIR /app в начале Dockerfile и удалить все cd … &&. Это ускорит сборку и сделает слои предсказуемыми.
  • [✓ ФАКТ: Баш-Прокурор] Кавычки в shell‑скриптах – обернуть все переменные в двойные кавычки, включить set -euo pipefail для надёжного завершения при ошибке.
  • [⚠ МНЕНИЕ] Обновление зависимостей – выполнить npm audit fix и вручную заменить уязвимые пакеты на версии без CVE (например, axios@1.6.8, fast-uri@2.2.0, hono@4.2.1).
  • [✓ ФАКТ: Докер-Дед] CI‑pipeline – добавить шаг npm ci && npm audit и проверку hadolint с флагом --fail-on WARN, чтобы сборка падала при новых предупреждениях.

Мелочи

  • [⚠ МНЕНИЕ] Лишние файлы – в корне присутствует Dockerfile.mesahub, который не используется в CI и не упоминается в README. Удалить или перенести в отдельный пример.
  • [⚠ МНЕНИЕ] README – описывает запуск через docker compose up, но в docker-compose.yml указаны устаревшие теги образов (latest). Лучше фиксировать теги.
  • [⚠ МНЕНИЕ] Линтер‑исключения – в .dockerignore отсутствует node_modules, из‑за чего каждый билд копирует гигантскую директорию, замедляя процесс.

Что хорошо

  • [⚠ МНЕНИЕ] Структура проекта – есть отдельные директории src/, config/ и scripts/, что упрощает навигацию.
  • [⚠ МНЕНИЕ] Логика отправки писем – реализована через hono‑router, поддерживает несколько эндпоинтов (/send, /status). Код роутера лаконичен, использует async/await без «callback‑ад‑хок».
  • [⚠ МНЕНИЕ] Документация – README подробно описывает переменные окружения, пример .env.example и шаги локального тестирования.
  • [⚠ МНЕНИЕ] Docker‑файлы – оба образа (основной и mesahub) построены на Alpine, что экономит место и ускоряет старт.
  • [⚠ МНЕНИЕ] Shell‑скрипт start.sh – автоматически подставляет переменные окружения в конфиг, упрощая деплой в контейнере.

Вердикт

Добротный старт, но без фиксаций зависимостей и правильного Docker‑файла проект рискует «выстрелить в ногу» уже на первом продакшн‑деплое.

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

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