Vercel дала поставщикам из Marketplace время до января 2027 года, чтобы отказаться от долгоживущих секретов в пользу OIDC-аутентификации. Но объявление о том, как платформа хочет убрать статические ключи доступа из своей экосистемы, быстро получило неудобное продолжение: разработчики заметили в инструментах самой Vercel токен для развертывания. Для команд, строящих CI/CD вокруг облачных платформ, это знакомый сюжет: правильная архитектурная идея разбивается о собственное наследие продукта.
Об этом сообщает The New Stack. Vercel намерена перевести Marketplace-интеграции на модель, в которой внешний сервис получает краткоживущий идентификатор через OpenID Connect, а не хранит постоянный API-ключ или токен. Смысл простой: секрет, случайно попавший в логи, репозиторий или переменную окружения, не должен давать доступ к инфраструктуре годами. Чем короче срок жизни учетных данных и чем точнее их привязка к конкретному запуску, тем меньше цена ошибки.
У OIDC в CI/CD уже вполне прикладная репутация. Система сборки подтверждает, кто именно запустил задачу и в каком контексте, а целевая платформа выдает временные права. Это уменьшает количество секретов, которые приходится заводить, копировать между проектами и периодически менять вручную. Для поставщиков Marketplace переход означает не косметическую правку документации: им придется пересмотреть способ аутентификации, обработку токенов и, вероятно, сценарии для старых клиентов.
Дедлайн в январе 2027 года выглядит достаточно дальним, чтобы интеграторы успели перестроиться, но он важен как сигнал рынку. Vercel не просто рекомендует более безопасную схему, а планирует сделать ее обязательной для части партнерской экосистемы. В облачных инструментах разработки это становится новой нормой: постоянный ключ удобен при первом подключении, зато затем годами остается в секрет-хранилищах, CI-настройках и чужих инструкциях по интеграции. Найти все такие копии обычно сложнее, чем выпустить новый механизм аутентификации.
Именно поэтому найденный разработчиками deployment token особенно заметен. Он не отменяет ценность OIDC и сам по себе не доказывает, что платформа нарушила собственные правила: внутренние процессы, обратная совместимость и отдельные технические сценарии нередко живут по другим графикам. Но публичный призыв убрать постоянные секреты неизбежно повышает внимание к тому, как этот принцип реализован у самого автора инициативы. Без понятного объяснения исключений разговор быстро смещается с безопасности на двойные стандарты.
Для российских разработчиков здесь нет экзотики, привязанной только к Vercel. Та же проблема возникает в GitHub Actions, GitLab CI, облачных провайдерах, внутренних пайплайнах и инструментах деплоя. Если доступ к облаку или production-среде выдан через бессрочный токен, его стоит воспринимать как технический долг с понятным риском: ключ может утечь, владелец может смениться, а назначение токена со временем перестанет быть очевидным. Переход на федеративную аутентификацию требует настройки ролей и доверенных утверждений, зато позволяет ограничить доступ конкретным репозиторием, веткой, окружением или запуском задачи.
Практический вывод для команд не сводится к срочной замене всех секретов одним махом. Сначала полезно составить инвентаризацию: где используются постоянные токены, какие из них дают доступ к развертыванию, кто отвечает за их ротацию и есть ли у используемых сервисов OIDC-аналог. После этого наиболее опасные статические ключи доступа — особенно связанные с production и внешними интеграциями — логично переносить первыми. Важно также проверить аварийные сценарии: временная учетная запись не поможет, если процесс восстановления доступа по-прежнему зависит от забытого бессрочного секрета в чужом vault.
История Vercel показывает более широкий сдвиг: безопасность поставки кода все меньше зависит от того, насколько тщательно команда прячет секреты, и все больше — от возможности вообще не хранить их постоянно. Однако платформам придется пройти этот путь публично и последовательно. Пользователи вполне справедливо спросят не только о сроке миграции для партнеров, но и о том, когда аналогичные исключения исчезнут из собственных процессов вендора.
