Недавний скандал вокруг двух критических уязвимостей в PHP казалась острым, но одноразовым инцидентом: организации вынужденно отключали сайты, чтобы срочно установить патчи. Но это не конец проблемы, а начало. Специалисты, которые эти баги обнаружили, вместе с командой Wiz (дочерняя компания Google по управлению уязвимостями), OpenAI и другими исследователями пришли к выводу: скорость, с которой ИИ способен находить и использовать новые уязвимости, меняет саму природу угрозы.
PHP работает примерно на 70% всех веб-сайтов в интернете — это не просто популярный язык, это фундамент огромной части цифровой инфраструктуры. Большая часть этого кода сложилась десятилетия назад, и переписать его или даже регулярно актуализировать его безопасность для миллионов разработчиков попросту нереально в темпе, необходимом для защиты от новых угроз. Раньше цикл выглядел так: уязвимость находили, её пытались закрыть, пока она была известна узкому кругу. Теперь этот цикл ускоряется ИИ-инструментами, которые способны автоматизировать анализ, поиск и даже написание exploit-кода.
Главная боль в том, что ручное патчирование уже не масштабируется. Когда один баг может быть задокументирован и преобразован в рабочий exploit за часы или дни (вместо месяцев), организации, управляющие миллионами строк наследованного кода, просто физически не успеют среагировать. Особенно это касается небольших компаний и организаций, которые не держат на штате круглосуточных команд безопасности.
Происходящее — это не просто очередной инцидент, а индикатор смены парадигмы. ИИ делает профессию attacker с точки зрения технической готовности более демократичной, а с точки зрения скорости исполнения — более опасной. Если раньше для масштабной атаки требовались навыки и время, то теперь достаточно знаний о том, как использовать автоматические инструменты анализа уязвимостей и генерации payload-ов. Интернет, построенный на коде, который редко обновляется и часто забывается, оказался идеальной мишенью для такого сценария.
Это создаёт давление не только на разработчиков, но и на весь цикл разработки: нужна либо существенная переоценка скорости обновлений и поддержки, либо фундаментальная смена архитектур на более безопасные по умолчанию. Некоторые крупные проекты уже двигаются в сторону автоматизации скан-и-patch процессов через CI/CD pipelines и контейнеризацию, но для огромной части веб-кода этого не происходит.
В России эта проблема особенно острая для компаний, которые работают с наследованным корпоративным кодом или использют open-source в production без регулярного аудита. Банки и крупные e-commerce платформы более-менее готовы к таким угрозам, потому что в них есть security-команды. А вот средний бизнес — SaaS-сервисы, маркетинг-платформы, системы управления контентом — часто работают на базе неуверенной версии PHP или других популярных языков, где обновление требует ресурсов. Здесь нужны либо инструменты автоматизированного мониторинга уязвимостей (которые анализируют код без остановки production), либо переход на поддерживаемые, регулярно обновляемые платформы. Компании, которые строят новые системы, должны закладывать в архитектуру контроль версий зависимостей и автоматизированный scanning с первого дня разработки, а не добавлять его потом как patch.
Алексей Мартыненко
Главный редактор SPV News
PHP-инцидент важен не сам по себе, а потому, что показывает реальное ограничение человеческой скорости. ИИ не создал проблему уязвимостей в наследованном коде — эта проблема была всегда, просто её закрывали медленнее. Теперь открытие и эксплуатация уязвимостей стали быстрее, чем человеческая способность их патчить в масштабе. Это означает, что компании должны либо вложиться в автоматизацию контроля и обновлений, либо приготовиться к постоянному состоянию игры в догонялки. Третьего обычно не дано.