Угроза, которую пропускают классические инструменты
Большинство средств анализа кода ориентированы на поиск уязвимостей — то есть ошибок и недостатков конфигурации, через которые проект можно атаковать извне. Но этот подход не защищает от принципиально другого сценария: намеренного внедрения вредоносного кода в сам проект — поставщиком, подрядчиком или скомпрометированным участником разработки.
Один из недавних показательных случаев — инцидент с библиотекой LiteLLM: вредоносный код был встроен непосредственно в репозиторий и работал с теми же правами, что и обычное приложение, не используя никаких уязвимостей. Этот класс угроз формализован в CWE-506 (Embedded Malicious Code — встроенный вредоносный код) и традиционными инструментами безопасности, как правило, не обнаруживается.
Ключевая сложность в том, что каждое отдельное действие вредоносного кода выглядит совершенно безобидно: прочитать файл, отправить запрос в сеть, расшифровать строку, запустить процесс. Всё это встречается в сотнях легитимных библиотек. Код становится опасным только тогда, когда эти действия выстроены в конкретную последовательность — например, скрипт читает логин и пароль из переменных окружения, кодирует их и отправляет на сторонний сервер. Классические сигнатурные правила, проверяющие отдельные конструкции, такие сценарии пропускают.
Архитектура и принцип работы MOLOT
MOLOT устроена иначе: вместо проверки отдельных фрагментов она анализирует программу как последовательность действий. Из кодовой базы извлекаются все операции, которые программа совершает при работе: обращения к сети, взаимодействие с файловой системой, запуск процессов, использование криптографии и так далее. Эти действия собираются в упорядоченную последовательность и подаются на вход нейросети.
Архитектурно MOLOT построена на трансформере — том же подходе, что лежит в основе современных больших языковых моделей (LLM). Как LLM учатся понимать смысл текста по последовательности слов, MOLOT учится понимать поведение программы по последовательности её действий — и отличать паттерны, характерные для вредоносного кода, от нормальных рабочих сценариев.
Практический пример работы модели: компания принимает репозиторий от подрядчика или внешнего сотрудника. В коде присутствует типичная бизнес-логика: чтение паролей из переменных окружения, декодирование переменных, последующее использование этих данных для формирования сетевого запроса. По отдельности каждое из этих действий встречается в легитимных библиотеках, и сигнатурные правила его не помечают. MOLOT видит всю цепочку целиком и квалифицирует её как подозрительную.
Результаты тестирования и открытый бенчмарк
Тестирование на реальных вредоносных пакетах из репозиториев PyPI и npm показало, что MOLOT обнаруживает вредоносный код точнее open-source аналогов — разница достигает 30 процентных пунктов на части тестов. В сравнении с классическими правилами общая точность выше на 15%.
«Тестирование на реальных вредоносных пакетах из репозиториев PyPI и npm показало, что MOLOT находит вредоносный код точнее open-source аналогов, разница доходит до 30 процентных пунктов на части тестов. Чтобы наши результаты можно было независимо перепроверить, мы публикуем сбалансированный набор данных и сценарии запуска как открытый бенчмарк», — заявил Максим Митрофанов, руководитель ML-команды Application Security в Positive Technologies.
Открытый бенчмарк позволит сторонним исследователям и компаниям самостоятельно воспроизвести результаты и сравнить MOLOT с собственными решениями. Это относительно редкая практика для продуктовых команд в сфере безопасности.
Интеграция в PT Application Inspector
MOLOT уже встроена в PT Application Inspector — SAST-инструмент (Static Application Security Testing, статический анализ безопасности приложений) компании — начиная с релиза 6.0. По утверждению Positive Technologies, продукт стал вторым в мире SAST-решением, способным обнаруживать угрозы класса CWE-506 по поведению программы.
При каждой сработке модель не только выносит вердикт, но и подсвечивает конкретные строки кода, на основании которых было принято решение. Это позволяет аналитику безопасности за пару кликов перейти к нужному фрагменту и самостоятельно проверить вывод модели — вместо того чтобы разбирать весь репозиторий вручную.
