В VS Code 1.123 автоматические обновления расширений больше не прилетают мгновенно: новая версия ждет два часа после публикации и только потом раскатывается пользователям. Для экосистемы, где один скомпрометированный апдейт может доехать до миллионов машин, это не косметика, а попытка дать защитникам хоть какое-то окно на отзыв релиза. Для русскоязычных команд, которые живут в Visual Studio Code и ставят десятки плагинов на рабочие ноутбуки разработчиков, это еще один сигнал: supply chain-риски добрались уже не только до npm и pip, но и до IDE.
О нововведении сообщает InfoQ: начиная с версии 1.123, вышедшей 3 июня, новые обновления расширений VS Code при включенном автообновлении ставятся не сразу, а спустя два часа после публикации. Логика простая: если аккаунт мейнтейнера захватили и через него выпустили вредоносную версию, появляется короткое окно, чтобы заметить проблему и снять релиз до массовой раздачи. При этом ручное обновление никто не убирал: если пользователь хочет, он по-прежнему может нажать Update и получить свежую версию сразу.
Есть, впрочем, важная оговорка. Задержка не действует для так называемых trusted publishers, то есть доверенных издателей. В эту категорию входят Microsoft, GitHub и OpenAI, и их расширения продолжают обновляться без паузы. Здесь начинается самое интересное. Формально исключение понятно: крупным вендорам хотят сохранить максимально гладкий UX. Практически это выглядит спорно, потому что именно крупные издатели с огромной базой установок выглядят как самые ценные цели для захвата аккаунта или компрометации пайплайна. Если атакующий доберется до маленького плагина, ущерб локальный. Если до популярного расширения с миллионами установок, последствия уже совсем другого масштаба.
Два часа против недель
Сам по себе подход не новый. За последний год механика cooldown, то есть обязательной выдержки перед установкой свежего пакета, стала почти стандартным ответом на атаки через цепочку поставок. В материале InfoQ перечислены сразу несколько примеров. Pip 26.1 получил настраиваемые dependency cooldowns, с помощью которых команда может блокировать пакеты моложе семи дней. При этом исследование, на которое ссылается статья, показало: семидневная задержка остановила бы 8 из 10 проанализированных supply chain-атак. RubyGems добавил опциональные cooldown-механизмы в Bundler. Порог минимального возраста релиза за прошлый год появился и в npm, pnpm, Yarn, и Bun.
На этом фоне обновления расширений VS Code выглядят скорее осторожным первым шагом, чем жесткой обороной. Два часа на фоне семи дней у pip или даже многодневных внутренних политик в компаниях смотрятся довольно скромно. Но важно другое: Microsoft фактически признает, что модель «обновляй все немедленно, это безопаснее» больше не выглядит бесспорной. Для индустрии это заметный культурный сдвиг. Еще недавно любая задержка апдейтов воспринималась как антишаблон. Теперь зрелые экосистемы одна за другой добавляют тормоз, потому что цена мгновенной доставки оказалась слишком высокой.
Реакция сообщества, если верить обсуждению на Reddit, была предсказуемо язвительной. Самый заметный комментарий, набравший более 650 апвотов, сводился к простой мысли: двух часов мало, потому что многие компрометации находили не через часы, а через дни и недели. Другой участник дискуссии, представляющий security-практику, пошел еще дальше и фактически оспорил культ немедленных патчей: в средах с высоким уровнем безопасности задержка обновлений на неделю или даже месяц давно не выглядит ересью, если речь не идет о точечных исправлениях под уже известную критическую уязвимость.
При этом не все участники обсуждения списали идею в утиль. Часть комментаторов напомнила, что подозрительные пакеты и расширения часто первыми замечают не люди, а автоматические сканеры. Для них даже короткое окно может быть полезным: машина успеет поднять флаг, а команда безопасности хотя бы попробует проверить тревогу до массового раската. Но и здесь звучала та же претензия: два часа для этого сценария тоже не выглядят щедрым запасом.
Что это значит для команд
Самый практичный вывод для бизнеса и инженерных руководителей довольно приземленный. Обновления расширений VS Code теперь по умолчанию чуть безопаснее, но рассчитывать, что эта настройка сама по себе закроет проблему supply chain-атак, не стоит. Если у компании есть требования к контролю рабочих окружений, двухчасовая задержка не заменит внутреннюю политику. Варианты уже привычны: отключать автообновления, фиксировать допустимые версии, собирать allowlist расширений, раздавать их через policy-based механизмы или вовсе держать курируемый внутренний marketplace. Да, это скучнее, чем «нажал Install и забыл», зато и сюрпризов заметно меньше.
Отдельно любопытно, куда может пойти сама продуктовая логика VS Code. В обсуждении предлагали не только удлинять задержку, но и менять модель защиты. Один лагерь хочет песочницу и явные разрешения для расширений по аналогии с мобильными ОС: доступ к файловой системе, сети, терминалу и другим чувствительным возможностям должен быть прозрачен и ограничен. Другой лагерь предлагает staged rollout: сначала 5% пользователей, потом еще 10% через пару часов, дальше постепенное масштабирование на протяжении дней. Такой сценарий лучше соответствует реальности крупных платформ: если релиз все-таки окажется вредоносным, под удар попадет не вся база сразу.
На фоне общей картины эта история выглядит еще показательнее из-за контраста с экосистемами, где подобных предохранителей до сих пор нет. InfoQ напоминает о недавнем кейсе с WordPress: атакующий купил более 30 плагинов на Flippa, добавил бэкдор в первом коммите и активировал его только через восемь месяцев. Там не было ни задержки публикации, ни отдельной проверки смены контроля над проектом, ни обязательной подписи кода. После таких историй двухчасовой буфер в VS Code можно считать не финальным ответом, а минимальным санитарным порогом. Похоже, рынок уже пришел к неприятному, но полезному выводу: в цепочке поставок скорость обновления сама по себе больше не равна безопасности, а значит следующий спор будет не о том, нужна ли задержка, а о том, какой именно ценой экосистемы готовы покупать дополнительное время на обнаружение атаки.