SAST-Genius на основе больших языковых моделей: Гибридная система статического анализа для комплексной и применимой безопасности

Исследование представляет гибридный метод SAST-Genius, который объединяет традиционный инструмент для анализа безопасности кода (SAST) и большую языковую модель (LLM). Сначала SAST-инструмент быстро находит множество потенциальных уязвимостей, включая большое количество ложных срабатываний, а затем LLM выступает в роли "умного эксперта", который анализирует каждую находку в контексте всего кода, отсеивая ложные тревоги и подтверждая реальные угрозы.

Ключевой результат: Такой двухэтапный подход позволил сократить количество ложных срабатываний на 91% и повысить точность обнаружения реальных уязвимостей с 35.7% до 89.5%, экономя огромное количество времени аналитикам.

Суть метода заключается в разделении труда между быстрым, но неточным автоматом и медленным, но "думающим" LLM. Вместо того чтобы давать LLM огромный объем информации (весь код проекта) и задавать общий вопрос ("Найди здесь уязвимости"), что дорого и неэффективно, исследователи применили более умный подход.

1. Этап 1: Генерация "кандидатов". Обычный SAST-сканер (в данном случае Semgrep) просматривает код и по формальным правилам отмечает все подозрительные места. Он работает как широкая сеть, которая ловит много "мусора" (ложных срабатываний), но зато не пропускает потенциально опасные участки.

2. Этап 2: Контекстуальная верификация с помощью LLM. Для каждого "кандидата", найденного на первом этапе, формируется специальный, очень подробный промпт для LLM. Этот промпт включает:

   • Фрагмент кода, где найдена проблема.
   • Контекст: описание "пути данных" (data flow) — откуда пришли данные (например, от пользователя) и куда они попали (например, в запрос к базе данных).
   • Четкий вопрос: "Является ли данная ситуация реальной уязвимостью типа X (например, SQL-инъекция), учитывая весь контекст? Оцени как True Positive или False Positive и объясни почему".

Таким образом, LLM не ищет проблему с нуля, а выполняет сфокусированную экспертную оценку уже найденного "подозрения". Это позволяет модели применить свою способность к глубокому контекстуальному рассуждению именно там, где это нужно, и отсеять 9 из 10 ложных тревог.

• Прямая применимость: Любой пользователь может вручную воспроизвести этот метод для своих задач. Например, при вычитке длинного документа (договора, отчета, статьи) можно сначала быстро найти все сомнительные или слабые формулировки (например, поиском по ключевым словам "возможно", "предположительно", "и т.д."). Затем для каждой такой находки можно составить отдельный промпт для LLM, предоставив окружающий текст и задав конкретный вопрос: "Является ли эта фраза двусмысленной и рискованной в данном контексте? Обоснуй".

• Концептуальная ценность: Исследование дает пользователю три ключевые идеи:

  1. LLM — это "микроскоп", а не "телескоп": он лучше всего работает, когда его просят детально изучить небольшой, но важный участок, а не обозревать огромное поле с нуля.
  2. Контекст решает всё: качество ответа LLM напрямую зависит от полноты предоставленного контекста (не просто фраза, а вся логическая цепочка).
  3. LLM может ошибаться (галлюцинировать): всегда относитесь к выводам LLM как к экспертной гипотезе, которую нужно проверить, а не как к абсолютной истине. Пример с выдуманной функцией os.path.secure_join() — отличное напоминание об этом.

• Потенциал для адаптации: Метод легко адаптируется для любой аналитической работы.

  • Для редактора: Сначала прогнать текст через простой сервис проверки грамматики и стилистики (аналог SAST), а затем самые сложные и спорные моменты отдать на анализ LLM с просьбой предложить варианты переформулировки в заданном стиле.
  • Для маркетолога: Сначала собрать все негативные отзывы о продукте (аналог "кандидатов"), а затем подать их в LLM с промптом: "Проанализируй этот отзыв. Какая корневая проблема продукта вызвала это недовольство? Классифицируй как 'Проблема с сервисом', 'Проблема с качеством', 'Неоправданные ожидания'".

Представим, что вы SMM-менеджер и анализируете предложение по рекламной кампании от подрядчика. Вы чувствуете, что в нем есть слабое место, но не можете четко его сформулировать.

Ты — опытный маркетолог-стратег с 15-летним опытом запуска успешных кампаний для онлайн-школ. Твоя задача — провести безжалостный, но конструктивный анализ предложенной стратегии, выявив слабые места в логике воронки продаж.

**КОНТЕКСТ:**
Мне представили следующую стратегию продвижения для онлайн-курса по фотографии.


**Целевая аудитория:** Начинающие фотографы, возраст 20-35 лет.
**Платформа:** Соцсеть X (бывший Twitter).
**Механика:**
1.  **Привлечение:** Мы будем ежедневно публиковать по 5 постов с красивыми фотографиями, сделанными нашими выпускниками, с хэштегами #фотография #искусство #красота.
2.  **Вовлечение:** Будем задавать аудитории вопросы в постах, типа "А что вам нравится в этом фото?".
3.  **Конверсия:** Раз в неделю будем публиковать пост со ссылкой на лендинг нашего дорогого 6-месячного курса.


**ЗАДАЧА АНАЛИЗА:**
Я подозреваю, что в этой воронке есть логический разрыв между этапом "Привлечение" и "Конверсия". Модель не понимает, как именно просмотр красивых картинок должен мотивировать пользователя перейти по ссылке и купить дорогой курс.

Проанализируй предложенный путь пользователя (user journey).
1.  Оцени, является ли моя гипотеза о разрыве в воронке верной (**True Positive**) или я ошибаюсь и стратегия жизнеспособна (**False Positive**).
2.  Если гипотеза верна, подробно объясни, **почему** этот разрыв существует и в чем заключается фундаментальная ошибка в логике подрядчика.
3.  Предложи 2-3 конкретных шага, которые нужно добавить в воронку, чтобы "мостик" между привлечением и конверсией был построен. Ответ дай в виде четкого, структурированного анализа.

Этот промпт эффективен, потому что он в точности повторяет методологию SAST-Genius:

1. Роль и цель: Задается четкая роль ("опытный маркетолог-стратег"), что настраивает модель на нужный лад.
2. Предоставление контекста: Весь план кампании заключен в теги <PROPOSAL>, давая модели полную картину для анализа.
3. Идентификация "кандидата": Вместо общего вопроса "Оцени план", мы четко указываем на "подозрительную область": Я подозреваю, что в этой воронке есть логический разрыв.... Это аналог находки SAST-сканера.
4. Сфокусированная задача верификации: Мы просим модель не просто высказать мнение, а валидировать нашу гипотезу, используя терминологию из исследования (True Positive / False Positive). Это заставляет LLM не генерировать общие советы, а провести целенаправленный анализ конкретной логической цепочки ("пути пользователя").
5. Требование объяснения и решения: Промпт требует не только вердикта, но и объяснения "почему", а также конкретных шагов по исправлению, что делает ответ максимально полезным и действенным.

Представим, что вы снимаете квартиру и анализируете пункт договора аренды, который кажется вам подозрительным.

Ты — опытный юрист, специализирующийся на жилищном праве и защите прав арендаторов. Твоя задача — проанализировать пункт договора на предмет скрытых рисков для меня, арендатора.

**КОНТЕКСТ:**
Я собираюсь подписать договор аренды. В нем есть следующий пункт, который меня беспокоит.


"8. Ответственность сторон.
8.1. В случае поломки бытовой техники (холодильник, стиральная машина, плита), находящейся в квартире, Арендатор обязуется произвести ремонт за свой счет. Арендодатель не несет ответственности за работоспособность техники."


**ЗАДАЧА АНАЛИЗА:**
Я подозреваю, что этот пункт перекладывает на меня несправедливую ответственность, особенно если техника старая и может сломаться не по моей вине.

Проанализируй этот пункт.
1.  Оцени, является ли мое опасение обоснованным риском (**True Positive**) или этот пункт является стандартной практикой и мои риски минимальны (**False Positive**).
2.  Если риск реален, объясни, какие именно негативные сценарии могут произойти для меня из-за этой формулировки. Используй простые и понятные примеры.
3.  Предложи альтернативную, более справедливую формулировку этого пункта, которую я мог бы предложить арендодателю для внесения в договор.

Этот пример работает по тому же принципу "генерация кандидата + верификация LLM":

1. "Кандидат" найден: Пользователь сам идентифицировал потенциально проблемный пункт договора (<CLAUSE>). Ему не нужно, чтобы LLM вычитывал 20 страниц юридического текста в поисках проблем.
2. Сформулирована гипотеза: Пользователь четко выражает свое опасение: "пункт перекладывает на меня несправедливую ответственность". Это и есть гипотеза для проверки.
3. Сфокусированный анализ: Промпт просит LLM не просто "прокомментировать пункт", а выполнить конкретную задачу: подтвердить или опровергнуть гипотезу (True Positive / False Positive). Это направляет анализ в нужное русло.
4. Практический результат: Запрос на объяснение рисков и предложение альтернативной формулировки превращает ответ из теоретического рассуждения в практический инструмент для переговоров с арендодателем. Модель не просто говорит "да, это рискованно", а дает готовое решение проблемы.