javanet: self-hosted триаж артефактов и анализ уязвимостей для изолированных контуров (Go + локальный ИИ)
 

javanet - это self-hosted (разворачиваемая локально) платформа для статического анализа защищённости и триажа артефактов с поддержкой локального искусственного интеллекта.
Для чего она нужна​
Платформа предназначена для организаций с жёсткими требованиями к изоляции данных (банки, госсектор, критическая информационная инфраструктура, оборонные предприятия). Этим организациям законодательно или внутренними политиками запрещено отправлять свои бинарные файлы, исходный код или карты сетей в облачные сканеры уязвимостей (такие как Qualys, Snyk, Wiz). javanet закрывает эту потребность, работая полностью внутри изолированного контура (air-gapped).
Как это работает (Пайплайн)​
Приём и идентификация: Система принимает неизвестный артефакт. Тип файла определяется по магическим числам (сигнатурам), а не по расширению.
Статический анализ: Проводится декомпиляция, анализ энтропии, поиск опасных импортов и уязвимых зависимостей. Код никогда не исполняется (динамический анализ запрещён архитектурой).
Сверка с угрозами: Данные сверяются с локальной, регулярно обновляемой базой уязвимостей (NVD, OSV, CISA KEV, EPSS) и SBOM.
Приоритизация: Рассчитывается детерминированный скоринг риска (0-100) на основе реальных факторов: базовый CVSS, подтверждение активной эксплуатации (CISA KEV), наличие публичного эксплойта и вероятность (EPSS).
Отчётность и аудит: Генерируется экспортируемый отчёт. Все действия записываются в криптографически хешированный, неизменяемый (append-only) журнал на уровне триггеров базы данных для обеспечения проверяемой цепочки владения (chain of custody) перед регулятором.
Техническая архитектура​
Форм-фактор: Единый исполняемый бинарный файл (Go), включающий в себя веб-интерфейс (React SPA).
Зависимости: Требует только PostgreSQL 16 (с расширением pgvector для локального RAG) и локальный сервер LLM (Ollama).
ИИ: Используется исключительно в режиме советника (advisory-only). Модель не принимает автономных решений, не пишет в конфигурации и не взаимодействует с сетью. Все её выводы требуют подтверждения человеком.
Текущий статус разработки​
Готово: Программный код написан (более 21 000 строк продакшн-кода на Go, 323 теста), протестирован локально и упакован в нативные установщики для Windows и различных дистрибутивов Linux.
Не реализовано: В системе отсутствуют механизмы биллинга/лицензирования, нет полноценного разграничения ролевого доступа (RBAC) во всех 22 модулях и не реализована мультитенантность.

P.S - Это специализированный инженерный инструмент, заменяющий собой связку из множества разрозненных open-source утилит и электронных таблиц в изолированных контурах, предоставляя единый, проверяемый и безопасный процесс анализа уязвимостей.

Для добровольного пожертвования в развитие
BTC
bc1qzxh7cvvsff24heshtj4np0glt32errmkelgsrv
ETH
0xAAE9D927315F7260e07DA3EaC493Ce783a58a90E

Модуль JVN-Findings - реестр находок
Зачем он нужен

Раньше у нас было так: сканеры выдают кучу отчётов, кто-то вручную сводит их в таблицы, потом переносит в тикеты, потом отдельно считает просрочки - и это всё каждый раз заново. JVN-Findings это вытаскивает из разных мест и собирает в одном реестре. Все результаты - в одном списке, без ручной перегонки данных.

Что видно по каждой находке

По каждой записи можно сразу понять:
откуда пришла проблема;
на какой объект или путь она указывает;
насколько она критична;
в каком состоянии находится;
есть ли CVE;
входит ли в CISA KEV;
какой срок устранения установлен;
нарушен ли этот срок;
как менялся статус;
кто и что решил.

Главная мысль: ИБ-команда видит актуальную картину по всем рискам в одном месте, а не по частям в разных системах.

Как живёт находка

У каждой находки есть свой жизненный цикл:
обнаружено → открыто → триаж → работа над исправлением → проверка → закрыто.

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

Приоритеты
Уровни критичности:
🔴 Критический
🟠 Высокий
🟡 Средний
🔵 Низкий
⚪ Информационный
И отдельно система выделяет уязвимости из CISA KEV - чтобы их не затеряли среди сотен других записей. Это позволяет команде не разбирать всё подряд с одинаковым вниманием, а сосредоточиться на самом опасном.

Сроки и просрочки

Для каждого уровня критичности задаётся свой SLA. Пример:

Критичность SLA
Критическая 7 дней
Высокая 30 дней
Средняя 90 дней
Низкая 180 дней
Информационная 365 дней
Система сама отслеживает, где срок вышел, и показывает это прямо в реестре. Например: «Критические - 6 открытых, все 6 просрочены». Больше не нужно вручную сверять даты в Excel.

Фильтры и работа с дублями

Реестр позволяет отфильтровать находки по критичности, статусу, типу анализа, CVE, KEV, факту просрочки, объекту, пути. Есть и сворачивание дублей - особенно актуально, когда сканеры запускаются повторно. Вместо бесконечного потока одинаковых записей инженер видит одну логическую находку и работает с ней.

История изменений

Все ключевые решения по находке попадают в лог. В любой момент можно восстановить:
что нашли → когда нашли → какой статус поставили → какое решение приняли → кто принял → на каком основании → до какого срока.

Для аудита - как внутреннего, так и внешнего - это практически обязательная вещь.

Что в итоге получает ИБ-команда

Было:

сканеры → куча отчётов → CSV → Excel → ручной триаж → тикеты → ручной контроль SLA

Стало:

анализаторы → единый реестр → приоритеты → SLA → назначенный ответственный → устранение или принятие риска → аудит-логи

То есть модуль становится связующим звеном между тем, что нашли сканеры, и тем, что с этим делают дальше.


P.s - при написании текста была использована ИИ.