Опубликован начальный открытый выпуск Vigolium v0.1.13-beta — сканера уязвимостей для веб-приложений, совмещающего классическое детерминированное сканирование с агентным аудитом на базе LLM. Проект доступен на GitHub и распространяется под лицензией GNU AGPLv3; коммерческая часть вынесена в облачный CloudConsole, тогда как ядро сканера заявлено как открытое.
Vigolium предлагает два основных режима работы: vigolium scan — обычное многоэтапное сканирование с поиском контента, spidering’ом через браузер, активным и пассивным аудитом; и vigolium agent — агентный режим, где LLM выбирает модули, планирует атаки, генерирует пользовательские JavaScript-расширения и совмещает динамическое тестирование с аудитом исходного кода.
Prema актуального справочника модулей, Vigolium включает 251 модуль проверки, Od njih 154 активных и 97 пассивных. Активные модули отправляют изменённые запросы и применяют fuzzing, инъекции и поведенческий анализ, пассивные — анализируют уже имеющиеся пары запрос/ответ без генерации дополнительного трафика.
Karakteristike
Native Scan — обычное детерминированное сканирование.
Режим vigolium scan предназначен для быстрых и воспроизводимых проверок. Он проходит несколько фаз: внешний сбор данных, обнаружение контента, browser/SPA-spidering и аудит. Такой режим удобен для CI, регулярных проверок и случаев, когда важно получить предсказуемый результат без участия LLM.Agentic Scan — агентный аудит с LLM.
Режим vigolium agent использует встроенный runtime olium. Агент может сам искать endpoints, выбирать модули, запускать проверки, анализировать код, выполнять SAST и повторно проверять находки. Поддерживаются сценарии Autopilot, Swarm и Query mode: от автономного сканирования цели до разовых запросов для ревью кода, поиска endpoints и обнаружения секретов.Проверки XSS, SQLi, NoSQLi, SSTI, LFI, RCE, XXE и SSRF.
В справочнике модулей перечислены проверки отражённого XSS, SQL-инъекций по ошибкам и boolean-based blind SQLi, NoSQL-инъекций, server-side template injection, local file inclusion, command injection, XXE, SSRF и out-of-band-уязвимостей. Для находок используется шкала серьёзности от critical до info и шкала уверенности certain, firm, tentative.OAST-проверки для «слепых» уязвимостей.
Vigolium умеет проверять blind XSS, blind SSRF, blind XXE и blind RCE через callback-механизмы, в том числе через interactsh. Это нужно для случаев, когда уязвимость не проявляется прямо в HTTP-ответе, но сервер делает внешний DNS/HTTP-запрос или выполняет отложенное действие.Value-aware mutation — мутация параметров с учётом смысла значения.
Сканер классифицирует параметры по семантическому типу: число, UUID, JWT, email и другие варианты, после чего подбирает мутации под контекст. Это должно уменьшать шум по сравнению с грубой подстановкой одинаковых payload’ов во все поля подряд.Поддержка разных входных форматов.
В качестве входа можно передавать URL, спецификации OpenAPI/Swagger, коллекции Postman, данные из Burp Suite, cURL и Nuclei JSONL. Также поддерживается подача URL через stdin и запуск отдельных фаз сканирования.Аутентифицированное сканирование и проверки IDOR/BOLA.
Vigolium поддерживает несколько сессий одновременно: сессии можно передавать inline, загружать из файлов или описывать полноценные login flows с извлечением токенов. Это используется для проверок горизонтального и вертикального контроля доступа, включая IDOR/BOLA и повышение привилегий.Проверки фреймворков и типовых утечек.
В списке модулей есть проверки для Next.js, Spring/Java, Django, Flask, FastAPI, Laravel, Symfony, Rails, Express и ASP.NET/IIS. Например, для Spring проверяются открытые Actuator endpoints, Spring Boot Admin, Spring Cloud Config, H2 Console, Jolokia и консоли Java application servers; для Next.js — утечки через /_next/data, SSRF в Image Optimizer и обходы middleware.JavaScript-расширения.
Пользователь может писать собственные модули и hooks на JavaScript через встроенный JS-движок с HTTP API, учитывающим сессии. Важное ограничение: такие расширения могут выполнять произвольные команды и не изолированы песочницей, поэтому их нужно воспринимать как обычный исполняемый код.Отдельная фаза triage для результатов.
В LLM-assisted security testing часто возникает проблема правдоподобных, но невоспроизводимых находок. Автор Vigolium описывает triage как отдельный проход: сначала сканер собирает кандидаты, затем отдельная проверка повторно сверяет каждую находку с доказательствами.Ограничения бюджета для агентного режима.
Для агентного сканирования можно ограничивать токены, количество вызовов инструментов, число итераций triage и общее время выполнения. Это важно для CI и пентестов с фиксированным временем: агент не должен бесконечно «копать» одну цель и сжигать бюджет на малополезные гипотезы.Отчёты, очередь и масштабирование.
В Native Scan заявлены конкурентный worker pool, per-host rate limiting, гибридная очередь в памяти, на диске или в Redis, а также самодостаточные HTML-отчёты. Для вывода доступны console, JSONL и HTML.Серверный режим, API и интеграция с Burp Suite.
Vigolium может запускаться как API-сервер, принимать трафик, включать прозрачный HTTP-прокси и автоматически сканировать полученные данные. Для Burp Suite упоминается отдельное расширение burp-vigolium, позволяющее отправлять live-трафик в сервер Vigolium.Workbench и Console.
Помимо CLI, проект описывает radna tezga — self-hosted dashboard для визуализации результатов, управления проектами и отслеживания находок. konzola — облачный коммерческий слой для managed scanning, централизованной отчётности, совместной работы и планирования проверок.
postavljanje
Проект предлагает установку через shell-скрипт, npm, Docker, Homebrew, Bun и сборку из исходников. Для сборки из исходников в README указаны требования Idi 1.26+ и bun 1.3.11+.
curl -fsSL https://vigolium.com/install.sh | bash
npm install -g @vigolium/vigolium
docker pull j3ssie/vigolium:latest
docker run —rm j3ssie/vigolium:latest scan -h
Разработчики отдельно предупреждают, что Vigolium является offensive security tool: агентный режим запускается без песочницы и получает полный доступ к shell, файловой системе и сети хоста, а расширения также могут выполнять произвольные команды. Поэтому агентные проверки рекомендуется запускать в одноразовом контейнере или виртуальной машине, ограниченной рамками конкретного тестирования.
izvor: linux.org.ru
