Всего за несколько дней мы столкнулись с PHP2Shell, набором критических уязвимостей удаленного выполнения кода в самом ядре PHP. Причем не в приложении, созданном на PHP, а в движке, который обеспечивает работу примерно 70% веб-сайтов в интернете. Пострадала каждая версия PHP, выпущенная за последнее десятилетие. Мы увидели GitLab RCE with a CVSS score of 10.0, позволившую неаутентифицированному злоумышленнику запустить произвольный код на сервере GitLab — платформе разработки, на которую полагаются более 30 миллионов пользователей и больше половины компаний из списка Fortune 100. И мы увидели катастрофу с центром сертификации eMudhra, когда восемь закрытых ключей промежуточных центров сертификации оказались настолько слабыми, что их смогли восстановить обратной разработкой, потенциально позволив любому подделывать доверенные TLS-сертификаты для любого домена.
Три разных типа сбоев на трех разных уровнях стека. И все это за одну неделю. Самое интересное, что безопасность кажется разрушенной только на этой неделе. На самом деле это лишь обнажило то, что было сломано уже давно.
Традиционный процесс уже был нарушен
В эпоху программного обеспечения, создаваемого преимущественно с помощью ИИ, традиционный процесс управления уязвимостями будет с трудом успевать за угрозами, если он по-прежнему сводится к тому, что кто-то читает бюллетень, присваивает уровень критичности, заводит тикет и ждет следующего окна обслуживания для применения патча. Этот процесс испытывал трудности еще до «вулнпокалипсиса».
И данные это подтверждают. 2026 Verizon DBIR сообщила, что лишь 26% критических уязвимостей (определяемых как те, что входят в каталог известных эксплуатируемых уязвимостей CISA) были полностью устранены организациями в 2025 году. Это резкое падение по сравнению с 38% в предыдущем году. Можно предположить, что ИИ также способствует увеличению этого разрыва.
Вдобавок ко всему, впервые в истории отчетов эксплуатация уязвимостей программного обеспечения обогнала злоумышленное использование учетных данных в качестве вектора первоначального доступа при взломах. Теперь на нее приходится 31% подтвержденных инцидентов по сравнению с 20% годом ранее.
Что можно сделать со всем этим риском? Традиционным ответом всегда была установка патчей, причем обычно с помощью очень ручного процесса. Очевидно, что эта стратегия не имеет шансов в эпоху разработки с поддержкой ИИ.
У вас всегда будет период уязвимости
Нельзя рассчитывать на то, что удастся постоянно поддерживать идеальное обновление каждой системы. Период уязвимости будет существовать всегда. Поэтому одна из важнейших задач для организаций — создавать системы, устойчивые к компрометации отдельных компонентов. Если вы разделите авторизацию, сетевой доступ, сервисы и данные по отсекам, то уязвимость удаленного выполнения кода в одном сервисе не приведет автоматически к тому, что злоумышленник получит доступ ко всему остальному. Это не значит, что можно игнорировать критические патчи, но это дает вам некоторую свободу действий и значительно снижает последствия использования системы без патчей. Я называю это устойчивостью по дизайну.
Знайте, что у вас есть и где вы уязвимы
Другая важнейшая возможность заключается в том, чтобы гораздо лучше понимать свои активы и места, где вы уязвимы. Инвентаризация активов и обнаружение поверхности атаки значительно улучшились. Организации должны иметь возможность быстро определять, используют ли они уязвимое программное обеспечение, где оно находится, доступно ли оно для злоумышленников и к чему злоумышленник сможет получить доступ в случае его эксплуатации. Соедините это с информацией о том, какие уязвимости действительно эксплуатируются, и вы сможете принимать гораздо более разумные решения, чем просто патчить всё подряд с критическим баллом CVSS в порядке поступления.
Операционная надежность — это безопасность
Существует связь между безопасностью и операционной надежностью. Одна из причин, почему организации медленно устанавливают патчи, заключается в боязни нарушить работу производственных систем. Если вы инвестировали в автоматизированное тестирование, поэтапные развертывания, быстрый откат и надежное восстановление систем и данных, вы можете развертывать исправления безопасности гораздо более агрессивно. Вам не нужны недели тестирования для каждого изменения, если вы уверены, что сможете быстро обнаружить проблему и восстановиться. Повышение эффективности безопасного развертывания программного обеспечения — одно из лучших средств для улучшения безопасности.
Проблема доверия
Ициденты с GitLab и eMudhra также напоминают нам, что некоторые компоненты несут в себе огромный уровень доверия. Скомпрометированная платформа разработки может потенциально повлиять на все, что вы создаете и развертываете. Скомпрометированный центр сертификации может подорвать доверие к системам, которые в остальном полностью защищены патчами. Нам нужно тщательно подумать о том, где мы сосредоточили привилегии и доверие, и что происходит, когда эти предположения не оправдываются.
Именно поэтому дискуссия вокруг доверия к ПО (происхождение, непрерывная верификация, автономное исправление, управление и аттестация) важна как никогда раньше. Если вам интересно глубже разобраться в том, как выглядит реальная структура доверия на практике, мы написали об этом здесь.
Путь вперед
Мы не решим проблему «вулнпокалипсиса», просто наняв достаточное количество людей для триажа каждой новой уязвимости. Мы должны проектировать системы, которые проще понять, сложнее скомпрометировать целиком и быстрее исправить. Скорость обнаружения уязвимостей и изменения программного обеспечения не замедлится. Наша архитектура безопасности и операционные практики должны за этим успевать.
Это значит:
- Проектируйте с учетом устойчивости. Разделяйте компоненты по отсекам, чтобы единичный инцидент не приводил к лавинообразному эффекту. Сделайте радиус поражения проектным ограничением, а не второстепенной мыслью.
- Знайте свою уязвимость. Инвестируйте в инвентаризацию активов и обнаружение поверхности атаки. Расставляйте приоритеты на основе реальных рисков, а не только баллов CVSS.
- Уверенность в развертывании. Автоматизированное тестирование, поэтапный ввод в действие, быстрый откат. Чем быстрее вы можете безопасно развертывать, тем быстрее вы можете обеспечивать защиту.
- Изучите концентрацию доверия. Выявите компоненты, компрометация которых станет катастрофической. По возможности сокращайте единые точки доверия; неустанно следите за ними там, где это невозможно.
В 1998 году мы говорили Сенату, что планка слишком низка. В 2026 году планка не поднялась достаточно быстро, но давление на нее возросло. Неделя, когда рухнула безопасность, не была случайностью. Это был превью. Вопрос не в том, повторится ли такая неделя. Вопрос в том, будет ли ваша архитектура к этому готова.
