Мы официально избавились от PHP. Вот чему нас научил октябрь (пока что)

Неделя с 19 по 24 октября 2026 года, с понедельника по субботу, принесла целую череду серьёзных новостей о безопасности по всей отрасли. Если вы её пропустили, наш обзор той недели описывает подробности. Коротко: в нескольких случаях злоумышленники действовали раньше, чем появлялись исправления.

Такая неделя не отправляет нас обратно к чертёжной доске, но делает чётче линии, которые на ней уже проведены. Одно дело придерживаться принципа, и совсем другое: наблюдать, случай за случаем, что происходит там, где этого принципа нет. Поэтому вместо перечисления технических шагов мы хотим объяснить принципы, по которым работаем, ведь для вас как клиента подход важнее любого отдельного обновления. Один из этих принципов только что достиг своей вехи: теперь мы официально избавились от PHP.

Почему установка исправлений задним числом становится проигрышной гонкой?

Годами стандартный совет был прост: обновляйтесь быстро, и всё будет в порядке. Тенденция уже тогда работала против этого совета. Команда Mandiant из Google измерила среднее время между тем, как уязвимость становится известной, и её эксплуатацией: 63 дня в 2018 и 2019 годах, 32 дня за 2021 и 2022 годы и пять дней в 2023 году, в среднем и без учёта выбросов.

Пять дней: это цифра за 2023 год, ещё до того, как инструменты ИИ стали частью повседневной работы над программным обеспечением. Этот месяц дал нам свежий замер гонки, сделанный с трёх разных точек обзора вокруг раскрытия PHP2Shell 21 октября 2026 года.

Команда Amazon по анализу угроз зафиксировала попытку эксплуатации PHP2Shell 17 октября, за четыре дня до публичного раскрытия, и сообщает, что как только эмбарго было снято и патч выпущен, новые демонстрационные эксплойты появились в течение нескольких часов. F5 Labs увидела первое сканирование на PHP2Shell более чем за пять часов до публикации двух CVE, а уже через несколько часов после раскрытия её сенсоры фиксировали тысячи попыток эксплуатации. Генеральный директор Cloudflare Matthew Prince заявил 22 октября, что Cloudflare видела тысячи попыток до анонса, десятки тысяч за 45 минут после него, сотни тысяч в течение двух часов и миллионы к моменту публикации его поста. Это были попытки, а не подтверждённые взломы, но они показывают, как быстро начали дёргать двери: окно теперь измеряется минутами и часами, а для некоторых оно закрылось ещё до того, как патч вообще существовал.

Эксплуатация до появления какого-либо исправления тоже не редкость. В 2023 году 70% эксплуатируемых уязвимостей, которые отслеживала Mandiant, 97 из 138, были использованы как уязвимости нулевого дня, то есть до того, как существовало хоть какое-то исправление.

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

Почему мы удаляем программы, вместо того чтобы обкладывать их заплатками?

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

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

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

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

Как на самом деле выглядит малая поверхность атаки?

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

Задумайтесь, что такое сторонняя библиотека или плагин на самом деле. Когда разработчик подключает её, он доверяет незнакомцу, зачастую неоплачиваемому волонтёру, поддерживать безопасность этого кода всё время, пока тот работает. Библиотеке нужны собственные обновления, собственные исправления безопасности, собственный внимательный сопровождающий. Если этот сопровождающий теряет интерес, меняет работу или просто перестаёт отвечать, код продолжает работать, но за ним больше никто не следит. Уязвимость, найденная после этого момента, остаётся открытой навсегда, и это та самая проблема заброшенности из предыдущего раздела, пришедшая через боковую дверь. Умножьте это на множество компонентов, от которых зависит типичное приложение, и картина станет ясной. Каждая зависимость является маленьким обещанием человека, которого вы никогда не встречали, и некоторые из этих обещаний тихо истекают. Чем меньше их у вас работает, тем меньшему числу незнакомцев вы обязаны своей безопасностью.

Системы, в которые вы входите, через которые платите и с которыми общаются наши приложения, написаны на Go. PHP убран, а вместе с ним и длинный хвост библиотек, плагинов и зависимостей, который приложения на PHP обычно тянут за собой.

Мы выбрали Go для самых критичных систем, потому что он решает проблему зависимостей на уровне языка. Go безопасен по памяти: язык управляет памятью за программиста, что исключает целый класс ошибок, таких как переполнение буфера, и CISA (американское агентство по кибербезопасности и защите инфраструктуры) включает Go в список языков с безопасной работой с памятью в документе The Case for Memory Safe Roadmaps. Этот класс больше, чем кажется: по данным проекта Chromium, около 70% его серьёзных ошибок безопасности связаны с проблемами безопасности памяти. Стандартная библиотека Go покрывает большую часть того, что нужно веб-сервису, включая криптографию, поэтому сервису на Go требуется меньше сторонних пакетов, а значит, меньше тех самых обещаний от незнакомцев. К криптографии там относятся настолько серьёзно, что собственный криптографический модуль Go прошёл валидацию по стандарту правительства США FIPS 140-3, сертификат CMVP #5247. А когда уязвимость всё же обнаруживается в более широкой экосистеме, команда безопасности Go ведёт базу уязвимостей, и её инструмент govulncheck сообщает только об уязвимостях в коде, который программа действительно вызывает, что делает оповещения малошумными и практически полезными.

Это важно из-за того, насколько распространены и насколько стары развёртывания PHP. По данным W3Techs, PHP используется на 69,2% всех сайтов, чей серверный язык известен сервису, при этом 26,6% сайтов на PHP всё ещё работают на PHP 7, а 7,7% на PHP 5, по замеру от 27 октября 2026 года. Сам проект PHP поддерживает каждую ветку выпуска два года исправлениями ошибок и безопасности, а затем ещё два года только критическими исправлениями безопасности. PHP 7 и PHP 5 давно вышли за эти рамки. Значительная часть веба работает на коде, который его собственные создатели больше не защищают, а это добровольное вступление в проигрышную гонку из первого раздела.

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

Какие данные о вас мы храним?

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

Мы запрашиваем только то, что нужно для работы аккаунта. Наша политика конфиденциальности перечисляет это прямо: имя пользователя, адрес электронной почты, зашифрованный пароль и IP-адрес, использованный при регистрации. Платежи проходят через сторонние платёжные сервисы, поэтому данные вашей карты живут у специалистов, весь бизнес которых состоит в их защите, а не у нас.

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

Та же логика работает и за нашими пределами, потому что другие компании тоже проигрывают гонки. Многие утечки, от которых страдают люди, происходят в магазинах, на форумах и в сервисах, где они зарегистрировались давным-давно. Поэтому мы предлагаем оповещения об утечках данных: наш Data Breach Scanner проверяет известные утечки данных на наличие вашего адреса электронной почты и пишет вам, если он там обнаружится, чтобы вы могли сменить пароли до того, как утечкой воспользуются.

Что произойдёт, если что-то всё же сломается?

У третьего вопроса две половины: восстановление и закрытие бреши. Сначала восстановление. Хорошее планирование безопасности исходит из того, что плохие дни случаются. Оборудование отказывает, поставщики меняются, и иногда правильный ход состоит в том, чтобы просто уйти от части инфраструктуры.

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

Устойчивость не выглядит эффектно. Чаще всего она проявляется в том, что всё просто продолжает работать, и в этой логике именно она не даёт проигранному раунду превратиться в проигранный сезон.

Как быстро исправления попадают в наши системы?

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

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

А поскольку наш стек мал, исправлять попросту меньше, и здесь три вопроса сходятся: чем меньше того, что может пострадать, тем быстрее закрывается брешь.

Если поставить вопросы и отвечающие на них принципы рядом, получится вот что:

Что всё это значит для вас?

Это значит, что у трёх вопросов есть ответы, которые вы можете почувствовать. Между вами и вашим аккаунтом стоит меньше кода, поэтому меньше мест, где что-то может пойти не так. Ваших данных существует меньше, поэтому даже худший случай раскрывает немногое. А наши системы можно перестроить, поэтому плохой день для нас не обязан превращаться в долгий простой для вас.

Мы будем честны насчёт пределов всего этого. Гонку, с которой мы начали, нельзя надёжно выигрывать, ни нам, ни кому-либо ещё, потому что уязвимости иногда эксплуатируются раньше, чем кто-либо узнаёт об их существовании, и никакая архитектура этого не меняет. Ни один провайдер не может обещать нулевой риск, а тот, кто обещает, продаёт уверенность, а не безопасность. Что мы можем обещать, так это форму потери: мало путей внутрь, мало что можно забрать и быстрый путь назад. Мы не можем гарантировать победу в каждом раунде гонки. Мы построили всё так, чтобы проигрыш одного раунда стоил вам как можно меньше, и мы считаем, что такое обещание, выполняемое последовательно, стоит больше, чем смелое обещание, которое выполнить нельзя.

Безопасность также является общим делом. Самая сильная система, которую мы можем построить, всё равно выигрывает от хороших привычек с вашей стороны, поэтому если вам нужны практические шаги, начните с нашего руководства о том, как повысить свою безопасность в интернете. А если вы выбираете VPN, у нас или у кого-то ещё, спросите провайдера, как он думает, а не только что он продаёт. Ответ многое скажет о том, как пройдут ваши тихие недели, да и громкие тоже.