5 /10

lynxdb

https://github.com/lynxbase/lynxdb
Плохо

Прожарка: lynxdb

Оценка: 5/10

Критично

  • [⚠ МНЕНИЕ] Dockerfile (стр. 12) – apk add без указания версии. При пересборке образа может «поплыть» набор зависимостей, а в CI‑пайплайне это часто приводит к непредсказуемым сбоям.
  • [⚠ МНЕНИЕ] Dockerfile.release (стр. 2) – аналогично, apt‑get install без фиксированных версий.
  • [⚠ МНЕНИЕ] run‑all.sh (стр. 153) – ls | grep — неустойчивый способ перебора файлов; при наличии пробелов в именах скрипт упадёт.
  • [⚠ МНЕНИЕ] fault_inject.sh (стр. 14) – переменная COMPOSE_FILE объявлена, но нигде не используется; оставляет «мусор», который только запутывает читающего.
  • [✓ ФАКТ: CVE-Ищейка] trivy – уязвимости в dompurify (много CVE и GHSA). Библиотека используется для санитизации HTML, но текущая версия содержит известные bypass‑ы, что делает XSS‑защиту сомнительной.

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

  • [⚠ МНЕНИЕ] install.sh (стр. 44) – объявлена переменная BLUE, но она не участвует в дальнейшем коде; удалите или задокументируйте её назначение.
  • [⚠ МНЕНИЕ] analyze.sh (стр. 14‑115) – каждый вызов команды пишет в файл отдельным перенаправлением. Сгруппировать их в блок { … } >> logfile уменьшит количество открытых дескрипторов и упростит чтение.
  • [✓ ФАКТ: CVE-Ищейка] Dockerfile – добавить USER с ненулевым UID, иначе контейнер будет работать от root, что отмечено как high‑severity misconfiguration.
  • [⚠ МНЕНИЕ] Обновить зависимости: перейти на последнюю безопасную версию dompurify, follow-redirects и grpc. Это устранит большинство CVE‑средней тяжести и одну критическую.

Мелочи

  • [✓ ФАКТ: Баш-Прокурор] В shellcheck‑сообщениях о стиле (2129) рекомендуется объединять редиректы; это не критично, но повышает читаемость.
  • [⚠ МНЕНИЕ] В install.sh переменная BLUE могла бы стать параметром, если её планировали использовать в цветных выводах.
  • [⚠ МНЕНИЕ] В run-all.sh вместо ls | grep предпочтительнее for f in *.log; do …; done.

Что хорошо

  • [⚠ МНЕНИЕ] Репозиторий содержит полный набор CI‑файлов (GitHub Actions, GitLab CI) – автоматизация тестов и сборки уже настроена.
  • [⚠ МНЕНИЕ] Тестовый пакет присутствует, покрывая основные функции парсинга данных; это показатель, что авторы думают о качестве.
  • [⚠ МНЕНИЕ] README подробно описывает процесс установки и пример использования, включая готовый docker-compose.yml.
  • [⚠ МНЕНИЕ] В коде используются типичные Python‑модули (pandas, sqlalchemy) без излишних обёрток, что упрощает поддержку.
  • [⚠ МНЕНИЕ] Структура проекта достаточно логична: src/ – бизнес‑логика, scripts/ – вспомогательные утилиты, tests/ – юнит‑тесты.
  • [⚠ МНЕНИЕ] В Dockerfile.release предусмотрен multi‑stage build, что уменьшает размер финального образа.

Вердикт

Добротный набор утилит, но без фиксированных версий пакетов и с устаревшими зависимостями проект держится на грани стабильности. Улучшите безопасность и уберите «мёртвый» код – тогда оценка поднимется.

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

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