Иногда в мире технологий появляется идея, которая на первый взгляд кажется неочевидной: «взять действительно нетривиальную задачу и свести её к обычному ранжированию документов». Именно об этом рассуждает автор блога noperator, предлагая свежий взгляд на некоторые сложные проблемы в области ИБ (информационной безопасности) и тестирования.
🤔 Что такое «ранжирование документов»?
Ранжирование документов — классическая задача в сфере информационного поиска (IR - Information Retrieval). Мы пытаемся упорядочить набор «документов» по релевантности к «запросу». Веб-поисковики именно так работают с нашими поисковыми запросами, сортируя миллионы страниц. Но если вместо веб-страниц взять патч-диффы (Patch diffs) - кусочки кода с изменениями), а «запросом» сделать описание уязвимости — оказывается, что LLM (Large Language Model) вполне может прикинуться «поисковиком» и показывать, где конкретно спрятано решение проблемы.
🎯 Ключевая мысль автора
Автор доказывает, что:
- LLM можно эффективно использовать как сравнивающий механизм для списочного ранжирования документов.
- Даже очень сложные инженерные задачи (например, поиск в патче того места, где исправлена уязвимость) можно свести к ранжированию документов.
Это означает, что вместо глубокой экспертизы в бинарных файлах, дизассемблировании и анализе контекста уязвимостей, можно сделать шаг назад и рассмотреть проблему с точки зрения соответствия документов (патч-диффов) описанию уязвимости.
💡 Пример с «N-day» уязвимостями
Чаще всего мы говорим о N-day (публично раскрытые - publicly disclosed) уязвимостях, когда уже вышло исправление (патч), но исследователь хочет понять, какая именно часть кода устраняет брешь.
- 🐣 Новая методика: Использовать LLM для семантического поиска совпадений между описанием бага и изменениями в коде.
- 🔎 Инструмент: Автор привёл пример утилиты raink, которую он опубликовал на Bishop Fox blog. Она берет на вход набор патчей (разбитых на отдельные «документы») и ранжирует их, используя GPT-модель для оценки релевантности.
Результат: вместо ручного просмотра сотен или тысяч функций, мы сразу получаем список наиболее вероятных изменений, содержащих исправление.
⚙️ Как это реализовано
- 📝 Списочное ранжирование (Listwise-рейтинг) против попарного ранжирования (pairwise).
Традиционно некоторые исследователи используют «попарное сравнение»: LLM говорит, «какой документ более релевантен: A или B». Это даёт качественный результат, но очень долго при большом числе документов. - 📚 Списочный подход (Listwise-подход): формируем «список» патчей и просим LLM упорядочить все сразу. Такая методика может быть оптимальнее по числу запросов, хотя и сложнее в реализации, ведь модели приходится анализировать всё разом.
- 🏷️ Стоимость обработки (Reedeming cost): по словам автора, он смог обработать около 1600 функций и найти нужный фикс менее чем за 5 минут и за $0.30 (при использовании GPT-4o mini).
- 🎩 Улучшение уверенности: после получения списка можно брать топ-N результатов и повторно «доранжировать» их — либо проверять их автоматически (например, загружать PoC-эксплойт и смотреть, какой участок кода закрывает дыру).
🚀 Какие задачи решаются?
- 🛡️ Сравнение исправлений: как уже говорилось, найти конкретную строчку кода, где исправлена уязвимость.
- 🏴☠️ Аудит безопасности: при тестировании, например, можно искать самые «опасные» места кода для фаззинга (fuzzing) или потенциальные точки внедрения (injection points) в веб-приложении.
- 🤖 Автоматическая генерация PoC (доказательства концепции): автор упоминает идею использовать LLM, чтобы она не просто нашла фиксы, но и сформировала автоматическую проверку (Proof-of-Concept). Это позволяет «верифицировать» результаты ранжирования.
🏷️ «Неприличная» эффективность LLM
Авторы докладов (например, Thomas Dullien на FUZZING ‘24) всё чаще говорят о «необычайном успехе» фуззинга, а теперь и о «необычайном успехе» больших языковых моделей. При этом:
- 🪄 LLM упрощает жизнь разработчикам и исследователям: они берут сложные задачи и сводят к «простой» формуле: «какие из этих документов наиболее релевантны моей проблеме?»
- 🔮 Перспектива: Такой подход может стать стандартным для автоматизированного аудита кода и патчей, когда LLM подсказывает, куда смотреть.
🤝 Ссылки и материалы
- Основная статья автора: Hard problems that reduce to document ranking
🤷 Личное мнение
Мне кажется, в этом подходе есть доля «магии» (спасибо мощным LLM), но и много практической пользы. Умение анализировать патчи и сопоставлять их с описаниями уязвимостей прокладывает путь к более автоматизированному аудиту безопасности, где инженеру остаётся только проверять наиболее вероятные исправления. И если это позволяет сэкономить месяцы ручного труда при масштабном анализе кода, то, возможно, мы становимся свидетелями зарождения одного из перспективных направлений в области атакующей (и не только) безопасности.