Vercel объявила курс на отказ от долгоживущих API-ключей во всей своей экосистеме. Интеграциям из Marketplace дан срок до января 2027 года: либо они переходят на OpenID Connect и короткоживущие токены, привязанные к идентичности, либо рискуют вылететь из каталога.

Почти сразу разработчики указали на неудобную деталь: официальная инструкция по деплою через GitHub Actions по-прежнему предлагает хранить в секретах постоянный VERCEL_TOKEN, то есть ровно тот тип ключа, от которого компания призывает избавиться остальных.

Что требует Vercel

По словам технического директора Малте Убла, компания опросила более 1000 SaaS-поставщиков и выяснила, что лишь 8,4% из них поддерживают способы аутентификации, которые Vercel считает безопасными. Альтернатива статическим ключам, которые могут жить бесконечно, это OIDC и короткие токены, выдаваемые под конкретную идентичность.

Гендиректор Гильермо Раух сформулировал идею так: взломы всё равно будут случаться, но украденные учётные данные должны вести себя как «самоуничтожающиеся ключи» и истекать раньше, чем атакующий успеет ими воспользоваться. С 30 ноября интеграции, не дотягивающие до требований, получат в каталоге пометку «Not secure». Методику опроса и список компаний Vercel не раскрыла.

Двойной стандарт в деплое

Инженер Fanatics Йордис Прието публично напомнил, что OIDC-федерация у Vercel есть, а в его CI-пайплайне всё равно приходится держать долгоживущий токен, причём доступен и вариант без срока действия. В анонсе Убл пообещал распространить OIDC на API и CLI, чтобы убрать постоянные токены из сценариев деплоя, но сроков для GitHub Actions пока нет.

Для агентов и приложений у Vercel уже есть сервис Connect: он выдаёт ограниченные по правам учётные данные во время работы, опираясь на идентичность деплоя, и сам обновляет токены. Однако для провайдеров без OAuth Connect по-прежнему хранит статические ключи, пусть и централизованно.

Комментарий

Направление правильное: волна атак на цепочки поставок, включая недавний npm-червь, который вытаскивал токены прямо из CI, показывает, сколько вреда приносит один утёкший секрет. При этом ждать, пока платформа доделает OIDC, не обязательно. Уже сейчас стоит проверить секреты в репозиториях: выдавать токены с минимальными правами и сроком действия, регулярно их ротировать, а там, где хостинг или облако поддерживает OIDC из GitHub Actions, переходить на него.

Источник: The New Stack.