Читаем вместе. ИИ в AppSec: могут ли LLM работать с уязвимым кодом

[хабр-обзор] [папира]

Всем привет!

Решил расширить RG еще и на тексты Хабр, сделал разбор статьи LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks. В качестве затравки — несколько тезисов из разбора:

➡️ Результаты бенчмарка — «фотография во времени», быстро устаревающая не только по списку оцененных моделей, но и по попаданию данных в cut-off более современных LLM. Бенчмаркам на безопасность кода критически не хватает подходов по автоматическому обновлению на подобие SWE-rebench.

➡️ Очень зашли гипотезы про согласованность рассуждений и ответов, проверка на «пропатченном» коде и эксперименты с аугментацией.

➡️ Так, например, даже сильные модели ломаются на стресс-аугментациях, таких как изменения в уязвимом коде названий методов/переменных или добавление неиспользуемого кода.

➡️ Наглядная секция про техники промптинга. Практический вывод: роль-ориентированные инструкции и пошаговый CoT заметно улучшают качество (особенно в zero-shot). Но при наличии few-shot инструкций импакт от CoT снижается. Это может помочь сэкономить контекста в некоторых задачах.

➡️ Ограничение длины контекста в реальных кейсах играет критическую роль, поскольку код, приводящий к уязвимости, может находиться не только в разных частях файла, но и в разных частях проекта. Тут стоит отойти от академических статей и посмотреть на инженерные подходы к отбору контекста разработчиками Cursor, Claude-code и прочих копайлотов для разработки.
__________________

Макс Митрофанов, ML-лид направления AppSec 🟥