ИИ ускорил поиск уязвимостей. Кто успеет их исправить?

Найти опасную ошибку в программе становится проще. Доказать, что она настоящая, подготовить исправление и довести его до пользователей — по-прежнему трудная работа. В докладе на Black Hat USA 2026 исследователь Ян Шошитаишвили из Университета штата Аризона описал лабораторию, которая, по его оценке, находит уязвимости примерно в десять раз быстрее, чем успевает готовить сообщения о них.

Это разрыв между обнаружением и защитой. Для разработчика результат проверки ИИ полезен, когда из него понятно, при каких условиях возникает ошибка, что сможет сделать атакующий и как исправление закрывает этот путь. Само количество предупреждений этих ответов не даёт.

Языковая модель может прочесть код и предложить десятки подозрительных мест. Часть окажется выдумкой, часть — настоящими дефектами. Но даже точный список охватывает лишь те виды ошибок, которые модель распознаёт при такой постановке задачи. Остальные могут остаться незамеченными.

Шошитаишвили различает три способа получить больше находок: улучшить метод анализа, проверить больше программ или применить другой метод к тому же коду. Последний часто обнаруживает то, чего первый метод вообще не искал. Поэтому новое средство с большим числом находок ещё нельзя объявлять лучшим: результат зависит и от порядка проверок.

Например, фаззинг — проверка программы множеством автоматически подобранных входных данных — помогает найти случаи, в которых программа падает. Анализ кода может увидеть другие проблемы. Модель также может знать старую ошибку из обучающих материалов: тогда обнаружение знакомого дефекта нельзя считать убедительным испытанием на неизвестных уязвимостях.

В центре подхода лаборатории — свойства уязвимости. Исследователь описывает связь между данными, правами доступа и действиями программы, из-за которой возникает ошибка. Для одних дефектов важно, откуда пришли данные; для других — может ли атакующий повлиять на команду; для третьих — что произойдёт, если два действия выполняются одновременно.

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

Лаборатория применила этот подход к OpenHarmony, открытой операционной системе. В исследовании на USENIX Security 2026 команда разобрала 116 публикаций об Android, выделила 56 уникальных уязвимостей уровня проектирования и показала, что OpenHarmony подвержена 24 из них. Среди последствий — нарушение конфиденциальности, скрытое повышение прав и проблемы надёжности системы.

В изложении докладчика агенты помогали изучать историю исследований, а свойства ошибок и код OpenHarmony на этом этапе проверяли вручную. Это существенная граница: опубликованный результат нельзя целиком приписать автономной модели. Его смысл в том, что новая реализация может сохранить старую ошибку проектирования даже без копирования исходного кода.

В рассказе Шошитаишвили о проверке ядра Linux несколько десятков моделей сначала нашли около 300 потенциальных уязвимостей, позволяющих локально повысить права. Так называют ошибку, с помощью которой пользователь без административных полномочий может получить более высокие права на том же компьютере. Это конкретная модель угрозы, а не любой дефект ядра.

Затем команда связала три модели рабочим процессом с планированием и взаимной проверкой. Счёт вырос примерно до 600; докладчик говорит, что эти находки разобрали вручную. Добавление свойств исторических и свежих уязвимостей подняло заявленное число выше тысячи.

Эти цифры описывают опыт лаборатории. В докладе нет условий, позволяющих считать последовательность независимым сравнительным тестом моделей. Сам Шошитаишвили оговаривает несопоставимость своего подсчёта с публичными числами другой системы. Вывод, который подтверждает этот опыт, более узкий: способ организации поиска заметно влиял на его результат.

Сообщение разработчику должно содержать обоснованный разбор и предложенное исправление. При темпе находок, который Шошитаишвили оценивает как десятикратный относительно темпа подготовки сообщений, накопление отчётов становится отдельной проблемой. Лаборатория отказывается отправлять необработанный поток.

По его рассказу, подробности публикуют для ошибок с уже присвоенными CVE — общепринятыми идентификаторами уязвимостей. Для остальных оставляют хеши, короткие цифровые значения для фиксации находок. С производителями обсуждают временные исправления, которые могут помочь до основного обновления. Готовой замены привычному порядку раскрытия у исследователя пока нет.

Rust помогает предотвратить многие ошибки обращения с памятью. Но программа может корректно работать с памятью и всё равно неправильно проверять права, обрабатывать состояние или реализовывать криптографический алгоритм. Эти дефекты относятся к логике программы.

Шошитаишвили поручил агентам переписать распространённые библиотеки C, в том числе libssl, libpng и libxml. Получившийся код собирался и работал. Однако известные ошибки логики появлялись снова, даже когда агентам прямо запрещали переносить старые дефекты. Повторная проверка находила то, что запрет в запросе не предотвратил.

Позднее опубликованный проект SafeLibs предлагает совместимые замены библиотек Ubuntu на Rust. На сайте прямо сказано, что люди не проверяли код и перевод может добавить новые ошибки вне работы с памятью. Это исследовательский эксперимент с существенными ограничениями, а не подтверждённая безопасная замена рабочих библиотек.

Шошитаишвили выступает за доступ защитников к мощным инструментам и считает обучение кибербезопасности особенно полезным сейчас. Это его позиция: агенты расширяют объём работы, которую способен выполнить специалист, а постановка задачи и оценка результата требуют знаний о системе.

В финале он возвращается к исследовательским прототипам. Агент может провести опыт, увидеть провал в новых условиях и помочь изменить программу. Человек задаёт условия испытания и решает, какой результат является доказательством. Для поиска уязвимостей эта граница определяет всё: говорить о безопасности можно только после проверки того пути, которым реально может воспользоваться атакующий.