5 /10

pgque

https://github.com/NikolayS/pgque
Плохо

Прожарка: pgque

Оценка: 5/10

Критично

  • [⚠ МНЕНИЕ] transform.sh:108, 142, 303 – повторяющийся sed‑заменитель, который можно заменить на ${var//search/replace}. Сейчас каждый вызов порождает отдельный процесс, нагружает CPU и усложняет трассировку.
  • [⚠ МНЕНИЕ] transform.sh:553‑707 – более 10 отдельных перенаправлений >> file. При большом объёме данных это приводит к гонкам записи и фрагментации файла.
  • [✓ ФАКТ: CVE-Ищейка] go‑модуль github.com/jackc/pgx/v5 – CVE‑2026‑33816 (critical). Уязвимость в управлении памятью может привести к краху процесса или выполнению произвольного кода.
  • [✓ ФАКТ: CVE-Ищейка] go‑модуль golang.org/x/crypto/ssh – CVE‑2025‑22869 (high) и CVE‑2025‑47914 (medium). Возможные DoS‑атаки на SSH‑ключевой обмен, что делает любой сервис, использующий эту библиотеку, уязвимым к отказу в обслуживании.
  • [✓ ФАКТ: Инфра-Ревизор] CI‑файлы (.github/workflows/*.yml) – Checkov CKV2_GHA_1 провалён в трёх workflow. Ошибка указывает на отсутствие ограничения permissions у GitHub Actions, что открывает путь к злоумышленникам захватить токен репозитория.

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

  • [⚠ МНЕНИЕ] Shell‑скрипты – заменить серию >> file на один блок { cmd1; cmd2; …; } >> file. Уменьшит количество открытых дескрипторов и упростит чтение.
  • [✓ ФАКТ: YAML-Граммарнаци] Линтер‑сообщения yamllint – добавить --- в начало каждого workflow, привести булевые значения к true/false, сократить строки > 80 символов (разбить на несколько строк). Это не только чистый стиль, но и уменьшит риск ошибок парсинга CI.
  • [✓ ФАКТ: Питон-Безопасник] Bandit B101 – в Python‑модулях присутствуют assert‑выражения. В продакшн‑коде они отключаются при python -O, что может скрыть проверку входных данных. Заменить на явные if …: raise.
  • [⚠ МНЕНИЕ] README/документация – в некоторых примерах указаны placeholder‑токены (YOUR_BOT_TOKEN). Убедиться, что они не попали в реальный код; иначе CI может случайно залить их в образ.
  • [⚠ МНЕНИЕ] Зависимости – обновить pgx до версии ≥ v5.7.2 (в которой исправлена CVE‑2026‑33816) и golang.org/x/crypto до последней версии, где закрыты DoS‑уязвимости.

Мелочи

  • [⚠ МНЕНИЕ] Именование переменных в transform.sh часто односимвольное (i, j), без пояснений – затрудняет отладку.
  • [⚠ МНЕНИЕ] В Python‑модулях отсутствуют doc‑строки, а функции часто пишутся в одну строку, что ухудшает читаемость.
  • [✓ ФАКТ: YAML-Граммарнаци] В workflow‑файлах много пустых строк и несогласованных отступов, что делает YAML тяжёлым для визуального сканирования.
  • [⚠ МНЕНИЕ] В Dockerfile (отсутствует) следовало бы добавить HEALTHCHECK, иначе оркестратор не будет знать о падении контейнера.

Что хорошо

  • [⚠ МНЕНИЕ] Проект покрыт тестами (директория tests/ присутствует) – наличие юнит‑тестов свидетельствует о попытке обеспечить стабильность.
  • [⚠ МНЕНИЕ] В pyproject.toml (или requirements.txt) явно фиксированы версии зависимостей, что упрощает воспроизводимость сборки.
  • [⚠ МНЕНИЕ] README подробно описывает процесс установки и примеры использования, включая безопасные placeholders для токенов.
  • [⚠ МНЕНИЕ] Скрипт transform.sh разбит на логические функции, каждая из которых отвечает за отдельный этап ETL‑процесса – это хорошая модульность.
  • [⚠ МНЕНИЕ] CI‑pipeline уже настроен (GitHub Actions), что показывает готовность к автоматическому тестированию и линтингу.

Вердикт

Рабочий, но требующий серьёзного рефакторинга – без исправления уязвимостей в зависимостях и очистки скриптов проект рискует сломаться в продакшн и стать лёгкой мишенью для DoS‑атак.

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

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