Почему «прошло ревью» больше не значит «безопасно»

Когда говорят про ИИ в безопасности, обычно имеют в виду будущее: «когда‑нибудь модели научатся находить уязвимости». Так вот, это будущее уже наступило, и у него есть конкретные даты и номера CVE (Common Vulnerabilities and Exposures, список известных уязвимостей). Я хочу разобрать, что именно произошло за последний год, почему это меняет правила игры для всех, кто эксплуатирует или поставляет ПО, — и что мы в ответ на это делаем у себя.

Это уже произошло

В октябре 2024‑го агент Big Sleep — совместная разработка Google Project Zero и DeepMind — нашёл эксплуатируемую ошибку повреждения памяти в SQLite. Не в студенческом проекте, а в одной из самых распространённых СУБД на планете: она стоит в каждом втором телефоне, браузере и приложении. Команда прямо назвала это первым публичным случаем, когда ИИ‑агент самостоятельно обнаружил ранее неизвестную memory‑safety уязвимость в реальном, широко используемом ПО. Баг починили в день репорта — до того, как он попал в релиз.

Через месяц вышла история, которая меня впечатлила сильнее. Google создал ИИ‑инструмент, который автоматически проверяет код на ошибки. Он проверил OpenSSL — популярную криптографическую библиотеку — и нашел уязвимость, которая позволяла злоумышленнику получить доступ к чужой памяти в системе. Эта уязвимость просидела в коде около 20 лет.

Тысячи инженеров по всему миру годами проверяли этот код вручную, нанимали аудиторов и гоняли автоматические тесты — особенно после резонансной ошибки с Heartbleed. И всё равно не нашли.

И речь уже не только о том, чтобы «найти». Две работы Иллинойского университета в 2024 году показали, что связки LLM‑агентов автономно эксплуатируют 87% one‑day уязвимостей всего по одному описанию из CVE, а командой агентов берут и zero‑day. Между «нашли дыру» и «написали рабочий эксплойт» теперь часы работы скрипта, а не недели работы человека.

Почему ручное ревью проигрывает на масштабе

У человека‑ревьюера есть три предела, которых нет у машины:

1. Усталость: после третьей тысячи строк внимание падает, и именно туда прячется баг.
2. Контекст: человек держит в голове десятки файлов, машина — миллионы строк сразу.
3. Экономическая асимметрия: защитник смотрит код один раз перед релизом, атакующий возвращается к нему бесконечно. Пока ревью стоило дорого и делалось людьми, эта асимметрия была терпимой. ИИ ее обнулил — теперь «бесконечно прощупывать» чужой код может кто угодно, у кого есть доступ к достаточно сильной модели.

Отдельная боль — длинный хвост легаси. Многие привыкли, что «старый, проверенный временем код» = «надёжный код». Раз он годами работает и его все читали, значит, там всё найдено. Это допущение больше не выдерживает проверки.

Только не спешите увольнять ревьюеров. ИИ не устает, но он может не понимать логику, заложенную в приложение или архитектурные особенности. ИИ‑сканирование остается инструментом в руках экспертов. Человек всё равно должен классифицировать находки, отклонять ложные срабатывания и принимать решения в неоднозначных случаях. В данном случае нужно дообучить специалистов промпт‑инжинирингу, архитектуре ИИ‑агентов, чтобы они понимали, как работают ИИ‑сканеры «под капотом».

Падает то, в чём мы не сомневались

Посмотрите на фон, на котором всё это происходит. Серьёзные дыры вскрываются ровно там, где мы десятилетиями были спокойны.

В OpenSSH, программе, через которую администраторы удалённо управляют серверами, нашли дыру, позволяющую постороннему человеку получить полный контроль над сервером без пароля. Эту уязвимость уже исправляли в 2006 году, но потом случайно вернули в код — и она снова пролежала там годы незамеченной. Под угрозой оказались около 14 миллионов серверов по всему миру.

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

В ядре Linux нашли уязвимость, которая пролежала там больше десяти лет и сейчас активно используется хакерами для атак с вымогательством. И это не исключение: только в ядре Linux в 2024 году обнаружили более 3000 уязвимостей. Это почти вдвое больше, чем годом ранее, а в 2025‑м их уже больше 5500. Количество уязвимостей растет стремительно.

Чего рынок ещё не осознал

Главное смещение — не техническое, а в голове. «Решение прошло ревью» перестало быть синонимом «решение безопасно». Сегодня это значит лишь, что на момент проверки человек не увидел проблемы — а человек, как мы только что показали, видит не всё.

Из этого следует неудобный вывод для всех, кто строит экосистемы из чужого кода: реальная поверхность атаки — это не только новый код, который вы вот‑вот зальёте. Это вся накопленная база уже работающих модулей, плагинов и зависимостей, которую никто не перепроверяет, потому что «она же давно в проде». Цепочка поставок ПО — главная мишень ближайших лет, и пока большая часть рынка к этому только просыпается.

Теперь при построении процессов ИБ и защитных мер точно нужно исходить из утверждения, что любое приложение может быть скомпрометировано в любой момент. В этих условиях новую актуальность получает методология Zero Trust, которая подразумевает отсутствие доверия даже к привычному, ранее проверенному

Что делаем мы

Мы решили не ждать, пока эта волна дойдёт до наших партнёров и клиентов, и встроили ИИ‑аудит как новый постоянный слой в программу «Безопасные интеграции».

Для контекста: Маркетплейс 1С‑Битрикс — это больше 2000 готовых модулей, приложений и шаблонов от сторонних разработчиков. Безопасность этой экосистемы давно выстроена как непрерывный процесс: автоматическая проверка по сигнатурам перед публикацией, экспертное ревью кода, публичный реестр уязвимостей и координированное раскрытие. ИИ‑аудит усиливает её там, где формальных правил и сигнатур не хватает, — на уровне контекстного понимания кода, позволяя находить менее очевидные классы уязвимостей в автоматическом режиме. Находки классифицируем по индустриальным стандартам — CWE и OWASP Top 10, серьёзность оцениваем по CVSS.

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

По итогам тестирования:

• в пилотном режиме 100% результатов мы перепроверили вручную;
• в 100% случаев подтвердилась необходимость выпустить исправления;
• недостатки безопасности преимущественно были в старых решениях;
• разработчики решений выпустили обновления в течение недели;
• на проверку одного решения специалисту бы потребовалась неделя.

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

Что делать вам?

Если Вы разработчик, то:

• начинайте изучать и выбирать подходящие модели и агенты для проверок безопасности;
• учитесь задавать контекст, учитывающий специфику вашего приложения и его окружения;
• проверяйте не только новый код;
• сформируйте план аудита всего кода, начиная с проверок наиболее критичных модулей;
• включите ИИ‑скан в процесс SBOM‑анализа;
• актуализируйте процесс поиска уязвимостей в коде, включив в него постоянные и периодические ИИ‑сканирования, в том числе ранее проверенных с помощью классических инструментов и с помощью ИИ‑агентов (модели постоянно становятся умнее).

Если вы компания‑пользователь приложений, то теперь акцент нужно делать не только на защите периметра:

• настройте сетевую сегментацию внутри ИТ‑инфраструктуры;
• обеспечьте насколько это возможно изоляцию системных компонентов информационных систем;
• на уровне приложений настройте защиту сессий, а в идеале стремитесь реализовать идентификацию и аутентификацию субъектов/объектов доступа при каждом чувствительном действии;
• пересмотрите процедуры аудита приложений, включая SBOM‑анализ, посмотрите доступные ИИ‑агенты, которые помогают проверить безопасность приложений
• усильте контроль при тестировании обновлений (это основной канал атак через цепочку поставок приложений);
• обеспечьте детальный мониторинг, аналитику на предмет возможных компрометаций, оперативное реагирование на инциденты ИБ.

Вместо вывода

Мы свой выбор сделали. И будем рады, если рынок перестанет считать ИИ‑аудит футурологией и начнёт считать его гигиеной.