В последнее время искусственный интеллект все чаще упоминается в обсуждениях информационной безопасности, причем не только как инструмент обнаружения угроз или автоматизации разработки. Я вижу, что все больше внимания уделяется тому, как большие языковые модели и автономные ИИ-агенты могут использоваться для поиска уязвимостей, подготовки атак и эксплуатации недостатков программных систем.
Один из распространенных прогнозов заключается в том, что дальнейшее развитие ИИ неизбежно приведет к росту числа кибератак. Объяснение выглядит достаточно убедительным: если раньше поиск сложной уязвимости требовал специальных знаний, времени и значительных усилий, то теперь часть этой работы может выполнять искусственный интеллект. А если объединить несколько моделей с инструментами и предоставить им возможность самостоятельно планировать действия, то участие человека потенциально может свестись только к постановке задачи.
Из этого возникает еще более радикальное предположение: для проведения технически сложной атаки скоро вообще не потребуется разбираться в информационной безопасности, достаточно будет получить доступ к подходящей модели или агентной системе.
Но насколько эти предположения соответствуют действительности?
Сам факт того, что ИИ способен обнаружить уязвимость, еще не означает, что неподготовленный человек сможет воспользоваться этой возможностью. Точно так же успешное выполнение агентом лабораторного задания не доказывает, что он способен самостоятельно компрометировать реальные информационные системы.
Есть тут и другая сторона вопроса. ИИ делает доступнее не только исследование уязвимостей, но и создание программного обеспечения. Сегодня человек без инженерной подготовки может с помощью ИИ разработать веб-приложение, подключить базу данных, реализовать пользовательскую авторизацию и опубликовать сервис в интернете. Однако способность создать работающее приложение не предполагает автоматически понимания его архитектуры, ограничений и требований безопасности.
При этом профессиональные защитники тоже используют ИИ. Автоматизация анализа исходного кода, обнаружения ошибок и подготовки исправлений развивается не менее активно, чем инструменты, применимые для наступательных операций.
Получается довольно противоречивая картина.
Искусственный интеллект делает сложные технические возможности доступными все большему числу людей. Но означает ли доступность этих возможностей наличие знаний и компетенций, необходимых для их безопасного и ответственного применения?
Чтобы разобраться в этом вопросе, я решил обратиться к четырем конкретным случаям и исследованиям. Они охватывают разные стороны информационной безопасности: обнаружение сложных уязвимостей, влияние ИИ на результативность неподготовленных пользователей, проблемы безопасности приложений, созданных с помощью ИИ, и возможности автономных защитных систем.
Это не попытка с моей стороны провести исчерпывающий обзор всей отрасли или спрогнозировать количество будущих кибератак, а скорее, возможность сопоставить несколько уже наблюдаемых явлений и отделить подтвержденные результаты от выводов, которые пока делать преждевременно.
PHP2Shell: когда искусственный интеллект помогает находить сложные уязвимости
21 октября 2026 года разработчики PHP выпустили обновления безопасности, устраняющие две критические уязвимости ядра интерпретатора: CVE-2026-109618 и CVE-2026-109619. Исследователи, занимавшиеся их анализом, использовали для них общее название PHP2Shell.
Уязвимости затрагивали низкоуровневые механизмы управления памятью и обработки ошибок. При определенных условиях они позволяли добиться удаленного выполнения кода, в том числе без предварительной аутентификации.
Первая проблема, CVE-2026-109618, была связана с некорректной обработкой состояния при исчерпании доступной памяти. В определенных обстоятельствах PHP мог оставить частично инициализированные внутренние структуры, которые впоследствии воспринимались как корректные. В результате возникали условия для повреждения памяти и выполнения произвольного кода.
Вторая, CVE-2026-109619, относилась к сохранению некорректного глобального состояния после фатальной ошибки. Внутренние структуры могли содержать ссылки на уже освобожденную память, создавая возможность ее повторного использования с непредусмотренными последствиями.
Особенность этих уязвимостей заключалась в том, что они находились не в конкретном пользовательском приложении, а непосредственно в интерпретаторе, причем в механизмах, которые участвуют в обработке огромного количества запросов.
Подробное техническое описание и обстоятельства раскрытия приведены в публикации PHP Foundation от 21 октября 2026 года, вы можете ознакомиться с ним самостоятельно. Там довольно интересно.
На первый взгляд, перед нами обычная история обнаружения и устранения критических уязвимостей, но ее хронология представляет значительно больший интерес.
Уязвимость, о которой подозревали ещё в 2024 году
Как следует из объяснения PHP Foundation, первые признаки проблемы, впоследствии получившей идентификатор CVE-2026-109618, были обнаружены еще в 2024 году.
Тогда проводился внешний аудит безопасности PHP, организованный при участии Quarkslab и OSTIF. В ходе устранения одной из выявленных проблем разработчик ядра PHP обнаружил признаки некорректного поведения механизма управления памятью.
Потенциальная возможность эксплуатации обсуждалась, однако конкретного способа добиться удаленного выполнения кода на тот момент обнаружено не было.
Возникла и другая проблема: возможные подходы к исправлению затрагивали обратную совместимость, производительность и взаимодействие со сторонними расширениями. Разработчики не могли выбрать решение, которое одновременно устраняло бы проблему и не создавало существенных побочных последствий.
Работа неоднократно останавливалась и возобновлялась.
PHP Foundation впоследствии прямо признала, что задержка была связана не только с технической сложностью, но и с недостатками организации работы и ограниченностью ресурсов команды.
В 2026 году ситуация изменилась.
При поддержке программ исследования безопасности несколько независимых команд, включая Calif, OpenAI и Wiz, представили результаты, позволившие установить практическую эксплуатируемость проблемы. В процессе применялись современные инструменты ИИ-анализа, а также традиционные методы исследования уязвимостей.
В частности, PHP Foundation сообщила об использовании Claude Mythos при исследовании кодовой базы и OpenAI Daybreak Red для проверки сообщений и сценариев эксплуатации. Дополнительные подробности о работе исследователей опубликованы в техническом разборе Wiz и материале Calif.
Здесь я считаю необходимым подчеркнуть важную деталь:
ИИ не обнаружил всю проблему с нуля и не выполнил самостоятельно полный цикл исследования.
Ее первоначальные признаки были известны специалистам задолго до появления соответствующих отчетов 2026 года. Именно исследовательская работа людей, дополненная современными инструментами, позволила установить тяжесть последствий и продемонстрировать практические сценарии эксплуатации.
Это не умаляет значения ИИ, а напротив, позволяет точнее определить характер его вклада.
От обнаружения ошибки к исследованию ее последствий
В информационной безопасности существует существенная разница между обнаружением подозрительного поведения программы и доказательством того, что это поведение можно использовать для нарушения безопасности.
Например, аварийное завершение процесса или некорректное управление памятью еще не означает возможности удаленного выполнения кода. Чтобы установить такую возможность, необходимо исследовать условия возникновения ошибки, состояние памяти, особенности среды исполнения и последовательность событий, при которой дефект становится практически значимым.
Эта работа требует не только механического перебора вариантов, но и анализа сложных технических взаимосвязей.
Современные ИИ-системы способны участвовать в подобных исследованиях: анализировать большие фрагменты исходного кода, предлагать гипотезы, помогать разрабатывать проверки и интерпретировать их результаты.
В случае PHP2Shell использование ИИ стало частью процесса, позволившего уточнить последствия давно замеченной проблемы.
Однако из этого случая нельзя вывести какой-то универсальный коэффициент ускорения поиска уязвимостей. В публичных материалах я не нашел сопоставимого эксперимента, который позволял бы утверждать, что конкретная задача с ИИ выполняется в определенное количество раз быстрее, чем без него.
Также я думаю, что нельзя сделать вывод, что любую аналогичную уязвимость теперь способен обнаружить неподготовленный пользователь.
Речь идет о результатах профессиональных исследовательских команд, работавших со сложной программной системой и использовавших специализированную инфраструктуру.
Тем не менее вывод уже достаточно существенный: ИИ уже является практически применимым инструментом сложных исследований безопасности, а не просто средством генерации кода или справочных ответов.
Обратная сторона ускорения
Есть в этой истории и еще одно обстоятельство, которое меня заинтересовало.
PHP Foundation сообщила, что рост количества исследований с применением ИИ привел к увеличению потока сообщений о потенциальных уязвимостях. Среди них встречаются настоящие проблемы, повторные обнаружения и сообщения, которые невозможно воспроизвести.
С 1 июля 2026 года команда опубликовала 15 CVE и обработала более 100 сообщений, оказавшихся некорректными, дублирующими или невоспроизводимыми.
Получается интересный эффект: ИИ может ускорять исследовательскую работу, но одновременно увеличивать нагрузку на тех, кто обязан проверять результаты и принимать решения об исправлениях.
Автоматизация обнаружения еще не означает автоматизации всего процесса обеспечения безопасности. Для выпуска исправления требуется оценить последствия изменения, проверить совместимость, провести тестирование и организовать распространение обновлений.
Часть этих операций очевидно также можно автоматизировать, но необходимость ответственного технического решения никуда не исчезает.
Таким образом, PHP2Shell показывает сразу две стороны применения ИИ: расширение возможностей исследователей и увеличение требований к процессам обработки результатов исследования.
При этом лично у меня остается вопрос, насколько эти возможности доступны человеку, не обладающему необходимой квалификацией.
RAND: действительно ли ИИ позволяет атаковать без специальных знаний?
28 мая 2026 года RAND Corporation опубликовала исследование Investigating the potential use of frontier AI models for offensive cyberattacks: A human uplift study.
Работа выполнялась по заказу британского AI Security Institute и была посвящена вопросу, который непосредственно связан с распространенными опасениями относительно ИИ: насколько доступ к современным моделям увеличивает способность людей с различным уровнем подготовки выполнять наступательные операции в области кибербезопасности?
Особенно здесь для меня была интересна методология исследования.
В отличие от демонстраций, в которых профессиональный исследователь показывает, как модель справляется с некоторой технической задачей, здесь оценивалось влияние ИИ на действия самих участников.
Что проверяли исследователи
В рандомизированном контролируемом эксперименте участвовали 157 человек с различным уровнем технической подготовки.
Исследование проводилось с сентября 2025 по январь 2026 года.
Участникам предлагались задачи, связанные с сетевыми операциями, эксплуатацией особенностей операционных систем, поиском и использованием уязвимостей.
Примерно половина участников получала доступ к современным ИИ-моделям, другая половина выполняла задания без такой помощи. В эксперименте использовались несколько передовых моделей, включая OpenAI o3, GPT-5, Claude Opus 4.1, Claude Sonnet 3.7 и Gemini 2.5 Pro.
Исследователи оценивали не только выполнение отдельных действий, но и способность участников завершать последовательности связанных задач, представляющих собой условные цепочки атак.
Я считаю, что это принципиально важно.
Можно успешно выполнить отдельную операцию, например разобраться в назначении инструмента или обнаружить подозрительное поведение программы, но не суметь воспользоваться результатом для достижения конечной цели. В реальной кибератаке успех часто зависит именно от способности последовательно преодолевать несколько технических препятствий.
Что показал эксперимент
Главный результат оказался гораздо менее однозначным, чем можно ожидать из популярных рассуждений о всемогуществе ИИ.
Для успешного завершения трех полных цепочек атак исследователи в целом не получили статистически значимых оценок преимущества участников, использовавших ИИ. Большинство участников не смогли завершить наиболее сложные сценарии независимо от того, имели ли они доступ к моделям.
Однако на отдельных этапах помощь ИИ была заметнее.
Например, в самом простом сценарии среди новичков наблюдалось увеличение доли успешных завершений на 18 процентных пунктов, тогда как среди технически подготовленных участников соответствующая оценка составляла 5 процентных пунктов.
При этом исследователи подчеркивают ограниченность статистической определенности таких результатов.
Еще интереснее различие между начальными и последующими этапами выполнения заданий.
У новичков эффект ИИ был особенно заметен в начале работы, когда требовалось разобраться в условиях, освоить базовые понятия и понять, какие действия вообще необходимо предпринять. Исследователи назвали это onboarding uplift: ИИ облегчал первоначальное погружение в задачу, но не обязательно обеспечивал преимущество при выполнении всей последовательности операций.
Иными словами, модель могла помочь человеку начать движение, но не гарантировала, что он доберется до результата.
Почему это важно
Я считаю, что предположение о том, что ИИ полностью устраняет необходимость в специальных знаниях, содержит скрытое допущение: если система способна объяснить или выполнить некоторую операцию, то пользователь сможет успешно применить ее в произвольных обстоятельствах.
Эксперимент RAND показывает, что это далеко не всегда так.
При выполнении сложной технической задачи необходимо не только получить инструкцию или фрагмент кода, но и понять, соответствует ли результат текущей ситуации. Нужно распознавать ошибки, выбирать дальнейшие действия и интерпретировать последствия.
Если модель предлагает некорректное решение, неподготовленный пользователь может оказаться неспособным это обнаружить. Если среда отличается от предполагаемой, ему может не хватить знаний для адаптации предложенного подхода.
Впрочем, было бы неправильно сделать противоположный категоричный вывод: будто бы ИИ не снижает требования к квалификации.
Во-первых, эксперимент зафиксировал преимущества на отдельных этапах.
Во-вторых, исследовались конкретные модели, задачи и условия применения. Полученные результаты не распространяются автоматически на все существующие и будущие агентные системы.
В-третьих, статистически незначимый результат не доказывает отсутствия эффекта, он означает всего лишь, что в данных условиях исследователи не получили достаточно убедительных оснований утверждать наличие соответствующего преимущества.
Наконец, важное ограничение эксперимента связано с защитными механизмами моделей. Половина участников, имевших доступ к ИИ, сталкивалась с отказами отвечать на некоторые запросы. Среди столкнувшихся с отказами 40% потребовалось не менее трех последующих обращений.
Такие ограничения очевидно могли влиять на результативность работы.
А что насчет моделей без ограничений и автономных агентов?
Этот вопрос заслуживает отдельного внимания.
Отсутствие модерации часто рассматривается как главный фактор, который позволит злоумышленникам использовать ИИ практически без препятствий, однако здесь смешиваются как минимум три разных свойства системы.
Первое: готовность модели отвечать на запросы, связанные с потенциально опасными действиями.
Второе: способность модели правильно решать сложные технические задачи.
Третье: возможность самостоятельно выполнять последовательность действий с использованием внешних инструментов.
Эти свойства не эквивалентны друг другу.
Модель без защитных ограничений не обязательно обладает высокой технической компетентностью. И напротив, сравнительно небольшая модель, свободно отвечающая на любые вопросы, может уступать более мощной системе с ограничениями.
Автономность тоже не означает безошибочности. Агентная система может самостоятельно выбирать операции, запускать инструменты и анализировать результаты, но при этом ошибаться в планировании или неверно интерпретировать состояние среды.
Поэтому при оценке рисков необходимо рассматривать не абстрактный «ИИ без цензуры», а конкретную систему: ее модели, инструменты, уровень автономности, возможности обратной связи и требования к оператору.
Отдельный вопрос заключается в том, насколько автономные системы способны компенсировать отсутствие квалификации человека. Результаты RAND не позволяют окончательно на него ответить.
Снижение порога входа началось не с ИИ
Есть и исторический контекст, который важно не упускать.
Он заключается в том, что сложные кибератаки давно перестали быть исключительно результатом самостоятельной работы высококвалифицированных специалистов.
Появление готовых инструментов эксплуатации, ботнетов, коммерческих наборов вредоносного программного обеспечения и различных моделей Cybercrime-as-a-Service постепенно снижало требования к самостоятельным техническим навыкам отдельных участников.
Человек мог приобрести готовый инструмент или услугу, не понимая во всех подробностях, как она устроена, поэтому сама по себе доступность технически сложных операций для неподготовленных пользователей не является принципиально новым явлением.
Возможное отличие ИИ заключается в другом: автоматизации не только заранее реализованных операций, но и части интеллектуальной работы по анализу ситуации, планированию и выбору дальнейших действий.
Насколько далеко продвинется такая автоматизация и насколько надежной она окажется, нам еще предстоит увидеть.
Исследование RAND позволяет сформулировать осторожный промежуточный вывод: ИИ действительно способен снижать барьеры для отдельных задач, но пока нет достаточных оснований утверждать, что наличие модели автоматически превращает человека без подготовки в квалифицированного участника сложной кибератаки.
Однако проблема доступности технических возможностей существует не только на стороне атакующих.
Moltbook: создать приложение проще, чем оценить его безопасность
В начале 2026 года внимание технологического сообщества привлекла Moltbook, социальная платформа, предназначенная для взаимодействия ИИ-агентов.
Ее концепция предполагала, что программные агенты могут публиковать сообщения, комментировать записи, голосовать и взаимодействовать между собой, формируя своеобразную социальную сеть. Проект быстро приобрел популярность, в том числе благодаря необычной идее и демонстрации возможностей современной агентной разработки. Создатель платформы публично рассказывал, что не писал код самостоятельно, а реализовал свое представление об архитектуре проекта с помощью ИИ.
Именно эта деталь делает дальнейшую историю для меня особенно интересной.
2 февраля 2026 года компания Wiz опубликовала результаты исследования безопасности Moltbook.
Исследователи обнаружили серьезную проблему разграничения доступа, позволявшую получать и изменять данные производственной базы. По данным Wiz, открытыми оказались около 1,5 млн токенов аутентификации ИИ-агентов, 35 тысяч адресов электронной почты и приватные сообщения.
Проблему сообщили разработчикам платформы, после чего она была устранена.
В чем заключалась уязвимость
Moltbook использовала Supabase, платформу, предоставляющую разработчикам PostgreSQL, интерфейсы доступа к данным, механизмы аутентификации и другие серверные возможности. В клиентском JavaScript приложения исследователи обнаружили публичный ключ доступа к проекту Supabase.
Здесь необходимо сделать техническое уточнение.
Наличие публичного ключа Supabase в клиентском приложении само по себе не является уязвимостью.
Архитектура платформы предусматривает использование определенных типов ключей в публичных клиентах. Безопасность в таком случае обеспечивается не секретностью ключа, а корректными правилами доступа к данным. В частности, Supabase поддерживает механизм Row Level Security (RLS), позволяющий ограничивать доступ к отдельным строкам таблиц PostgreSQL на основании заданных политик.
Например, пользователь может получать доступ только к собственным данным, даже если запрос к базе выполняется через общий публичный интерфейс. Но для этого соответствующие политики должны быть корректно настроены.
В случае Moltbook необходимое разграничение отсутствовало. В результате публичный интерфейс позволял выполнять операции с данными, которые не должны были быть доступны посторонним. Исследователи смогли подтвердить возможность чтения чувствительной информации и изменения содержимого базы.
Следовательно, проблема заключалась не в самом факте использования Supabase и не в наличии публичного API-ключа, а в отсутствии должным образом настроенных ограничений доступа на серверной стороне.
Это классическая ошибка информационной безопасности, и именно поэтому этот случай представляет интерес.
Приложение работает. Но что именно проверено?
Для пользователя, создающего приложение с помощью ИИ, основным критерием успешности часто оказывается выполнение ожидаемых функций.
Работает регистрация? Да.
Можно авторизоваться? Да.
Сохраняются данные? Да.
Отображается личный кабинет? Да.
С точки зрения функционального тестирования все может выглядеть вполне удовлетворительно.
Но работоспособность авторизации не означает, что правильно реализована авторизация каждой операции с данными. Наличие личного кабинета не гарантирует, что один пользователь не может получить данные другого, а успешная запись в базу не доказывает, что доступ к ней ограничен необходимыми полномочиями.
Для проверки таких свойств нужны дополнительные требования и соответствующие проверки.
Причем далеко не все требования безопасности можно вывести из видимого поведения интерфейса.
Человек без достаточной инженерной подготовки может не знать, что необходимо проверять политики доступа к данным, доверенные и недоверенные компоненты системы, условия выполнения серверных операций или правила хранения чувствительной информации. Он получает результат, который соответствует его функциональным ожиданиям, но не обязательно способен оценить свойства, не выраженные явно в постановке задачи.
В этом смысле Moltbook показывает важное различие между возможностью создать программный продукт и способностью квалифицированно принять результат его разработки.
Но разве профессиональные разработчики не допускают таких ошибок?
Разумеется, допускают.
Ошибки разграничения доступа, неправильные конфигурации баз данных и недостаточная проверка полномочий существовали задолго до появления генеративного ИИ. Сам по себе инцидент Moltbook не доказывает, что ИИ-разработка менее безопасна, чем традиционная, он также не позволяет установить, какая доля подобных ошибок возникает именно из-за генерации кода.
Для таких выводов потребовалось бы сравнивать сопоставимые приложения, созданные различными способами, с одинаковыми критериями оценки безопасности. Необходимо было бы учитывать квалификацию участников, сложность приложений, используемые технологии, процессы проверки и условия эксплуатации.
Тем не менее этот случай демонстрирует реальный риск, связанный с изменением доступности разработки.
Раньше создание достаточно сложного публичного сервиса обычно предполагало наличие хотя бы некоторой совокупности инженерных компетенций у разработчика или команды. ИИ-инструменты же позволяют частично отделить возможность создания системы от обладания этими компетенциями. Это не означает, что каждый человек, использующий ИИ для разработки, является неквалифицированным. Профессиональные разработчики также активно используют подобные инструменты и способны оценивать их результаты.
Проблема возникает в ситуации, когда сложность создаваемой системы превышает способность ее владельца или разработчика проверить корректность и безопасность реализации. При этом ИИ не только помогает реализовывать функции. Он может помочь подготовить тесты, выявить нарушения и предложить исправления, но и результаты таких проверок требуют оценки.
Нельзя считать систему безопасной только потому, что та же модель, которая создала код, впоследствии сообщила об отсутствии проблем.
Возможное увеличение поверхности атаки
Здесь у меня возникает еще одна гипотеза.
Если создание приложений становится доступнее, то количество публичных сервисов потенциально может расти быстрее, чем количество людей, способных квалифицированно обеспечивать их безопасность. Даже если среднее качество отдельного приложения не ухудшается, появление новых сервисов, интерфейсов, баз данных и интеграций может увеличивать совокупную поверхность атаки.
Однако это пока именно гипотеза.
Чтобы подтвердить ее, необходимо показать не только увеличение количества приложений, созданных с помощью ИИ, но и установить, какие из них публично доступны, какими уязвимостями обладают и насколько часто эти уязвимости эксплуатируются.
Случай Moltbook очевидно не предоставляет таких статистических данных.
Зато он наглядно демонстрирует другой, более узкий факт: создание работоспособного программного продукта с помощью ИИ не гарантирует соблюдения требований информационной безопасности.
Теперь, если сравнить этот случай с исследованием RAND, обнаруживается интересная связь.
В эксперименте RAND наличие инструмента не обеспечивало неподготовленным участникам гарантированного успеха при выполнении сложной технической задачи. В случае Moltbook инструмент помог создать работоспособную систему, но наличие результата не обеспечило его защищенности.
Это разные ситуации, и их нельзя считать доказательством единой закономерности, но обе заставляют меня задуматься о различии между технической возможностью выполнить действие и компетентностью, необходимой для оценки результата.
Было бы, однако, ошибкой с моей стороны завершить на столь тревожной ноте, ведь развитие ИИ меняет возможности не только тех, кто атакует системы или создает их без достаточной проверки.
DARPA AIxCC: защитники тоже получили искусственный интеллект
В августе 2025 года завершился финальный этап AI Cyber Challenge (AIxCC), соревнования, организованного американским агентством DARPA при участии других организаций и технологических компаний.
Его задача заключалась в развитии автономных систем, способных обнаруживать и устранять уязвимости в программном обеспечении.
В отличие от обычных инструментов статического анализа, которые преимущественно выявляют определенные категории подозрительных конструкций, участники разрабатывали более сложные системы автоматизированного исследования кода.
Такие системы могли объединять различные методы анализа, средства проверки и ИИ-компоненты для поиска уязвимостей, подтверждения их существования и подготовки исправлений.
Участникам предстояло работать с большими кодовыми базами реального программного обеспечения, в которые для оценки результатов были внесены специально подготовленные уязвимости. Организаторы также учитывали возможность обнаружения настоящих дефектов, существовавших независимо от соревнования.
Официальные результаты опубликованы в сообщении DARPA от 8 августа 2025 года.
Результаты соревнования
В финальном этапе автономные системы исследовали программное обеспечение общим объемом более 54 млн строк кода.
В рамках 63 испытаний, содержащих синтетические уязвимости, системы обнаружили 54 уникальные уязвимости и подготовили исправления для 43 из них. Кроме того, участники обнаружили 18 настоящих уязвимостей в исследуемых проектах и представили 11 исправлений для таких находок.
Организаторы также сообщили, что среднее время подготовки исправления участниками составляло около 45 минут, а средняя стоимость выполнения конкурсной задачи оценивалась примерно в 152 доллара.
Последние показатели необходимо трактовать осторожно, потому что они относятся к условиям соревнования и не представляют собой полной стоимости создания, внедрения и эксплуатации соответствующих систем. В частности, разработка самих автономных комплексов выполнялась квалифицированными исследовательскими командами.
Тем не менее результаты, на мой взгляд, показательны.
Речь идет уже не только о способности ИИ указать на подозрительный фрагмент кода, но и об автоматизированной подготовке изменений, направленных на устранение обнаруженной проблемы.
Почему обнаружить уязвимость недостаточно
Давайте вернемся к случаю PHP2Shell.
Обнаружение критической уязвимости само по себе не делает программную систему безопаснее. Для этого необходимо устранить проблему, проверить исправление и доставить его до пользователей.
Причем исправление должно не только закрывать уязвимость, но и сохранять ожидаемые свойства системы.
Изменение механизма управления памятью, например, потенциально может затронуть множество компонентов интерпретатора и сторонних расширений, поэтому разработчикам приходится учитывать последствия, которые не ограничиваются устранением конкретного дефекта.
С этой точки зрения особенно интересно, что в AIxCC оценивалась не только способность находить уязвимости, но и качество подготовленных исправлений. Автономная система должна была работать с результатом исследования и предлагать практический способ устранения проблемы.
Это существенный шаг по сравнению с автоматизацией одного этапа анализа.
Если подобные технологии получат широкое применение, они потенциально смогут сокращать трудоемкость некоторых операций, которые сегодня выполняют специалисты по безопасности и разработчики.
Но здесь снова необходимо отделять продемонстрированную возможность от ее распространенности.
Почему нельзя просто перенести результаты AIxCC в обычную компанию
Здесь я должен особо отметить, что это соревнование проводилось в специально подготовленных условиях.
Участники имели доступ к определенным кодовым базам, инфраструктуре проверки и заранее установленным правилам оценки. Над созданием автономных систем работали профессиональные команды.
В реальной организации условия могут существенно отличаться.
Программная система может состоять из множества взаимодействующих компонентов, часть которых разработана сторонними поставщиками. Не все исходные коды доступны. Не для всех функций существуют полноценные автоматизированные тесты, и изменение одного компонента может влиять на работу других систем.
Кроме того, обнаружить и технически исправить уязвимость не всегда достаточно.
Исправление необходимо согласовать, протестировать, включить в выпуск, развернуть в соответствующей инфраструктуре и убедиться, что оно не нарушило работу критически важных функций. Автоматизация способна помочь на многих из этих этапов, но результаты AIxCC не доказывают, что весь процесс управления уязвимостями может быть полностью передан автономным системам. Тем более они не означают, что организация без квалифицированных специалистов сможет получить аналогичные результаты, просто подключив ИИ-модель.
Однако отрицать значение продемонстрированных возможностей тоже было бы неправильно.
AIxCC показал, что автоматизированные системы способны выполнять содержательную часть работы по обнаружению и исправлению уязвимостей в сложных программных проектах.
Кому ИИ дает преимущество?
Этот вопрос часто возникает при обсуждении искусственного интеллекта и кибербезопасности.
Если ИИ помогает находить уязвимости, значит ли это, что атакующие получают преимущество?
Не обязательно.
Обнаруженная добросовестным исследователем уязвимость может быть исправлена до того, как ей воспользуется злоумышленник. Автоматизация анализа способна помочь разработчикам выявлять дефекты раньше, в том числе до выпуска программного обеспечения.
Но и обратное утверждение, что защитники неизбежно получат преимущество благодаря ИИ, тоже не подтверждается рассмотренными данными. Для сравнения тут нам необходимы сопоставимые показатели: скорость обнаружения уязвимостей, время разработки и распространения исправлений, успешность эксплуатации, стоимость операций и множество других факторов.
Результаты одного соревнования не позволяют определить итог такого противостояния, и тем не менее они демонстрируют, что развитие ИИ не является исключительно фактором усиления наступательных возможностей. Технологии, которые могут использоваться для исследования уязвимостей, способны становиться частью инструментов их обнаружения и устранения.
И это обстоятельство существенно усложняет любые однозначные прогнозы.
Что в итоге меняется?
Давайте вернемся к моему исходному предположению: искусственный интеллект упростит проведение кибератак настолько, что количество взломов начнет неизбежно увеличиваться, а специальные знания злоумышленникам больше не понадобятся.
После рассмотрения этих четырех исследований и случаев я бы разделил это утверждение на несколько самостоятельных вопросов.
Первый: способен ли ИИ выполнять сложную работу в области информационной безопасности?
Да, соответствующие возможности уже продемонстрированы.
PHP2Shell показывает практическое применение ИИ в исследованиях сложных уязвимостей. AIxCC демонстрирует возможности автономных систем по обнаружению и исправлению программных дефектов.
Однако оба случая связаны с профессиональными исследовательскими командами, и они не доказывают, что аналогичные результаты доступны любому пользователю без подготовки.
Второй: снижает ли ИИ требования к специальным знаниям?
В определенных задачах да.
Эксперимент RAND выявил признаки положительного эффекта, особенно на начальных этапах выполнения заданий новичками, но при оценке способности завершать сложные цепочки атак общие результаты оказались гораздо менее убедительными.
Следовательно, нет достаточных оснований считать, что ИИ уже полностью заменяет квалификацию человека в подобных задачах.
Третий: возникают ли новые проблемы безопасности из-за доступности разработки с ИИ?
Здесь, как мне думается, необходимо различать появление новых типов уязвимостей и изменение условий, при которых создается программное обеспечение.
Случай Moltbook иллюстрирует хорошо известную проблему разграничения доступа, однако ничего принципиально нового в ее технической природе нет. Новым мне представляется другое: сложный публичный сервис может быть создан с помощью ИИ даже тогда, когда создатель не обладает достаточными знаниями для самостоятельной реализации и проверки отдельных компонентов.
Это потенциально изменяет соотношение между доступностью разработки и компетенциями, необходимыми для контроля результата.
Однако из одного инцидента также нельзя заключить, что все приложения, созданные с помощью ИИ, менее безопасны.
Четвертый: обязательно ли все это приведет к росту числа успешных кибератак?
На основании рассмотренных мной источников я не могу сделать такой вывод.
Мы располагаем свидетельствами развития технических возможностей, отдельными экспериментами и конкретными инцидентами. Но между ростом возможностей ИИ и увеличением количества успешных атак находится множество дополнительных факторов: доступность инструментов, квалификация операторов, состояние защищаемых систем, развитие методов обнаружения угроз, скорость устранения уязвимостей и организационные особенности обеспечения безопасности.
Чтобы утверждать наличие устойчивой причинно-следственной связи, необходимы сопоставимые данные о реальной преступной активности и ее изменении во времени.
Доступность возможностей не равнозначна компетентности
На мой взгляд, главное наблюдение выходит несколько за рамки непосредственно кибербезопасности.
Современные ИИ-инструменты позволяют выполнять действия, которые раньше были тесно связаны с наличием специальных знаний, при этом получение технического результата и способность оценить его корректность остаются разными задачами.
Человек может получить работающий программный код, не понимая всех его свойств. Может выполнить предложенную моделью последовательность действий, не умея самостоятельно оценить ее последствия. Может обнаружить потенциальную уязвимость, но не знать, действительно ли она эксплуатируема и как безопасно ее устранить.
Однако это не означает, что ИИ обязательно создает технологическую среду, в которой компетенции перестают иметь значение, скорее, изменяется характер их применения.
Часть операций, ранее требовавших непосредственного выполнения специалистом, становится доступной через автоматизированные системы. Но одновременно возрастает значение постановки задач, оценки результатов, понимания ограничений и принятия решений.
Причем одинаково важно не преувеличивать и не преуменьшать этот эффект.
Нельзя утверждать, что без специальных знаний невозможно получить практически значимый результат при использовании ИИ. Но нельзя и считать, что технические возможности модели автоматически становятся компетенциями ее пользователя.
Результат зависит от конкретной задачи, качества системы, степени автономности и условий ее применения.
Вместо прогноза
В этой публикации я намеренно не пытался определить, кто в конечном счете получит больше преимуществ от развития ИИ: атакующие или защитники. Для подобного вывода рассмотренных данных недостаточно.
Зато они позволяют говорить о более конкретном изменении.
Искусственный интеллект уже участвует в выполнении задач, которые раньше требовали значительной экспертной работы. Это касается исследования уязвимостей, создания программного обеспечения и подготовки исправлений.
Но технический результат сам по себе не гарантирует ни его корректности, ни безопасности, ни способности человека оценить последствия.
Поэтому, на мой взгляд, один из наиболее интересных вопросов ближайших лет заключается не только в том, насколько мощнее станут ИИ-модели.
Не менее важно, как будет изменяться разрыв между возможностью выполнять сложные технические действия и способностью понимать, проверять и контролировать их результаты.
Именно от того, как разные участники научатся работать с этим разрывом, могут зависеть многие последствия дальнейшего распространения ИИ.
Основные источники, которые я использовал для этой публикации
-
PHP Foundation. Today’s PHP Security Release, and How We’re Strengthening PHP Security. 21 октября 2026 года.
-
Wiz Research. PHP2Shell: PHP Remote Code Execution Vulnerabilities. 2026.
-
Calif. PHP2Shell. 2026.
-
RAND Corporation. Investigating the potential use of frontier AI models for offensive cyberattacks: A human uplift study. 28 мая 2026 года. DOI: 10.7249/RRA3892-1.
-
Wiz Research. Hacking Moltbook: The AI Social Network Any Human Can Control. 2 февраля 2026 года.
-
Supabase Documentation. Understanding API Keys. Техническая документация.
-
DARPA. AI Cyber Challenge Marks Pivotal Inflection Point for Cyber Defense. 8 августа 2025 года.
Автор: GBAK
