ИИ ускоряет поиск уязвимостей, но решающим остаётся внедрение исправлений

VulnCheck сообщает о росте числа CVE на 100% за год, связывая его предположительно с ИИ и расширением возможностей органов нумерации; период сравнения в тексте неясен.¹ Цифра заслуживает внимания, но не доказывает удвоение всех программных дефектов или исключительную роль ИИ в этом росте.

Иллюстрация, созданная ИИ: сервер, отключённый сетевой кабель и инструменты символизируют расследование киберинцидентов и устранение проблем; это не реальный инцидент в компании.

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

PHP показывает разницу между тяжестью последствий и вероятностью атаки

Версии PHP от 21 октября исправляют две критические уязвимости удалённого выполнения кода: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Уведомление от 23 октября касается необычной конфигурации загрузки файлов в сессии.² Проблемы с разными предпосылками нельзя объединять в один неразличимый риск. Позднее уведомление также не означает бесполезности предыдущих обновлений безопасности.

23 октября NCSC-NL назвал эксплуатацию сложной, а массовую эксплуатацию менее вероятной, сохранив рекомендацию установить исправления. Отключение его сайта было превентивным.³ Следовательно, остановка сервиса не доказывает успешного вторжения, а снижение оценки риска не оправдывает откладывание исправлений.

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

PHP Foundation связывает ранние признаки проблемы нехватки памяти с работой по итогам аудита 2024 года; не все этапы обнаружения следует приписывать ИИ.⁴

Больше сообщений не означает немедленного роста безопасности

Для пользователя ПО запрос на обновление должен соответствовать конкретным активам, ответственным за бизнес-процессы и исполнимому плану развёртывания. Без этих сведений раннее получение уведомления не обязательно сокращает период риска. NIST подчёркивает координацию технических команд и бизнес-подразделений в стратегии исправлений, рассматривая обслуживание как часть обычной работы.⁵ Разрыв между обнаружением и реагированием следует оценивать через эти условия, а не выводить размер очереди проекта только из количества сообщений.

NIST выделяет плановую установку исправлений, экстренную установку, срочное снижение риска и активы, которые невозможно исправить.⁵ Поэтому организации не должны после каждого срочного уведомления заново спорить, кто вправе разрешить остановку. Ответственных за бизнес-процессы, окна обслуживания и порядок эскалации нужно определить заранее, выбирая план по фактическим последствиям. Цель состоит в сокращении времени согласований, а не в предположении, что любое обновление можно немедленно внедрять без испытаний.

Аналогично, подозрительный результат от инструмента ИИ не должен автоматически давать ему право проверять его на производственных системах. Контролируемые испытания, минимально необходимый доступ и человеческая проверка сохраняют значение. Цель защиты состоит в надёжном устранении риска, а не в подмене подтверждённых результатов возрастающим объёмом автоматизированной активности.

Цепочка исправления должна доходить до производственной среды

NIST SP 800-40 Rev. 4 рассматривает управление исправлениями как профилактическое обслуживание: выявление, расстановка приоритетов, получение, установка и проверка. Документ также подчёркивает необходимость постоянно обновляемого учёта ПО и активов.⁵ Это объясняет, почему публикация уведомления не равнозначна завершению исправлений в организации.

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

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

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

При аутсорсинге эксплуатации и использовании хостинга ответственность не может заканчиваться фразой «поставщик занимается вопросом». Заказчику необходимо знать, кто устанавливает затронутый периметр, выполняет изменения и подтверждает завершение, а также кому передаётся вопрос при нарушении сроков. Эти уточнения полезнее для устранения риска, чем простая пересылка списка идентификаторов уязвимостей.

Исправление дефекта не завершает расследование инцидента

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

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

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

Источники

1. Patrick Garrity / VulnCheck, опубликовано 2026-10-22. Exploring the Risks and Impacts of AI on Vulnerability Discovery and Exploitation («Риски и влияние ИИ на обнаружение и эксплуатацию уязвимостей»). ↩

2. PHP, публикации от 2026-10-21 и 2026-10-23. Security advisory: Critical remote code execution vulnerabilities, update now; Informational advisory: Session upload progress («Уведомление безопасности: критические уязвимости удалённого выполнения кода, обновитесь сейчас; Информационное уведомление: ход загрузки файлов в сессии»), новостной архив 2026 года. ↩

3. NCSC-NL, опубликовано 2026-10-21; обновлено 2026-10-23 в 15:45, часовой пояс не указан. Update: PHP vulnerabilities remain a reason for immediate patching («Обновление: уязвимости PHP по-прежнему требуют немедленной установки исправлений»). ↩

4. The PHP Foundation, опубликовано 2026-10-21. Today's PHP Security Release, and How We're Strengthening PHP Security («Сегодняшний выпуск безопасности PHP и усиление защиты PHP»). ↩

5. Murugiah Souppaya / Karen Scarfone / NIST, опубликовано 2022-04-06. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology («Руководство по планированию управления исправлениями в организации: профилактическое обслуживание технологий»), SP 800-40 Rev. 4. Republished courtesy of the National Institute of Standards and Technology. Условия использования. ↩ ↩² ↩³ ↩⁴