LlamaIndex 0.14.25: сорок пакетов, один и тот же баг

LlamaIndex выпустил версию 0.14.25 - и апдейт задел не библиотеку целиком, а больше сорока отдельных пакетов: агентные модули под Azure и AgentMesh, коннекторы к Argilla, Arize Phoenix, Honeyhive, Langfuse, LiteralAI и ещё десяток пакетов помельче.

Формулировка фикса в каждом одинаковая - «resolve a ton of security alerts».

Повод скромный, техническая новость без драмы.

Но за ней стоит вопрос, который компания, строящая RAG-контур на LlamaIndex, обычно себе не задаёт: сколько отдельных пакетов реально нужно пропатчить, чтобы закрыть одну проблему безопасности. LlamaIndex давно перестал быть одной библиотекой.

Каждый коннектор к внешнему сервису оформлен отдельным pypi-пакетом со своей версией и своим набором зависимостей: `llama-index-callbacks-langfuse` тянет клиент Langfuse, `llama-index-agent-azure` - Azure SDK, `llama-index-callbacks-arize-phoenix` - Phoenix. У каждого пакета свой список транзитивных зависимостей, а значит свой набор уязвимостей, которые сканеры вроде Dependabot или pip-audit находят независимо друг от друга.

Когда в базовой зависимости - обычно это что-то вроде `requests`, `urllib3` или `fastapi` - находят CVE, алерт прилетает сразу в десятки пакетов, по числу модулей, закрепивших эту зависимость в своём `pyproject.toml`.

Отсюда формулировка «resolve a ton of security alerts»

, повторённая в changelog сорок с лишним раз: разработчики LlamaIndex закрывали одну и ту же дыру, размноженную архитектурой на десятки версий.

Компания, поставившая LlamaIndex с пятнадцатью экстра-модулями под конкретный RAG-пайплайн, получает после такого релиза пятнадцать задач: проверить, что новая версия каждого модуля не сломала совместимость с остальными четырнадцатью.

Время на это редко закладывают в спринт - фреймворк держат за готовую инфраструктуру, хотя это код, который нужно сопровождать.

Здесь та же логика, что и с TTU - временем до результата.

Зрелая команда не ставит LlamaIndex и не забывает про него - она строит процесс вокруг него: автоматический скан зависимостей (Dependabot, Renovate, pip-audit) с PR на каждый CVE, закреплённые lock-файлы вместо диапазонов версий, регулярный аудит того, какие из установленных экстра-модулей вообще используются в проде.

Каждый неиспользуемый коннектор увеличивает поверхность атаки без всякой пользы. ###

Как это закрывается инженерно В проектах, где мы в KT.Team ставим LLM & Security Gateway, агентный код и RAG-пайплайн не обращаются к провайдерам моделей и внешним сервисам напрямую - трафик идёт через шлюз, который сам решает, куда какой ключ и какой запрос попадает. LlamaIndex всё равно нужно патчить - шлюз этого не отменяет.

Но он снижает цену ошибки: если уязвимый коннектор из релиза 0.14.25 попадёт в прод до патча, у него нет прямого доступа к боевым секретам и внешней сети - только к тому, что явно разрешил шлюз. MCP-интерфейс поверх такой архитектуры даёт вторую выгоду: агент обращается к инструменту через протокол, а не через прямой импорт конкретной версии пакета, поэтому обновление или замена библиотеки внутри контура не требует переписывать бизнес-логику агента.