MOLOT от Positive Technologies: как BERT-энкодер ищет вредоносный код без GPU и галлюцинаций — VogueTech

Что нового

Positive Technologies выпустила ML-модуль MOLOT для статического анализа кода в составе PT Application Inspector. Это не LLM, а модель на базе классического BERT-энкодера, заточенная под поиск вредоносного кода по цепочкам вызовов.

Ключевые факты:

Архитектура: BERT-энкодер bert-base-uncased, без modern/neo-надстроек.
Тип задачи: бинарная классификация файлов проекта по признаку вредоносности.
Фокус: вредоносный код по цепочкам вызовов (call chains), а не по отдельным строкам.
Контекст: работа с цепочками до 4096 токенов показала отсутствие выигрыша в качестве, поэтому команда осталась на стандартном контексте BERT.
Производительность: MOLOT целится в запуск на CPU с нормальной пропускной способностью памяти, без обязательного GPU. Для языковых моделей масштаба 1B параметров разработчики не смогли получить сопоставимую скорость при похожем качестве.
Интерпретация: кастомный SHAP-анализ даёт 81% согласованности по строкам кода, которые выбирают эксперты при разметке вредоносных фрагментов.
Качество: метрики подтверждены на открытом бенчмарке Open Malicious Code Benchmark (OMCBench): 400 вредоносных и 400 легитимных пакетов из PyPI и npm. Этот датасет — часть закрытого набора на 4,5 тыс. примеров, на котором изначально считали метрики.
Сравнение по классу задач: MOLOT по качеству детектирования вредоносного кода по цепочкам вызовов находится на уровне Mythos от Anthropic и не подвержен промпт-инъекциям по определению (нет генеративного компонента).

Как это работает

MOLOT встраивается в PT Application Inspector и работает как ML-ядро для поиска вредоносного кода. Под капотом — классический BERT-энкодер и несколько этапов препроцессинга и постобработки.

1. Построение графа вызовов и сбор переменных

Сначала PT Application Inspector разбирает исходный код и строит граф вызовов (call graph) плюс информацию о переменных. Это важный момент: модель не читает файл сверху вниз, как LLM, а опирается на реальную структуру исполнения.

Причины такого подхода:

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

2. Разбиение графа на цепочки вызовов по файлам

Дальше граф разбивают на цепочки вызовов для каждого файла. Это нужно сразу по нескольким причинам:

оптимизация длины контекста для BERT;
соответствие требованиям к SAST-инструментам: нужен не только вердикт по проекту, но и локализация проблемы в конкретном файле;
защита от кейсов, когда вредоносный фрагмент написан на другом языке, чем основной код проекта (встречалось в реальных кампаниях).

Итог: модель всегда работает на уровне файла, а не только репозитория.

3. Переход от цепочки вызовов к цепочке активностей

Цепочку вызовов преобразуют в цепочку активностей. Этот подход вдохновлён архитектурой Cerebro, но команда Positive Technologies переработала его под задачи статического анализа.

Что здесь происходит:

из графа вызовов и данных о переменных формируют абстрактные «активности» — семантические шаги поведения кода;
устраняют ограничения оригинального Cerebro, чтобы повысить стабильность анализа и качество детектов на реальных проектах;
получают компактное, но содержательное представление поведения файла, которое удобно подавать в BERT.

4. Классификация в BERT-энкодере

На вход BERT подаётся токенизированная цепочка активностей. Модель обрабатывает всю последовательность целиком и на выходе возвращает вердикт: вредоносный файл или нет.

Ключевое отличие от LLM:

нет автодополнения и предсказания следующего токена;
нет декодера и вероятностного выбора следующего слова;
модель принимает одно финальное решение по всей последовательности.

Из-за этого архитектура не страдает от галлюцинаций в привычном для LLM смысле: она не «выдумывает» текст, а только классифицирует уже существующую последовательность.

5. Интерпретация результата и возврат к исходному коду

Самая чувствительная часть для безопасной разработки — объяснение, почему ML сказал «вредоносно».

MOLOT решает эту задачу так:

Для цепочки активностей запускают кастомный SHAP-анализ, чтобы понять вклад каждого токена в вердикт.
Через связку «активность → граф → строка кода» система возвращает подсвеченные строки исходника, на которые «смотрела» модель.

Результат: специалист по безопасной разработке видит конкретные строки в файле, которые повлияли на решение ML. По внутренней проверке Positive Technologies, подсветка совпала с выбором экспертов по вредоносному коду в 81% строк.

Что это значит для вас

Когда MOLOT полезен

MOLOT пригодится, если вы:

занимаетесь безопасной разработкой и уже используете или планируете использовать SAST-инструменты;
проверяете сторонние пакеты из PyPI и npm и хотите ловить вредоносный код на уровне поведения, а не только по сигнатурам;
работаете в среде, где GPU недоступен или дорог, а запускать ML-модели всё равно нужно локально;
хотите снизить риск галлюцинаций, которые LLM может выдать при анализе кода, и получить чёткий бинарный вердикт с объяснением.

Типичные сценарии:

интеграция в pipeline CI/CD через PT Application Inspector;
регулярные проверки внутренних и внешних репозиториев;
аудит open source-зависимостей на предмет вредоносных вставок.

Где MOLOT не поможет

MOLOT — это не универсальная нейросеть для работы с кодом. Он не:

пишет код и не дополняет его, как GPT-4o или Claude 3.5;
делает рефакторинг или ревью стиля;
отвечает на вопросы о бизнес-логике проекта.

Если вам нужно:

автодополнение кода;
генерация юнит-тестов;
объяснение архитектуры проекта на естественном языке;

— MOLOT не заменит LLM. Его зона ответственности — поиск вредоносного поведения в коде.

Доступность и требования

MOLOT — часть PT Application Inspector. Системные требования на стороне ML-модуля рассчитаны на запуск:

на CPU, без обязательного GPU;
с учётом ограничений по памяти и пропускной способности, характерных для локальных серверов.

Если инфраструктура компании уже тянет PT Application Inspector, дополнительных GPU-ресурсов под MOLOT не потребуется.

Информация о необходимости VPN или ограничениях по региону доступа к PT Application Inspector зависит от лицензирования и политики Positive Technologies. Перед внедрением стоит проверить условия поставки именно для вашей юрисдикции.

Место на рынке

MOLOT работает в нише поиска вредоносного кода в цепочках вызовов и конкурирует в первую очередь не с чат-ботами, а с другими системами статического анализа и специализированными ML-моделями для кибербезопасности.

По классу задач его логично сравнивать с:

Mythos от Anthropic — тоже ML-подход к детектированию вредоносного кода по поведению.

Что известно из описания MOLOT:

по качеству детектирования вредоносного кода на цепочках вызовов MOLOT показывает уровень, сопоставимый с Mythos;
MOLOT не уязвим к промпт-инъекциям, потому что не использует генерацию текста и не принимает текстовые промпты от пользователя.

Относительно больших языковых моделей (масштаба ~1B параметров):

команда Positive Technologies отказалась от LLM этого размера, потому что при сопоставимом качестве детектирования скорость работы и требования к ресурсам оказывались хуже, чем у BERT-энкодера;
encoder-only архитектура позволяет держать высокую производительность на CPU, чего не получилось бы добиться с LLM аналогичного масштаба в рамках тех же ограничений.

С точки зрения рынка SAST-инструментов MOLOT добавляет к PT Application Inspector ML-слой, который ориентирован именно на malicious code, а не только на классические уязвимости (SQL-инъекции, XSS и т.д.). Это даёт отдельный сценарий использования: поиск кода, который намеренно встроили в проект для кражи данных, обхода защиты или получения удалённого доступа.

Итоги

MOLOT — это приземлённый, но практичный ход: вместо того чтобы встраивать ещё одну большую языковую модель в продукт, Positive Technologies взяла проверенный BERT-энкодер и выжала из него максимум за счёт:

работы с графами вызовов и цепочками активностей;
аккуратной подготовки датасетов (включая OMCBench из 800 пакетов);
интерпретации через SHAP с привязкой к строкам кода.

MOLOT подойдёт тем, кто:

уже живёт в экосистеме PT Application Inspector или рассматривает его;
хочет подстраховать себя от вредоносных зависимостей и закладок в коде;
не готов тянуть ещё одну LLM на GPU только ради поиска malicious code.

Если же приоритет — генерация кода, умный ассистент в IDE или диалоговый разбор архитектуры, лучше смотреть в сторону GPT-4o, Claude или аналогичных моделей, а MOLOT использовать как отдельный слой безопасности поверх обычных SAST-проверок.