Composer 2.11 добавил карантин для новых версий пакетов

29 октября 2026 года вышел Composer 2.11 — об этом объявила сама команда Packagist в официальном блоге. Главное изменение релиза — новая политика cooldown: Composer теперь умеет withholding (откладывать) свежепоявившиеся версии зависимостей на заданный срок, прежде чем предложит поставить их в проект. Независимо разбор фичи и её практических следствий для команд на Laravel опубликовал security-блог Securing Laravel — оба источника сходятся в деталях конфигурации и мотивации изменения.

Как работает cooldown

Политика включается в composer.json через секцию config.policy.cooldown — по умолчанию она выключена, то есть ничего не меняется в проектах, которые не настроили её явно. При заданном периоде, например "period": "7 days", Composer исключает из резолва зависимостей версии пакетов моложе этого срока — и при composer update, и при composer require. Для случаев, когда ждать нельзя — например, вышел патч для уже найденной уязвимости — добавлен флаг --no-cooldown, который снимает ограничение для одной конкретной команды, не трогая остальные политики безопасности проекта.

Почему это реакция на supply-chain-атаки

Идея не абстрактная: за 2026 год через npm прошла серия волн worm-кампаний вроде Shai-Hulud, когда вредоносный код публиковался в виде минорного обновления легитимного пакета и расползался по зависимостям раньше, чем его успевали снять с регистра. У PHP-экосистемы Composer/Packagist своя версия того же риска — автообновление зависимостей в CI тянет самую свежую версию мгновенно, не оставляя времени ни исследователям безопасности, ни самому Packagist на реакцию. Cooldown не блокирует атаку технически, но меняет экономику: злонамеренному релизу нужно пережить несколько дней публичной видимости, прежде чем он попадёт хотя бы в одну реальную сборку — а именно в эти дни такие пакеты чаще всего и находят.

Что проверить в проекте

• Обновиться на Composer 2.11.0 и прочитать, какие ещё изменения резолва зависимостей вошли в релиз — не только cooldown
• Решить для каждого проекта осознанно: включать ли cooldown и на какой срок — для low-traffic внутренних сервисов 3–7 дней обычно не мешают циклу разработки
• Завести в CI отдельный шаг с --no-cooldown для случаев срочного патчинга известной уязвимости, чтобы cooldown не превратился в причину держать дырявую версию
• Проверить lock-файл и список прямых зависимостей на версии, которые были обновлены автоматически без явного ревью — именно такие апдейты чаще всего остаются незамеченными до инцидента

Настройка политики безопасности зависимостей — разовая задача, но то, что происходит с проектом дальше (кто и как ревьюит обновления, растёт ли технический долг, успевает ли команда следить за экосистемой), решает уже не конфиг-файл. Если в проекте давно никто системно не пересматривал процесс работы с зависимостями и обновлениями, разумный шаг — привлечь внешнюю команду: мы уже разбирали практики безопасной работы с Composer в материале «Composer без боли», а системное сопровождение и доработку самого веб-приложения на таком стеке можно отдать команде, которая держит процесс обновления зависимостей под контролем на регулярной основе.