Руководство по реагированию на инцидент Vercel от апреля 2026 года
Последнее обновление: 20 апреля 2026 г., 12:07 по восточному стандартному времени Австралии/Брисбен (v2 — включает обновление от генерального директора Vercel от 20 апреля)
ВАЖНО: Это не юридическая или официальная консультация. Если вы считаете, что были скомпрометированы, обратитесь к партнеру по реагированию на инциденты. Эта информация предоставляется исключительно в качестве доброй воли командой OpenSourceMalware. Если вам нужны контакты компаний, занимающихся реагированием на инциденты, мы можем предложить несколько, с которыми мы работали.
Что произошло?
Vercel раскрыла 19 апреля 2026 года, что злоумышленник получил несанкционированный доступ к внутренним системам. Вот официальное объявление:
20 апреля генеральный директор Vercel Гильермо Рауч опубликовал подробное обновление, подтверждающее начальный путь доступа: сотрудник Vercel использовал AI-платформу под названием Context.ai, которая сама была взломана; оттуда злоумышленник переключился на учетную запись сотрудника в Google Workspace и повысил привилегии до сред Vercel. Переменные окружения зашифрованы в состоянии покоя, но злоумышленник смог перечислить переменные, не помеченные как «чувствительные». Vercel характеризует злоумышленника как высококвалифицированного и, вероятно, с использованием AI-ускорения. Google Mandiant участвует в реагировании. Vercel заявляет, что Next.js, Turbopack и их проекты с открытым исходным кодом остаются в безопасности.
Вот важный раздел с индикаторами компрометации из этого уведомления о безопасности:
Довольно скудно на детали. Они даже не говорят, где искать этот единственный Google IOC. Как клиент Vercel, я весьма разочарован таким уровнем детализации. Помогите мне понять, что искать! Скажите, куда пойти, чтобы узнать, был ли я скомпрометирован или нет!
В отсутствие деталей от Vercel мы создали этот документ
Если вы запускаете рабочие нагрузки на Vercel, предполагайте следующее, пока не будет доказано обратное:
- Переменные окружения, не помеченные как «чувствительные» в любом проекте Vercel в окне воздействия, могли быть читаемыми.
- Любые учетные данные, отправленные в Vercel через панель управления или CLI
vercel env, которые не были ротированы, являются постоянной угрозой.
- Токены внутри путей интеграции Vercel ↔ GitHub и Vercel ↔ Linear могли быть доступны.
- Вы не получите четкого сигнала «вы затронуты / вы не затронуты» быстро. Сначала ротируйте, затем расследуйте.
Известное против заявленного: держите это раздельно в своих брифингах
Это различие важно для коммуникаций с руководством и для того, чтобы не чрезмерно реагировать (или нед реагировать).
Подтверждено Vercel (бюллетень + обновление генерального директора от 20 апреля)
- Несанкционированный доступ к определенным внутренним системам Vercel.
- Начальный вектор доступа: Context.ai, AI-платформа, используемая сотрудником Vercel, была взломана. Злоумышленник использовал эту точку опоры для компрометации учетной записи сотрудника Vercel в Google Workspace, затем повысил привилегии до сред Vercel.
- Переменные окружения клиентов зашифрованы в состоянии покоя. Переменные, обозначенные как «нечувствительные», тем не менее могли быть перечислены злоумышленником после проникновения.
- Воздействие на клиентов характеризуется как «весьма ограниченное»; Vercel напрямую связалась с клиентами, в отношении которых у них есть опасения.
- Next.js, Turbopack и проекты Vercel с открытым исходным кодом были проанализированы и, как полагают, остаются в безопасности (т.е. никаких вредоносных артефактов в пути выпуска этих проектов по состоянию на заявление Vercel от 20 апреля).
- Злоумышленник характеризуется как высококвалифицированный и, вероятно, значительно AI-ускоренный.
- Партнеры по реагированию: Google Mandiant активно участвует; привлечены внешние IR-фирмы, отраслевые коллеги и правоохранительные органы.
- Vercel связалась с Context.ai, чтобы помочь понять полный масштаб.
- Vercel выпустила улучшения пользовательского интерфейса: страница обзора переменных окружения, улучшенное управление чувствительными переменными окружения.
Сообщено / приписано третьими сторонами и злоумышленником (не подтверждено Vercel)
- Интеграции с Linear и GitHub непропорционально затронуты (сообщения сообщества, особенно от Theo Browne в X).
- Данные выставлены на продажу на BreachForums: внутренняя БД, учетные записи сотрудников, токены GitHub, токены npm, фрагменты исходного кода, временные метки активности — предложены примерно за $2M.
- Актор идентифицирует себя как ShinyHunters; другие акторы, исторически связанные с этим псевдонимом, отрицали свою причастность.
- Конкретные классы данных клиентов, выходящие за пределы того, что Vercel напрямую подтвердила клиентам.
Относитесь к неподтвержденным сообщениям как к правдоподобным и действенным для собственного анализа, но не ссылайтесь на них как на факт в коммуникациях с клиентами или регулирующими органами, пока Vercel не подтвердит это или у вас не будет независимых доказательств. Разрыв между «перечислимые переменные окружения» (подтверждено Раучом) и «токены npm + GitHub на продажу на BreachForums» (заявление злоумышленника) — это разрыв, который наиболее важен для риска цепочки поставок — предполагайте худшее для целей ротации, придерживайтесь подтвержденной версии для коммуникаций.
Определение масштаба: кому нужно выполнять этот сценарий
Наивысшая срочность — вы получили прямое обращение от Vercel или применимо любое из следующего:
- У вас есть (или была) интеграция Vercel ↔ GitHub с областью записи в репозиторий.
- У вас есть (или была) интеграция Vercel ↔ Linear.
- Вы храните незашифрованные секреты (не помеченные как чувствительные) в виде переменных окружения Vercel.
- Вы публикуете пакеты npm из CI/CD, который запускается на инфраструктуре Vercel или через нее.
Стандартная срочность — любая команда с активными проектами Vercel, даже маркетинговые сайты. Маркетинговые сайты часто содержат ключи API CMS, токены аналитики и вебхуки обработчиков форм, которые могут переключиться на более чувствительные системы.
Все равно сделайте — даже если ваши проекты были удалены до инцидента. Вопрос в том, находились ли секреты когда-либо в Vercel в читаемой форме, а не в том, существует ли проект до сих пор.
Параллельный вопрос: подвержена ли ваша организация воздействию Context.ai напрямую?
В обновлении от 20 апреля упоминается Context.ai как взломанный вышестоящий поставщик. Если кто-то в вашей организации использует Context.ai независимо от Vercel — для интеллектуального анализа встреч, управления знаниями, обогащения CRM или любого другого рабочего процесса — у вас может быть собственное окно прямого воздействия, отдельное от инцидента Vercel.
Выполните эти проверки параллельно:
- Запросите ваш SSO / IdP (Okta, Entra, Google Workspace) на предмет любого пользователя, который прошел аутентификацию в Context.ai или связанном OAuth-приложении.
- Поищите в консоли администратора Google Workspace → Безопасность → Журналы доступа OAuth приложений на предмет
context.ai или связанных идентификаторов приложений.
- Проверьте корпоративные инструменты управления расходами / SaaS spend management на предмет подписок Context.ai.
- Проверьте, какие области OAuth были предоставлены — чтение Gmail, Календарь, Диск и области видимости каталога Workspace имеют высокое влияние.
Если вы обнаружите использование Context.ai в вашей среде, отзовите OAth-гранты, ротируйте любые учетные данные, которые проходили через рабочие процессы Context.ai, и отслеживайте учетные записи затронутых пользователей в Google Workspace на предмет тех же индикаторов компрометации, которые Vercel описывает на своей учетной записи сотрудника. Обратитесь напрямую в Context.ai для получения собственных деталей инцидента; Vercel публично заявила, что координирует действия с Context, чтобы помочь другим затронутым организациям.
Фаза 0: Остановить кровотечение (первые 60 минут)
Две цели: предотвратить новый ущерб, сохранить доказательства.
-
Заморозьте развертывания. Приостановите автоматическое развертывание на производственных ветках. Вы хотите предотвратить отправку измененного злоумышленником билда и остановить ротацию журнала аудита.
-
Отключите GitHub App Vercel. Если у вас установлен GitHub App Vercel, что будет, если вы выполняете автоматическое развертывание на Vercel при отправке нового кода в GitHub. Вы можете найти установленные GitHub-приложения по адресу https://github.com/organizations/<GitHub-Organization>/settings/installations
-
Определите, какой доступ имеет GitHub App. Нажмите кнопку «Настроить» выше и проверьте, к каким репозиториям имело доступ приложение Vercel. Это указывает, на чем вам нужно сосредоточиться прямо сейчас. Перейдите в GitHub → Организация → Настройки → GitHub Apps → Vercel. Проверьте:
- Доступ к репозиториям (все репозитории или выбранные)
- Предоставленные разрешения
- Дата установки и кто установил
- Сделайте снимок журнала аудита Vercel для вашей команды. Экспортируйте или сделайте скриншот немедленно. Окно хранения ограничено, и интерфейс не показывает все. Получите это, прежде чем начнете вносить изменения, которые загрязнят журнал. Вы можете найти его по адресу https://vercel.com/activity-log
- Включите «Observability Plus». Это дополнительная платная функция от Vercel, и это отстой, что я должен предлагать вам включить ее и ЗАПЛАТИТЬ за нее, но в данном случае я считаю, что это лучшее, что можно сделать во время реагирования на инцидент. Я, конечно, не рад этому, но я включил ее просто потому, что она сохраняет журналы аудита дольше, чем по умолчанию, который ОЧЕНЬ короткий.
- Проведите инвентаризацию широты воздействия. Для каждой команды/учетной записи Vercel, которую вы контролируете, перечислите:
- Проекты и связанные с ними Git-репозитории
- Подключенные интеграции (GitHub App, Linear, Slack, интеграции маркетплейса)
- Члены команды и их роли
- Персональные токены доступа / токены API, выпущенные в рамках команды
- Deploy hooks
- Просмотрите журнал аудита GitHub Organization. Ищите в окне воздействия (ориентировочно, с 1 по 15 апреля 2026 г. по настоящее время). Фильтруйте:
repo.add_member, repo.add_topicorg.invite_member, org.add_memberintegration_installation, integration_installation.repositories_addedprotected_branch.destroy,
Пока не делайте объявлений и не ротируйте секреты. Сначала нужен снимок.
Фаза 1: Проверка индикаторов компрометации (IOC)
Подробности из объявления Vercel довольно скудные:
Насколько мы можем судить, они предлагают перейти в консоль администратора Google Workspace и найти это приложение googleusercontent.com. Вот как это найти в консоли:
-
В консоли администратора workspace перейдите в Безопасность > Доступ и контроль данных > Управление API и найдите приложения с доступом и ожидающие приложения.
-
Затем найдите в различных списках IOC, который, по-видимому, является OAuth-приложением: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
Если вы его нашли, немедленно удалите и обратитесь к партнеру по реагированию на инциденты. Это выше моей квалификации.
Фаза 2: Ротация учетных данных
Ротация — это единое действие с наивысшей ценностью. Делайте это в порядке приоритета, чтобы, если вас прервут, самое опасное уже было обработано.
Что вам нужно ротировать, зависит от того, что было раскрыто в ваших средах GitHub и Vercel. Начните с GitHub PATs и т.д. и двигайтесь дальше, используя это руководство.
Уровни приоритета
Уровень 0 — Ротировать сегодня, до всего остального:
- Немедленно ротируйте все GitHub PATs и завершите все существующие сессии. Personal Access Tokens, или PATs. Есть два типа PATs:
- Немедленно ротируйте любые переменные окружения Vercel, которые являются чувствительными: http://vercel.com/all-env-vars
Уровень 1 — Ротировать сегодня, в зависимости от того, что у вас раскрыто в приложениях:
- Секретные ключи платежных процессоров (Stripe, Adyen, Braintree и т.д.)
- Секреты подписи аутентификации (NextAuth
AUTH_SECRET / NEXTAUTH_SECRET, ключи подписи JWT, ключи cookie сессии, CSRF-токены)
- Строки подключения к базам данных с доступом на запись (
DATABASE_URL, прямые URL Postgres/MySQL, Mongo URI, Redis с аутентификацией)
- Ключи облачных провайдеров с корневым или широким доступом (ключи доступа IAM AWS, JSON-ключи сервисных аккаунтов GCP, секреты клиента Azure)
- Секреты подписи вебхуков (Stripe, GitHub, Slack — ротируйте и обновите конфигурацию отправителя)
Уровень 2 — Ротировать на этой неделе:
- Ключи API сторонних SaaS (аналитика, почтовые провайдеры, SMS, CRM)
- Секреты OAuth-клиентов для ваших собственных приложений
- Учетные данные SMTP
- Ключи шифрования для криптографии на уровне приложения (ротируйте с увеличением версии ключа, а не с заменой на месте)
- Ключи CDN purge, ключи сервисов изображений
- Ключи провайдеров feature flag
Уровень 3 — Ротировать, когда удобно, но все равно ротируйте:
- Токены аналитики только для чтения
- Sentry / логирования DSN (примечание: ротация DSN не критична, если вы готовы к небольшому окну пропущенных событий)
- Открытые ключи и анонимные ключи (все равно ротируйте — они могут раскрыть существование проекта и иногда обеспечить перечисление)
Подводные камни порядка действий
- Ключи подписи сессий аннулируют все активные сессии при ротации. Планируйте принудительный выход. Сообщите об этом.
- Секреты вебхуков должны быть ротированы на обоих концах. Сначала обновите отправителя (Stripe, GitHub), чтобы он отправлял под новым секретом, затем ваш получатель для проверки по нему. Или временно поддерживайте оба варианта.
- Учетные данные базы данных — сначала создайте нового пользователя, разверните, затем отзовите старого. Не заменяйте на месте, иначе вызовете простой.
- Ключи AWS — если вы ротируете ключи доступа пользователя IAM, создайте второй ключ, выполните развертывание, затем удалите первый. Не делайте
deactivate и не надейтесь.
- Повторно разверните после изменений переменных окружения. Переменные окружения Vercel встраиваются во время сборки для многих конфигураций фреймворков. Изменение переменных окружения без нового развертывания не применяется полностью.
- Проверьте также секреты CI. Если секрет был продублирован в GitHub Actions, CircleCI и т.п., ротируйте дубликат.
Не забудьте эти распространенные упущения
.env.local закоммиченный в приватный репозиторий (все еще проблема — исходный код мог быть выкраден)- Секреты в preview/development-средах Vercel, не только в production
- Секреты, сохраненные как общие переменные окружения на уровне команды Vercel
- Deploy hooks (ротируйте их; они являются полными триггерами развертывания)
- Персональные токены доступа Vercel, выпущенные в вашей учетной записи
- GitHub Personal Access Tokens, которые авторизовали установку GitHub App Vercel (отдельно от самого приложения)
Фаза 3: Охота на уровне репозиториев
Для репозиториев, которые были подключены к Vercel:
- Сравните HEAD
main/master с тегом/коммитом, который вы знаете как безопасный до окна инцидента.
- Ищите изменения в:
package.json → scripts (особенно postinstall, prepare, preinstall)package-lock.json / pnpm-lock.yaml / yarn.lock — неожиданные добавления зависимостей или обновления версий.github/workflows/*.yml — новые workflows, новые шаги run:, новые uses: с нефиксированными SHAvercel.json — изменения команд сборки, новые rewrites/redirects, которые могут перехватывать трафик
Если вы публикуете npm-пакеты из этих репозиториев
Это место, где компрометация Vercel может стать событием в цепочке поставок. Даже если вы не используете Vercel для публикации, если злоумышленник получил ваш GitHub-токен, а ваш workflow публикации использует этот токен:
- Проверьте историю публикаций
npm: npm view <pkg> time --json на наличие неожиданных версий.
- Сравните tarball каждой последней версии с git-тегом, от которого она якобы происходит. Злоумышленники публикуют с тега, который не соответствует тому, что находится в реестре.
- Проверьте использование
NPM_TOKEN в workflows — ротируйте токен, проверьте, кто имел к нему доступ.
- Проверьте новых мейнтейнеров, добавленных в ваши пакеты:
npm owner ls <pkg>.
- Если вы поддерживаете что-то значимое, следите за выполнением post-install-скриптов в tarball — распакуйте и проверьте.
Если вы найдете доказательства несанкционированной публикации, сообщите об этом в службу безопасности npm ([email protected]) и рассмотрите возможность подачи заявки в OSV.dev. Сделайте деприкейт плохой версии; не удаляйте (удаление ограничено по времени и нарушает работу нижестоящих потребителей).
Примечание о пакетах, принадлежащих Vercel: Vercel в своем обновлении от 20 апреля заявляет, что Next.js, Turbopack и их проекты с открытым исходным кодом были проанализированы и считаются безопасными. Это утверждение Vercel об их пути выпуска — вы все равно должны проверить свои пакеты, как указано выше. Если вы используете Next.js или Turbopack, вам не нужно фиксироваться на версии до инцидента в качестве меры предосторожности на основе текущей информации, но следите за бюллетенем Vercel на предмет изменений в этой позиции.
Фаза 4: Проверка интеграции Linear
Если ваша команда использует интеграцию Vercel ↔ Linear:
- Просмотрите журнал аудита Linear (Настройки рабочего пространства → Безопасность → Журнал аудита) за окно воздействия.
- Ищите:
- Новые выпущенные ключи API
- Новые добавленные интеграции
- Комментарии, опубликованные сервисными учетными записями
- Изменения в назначениях вебхуков
- Приглашения участников
- Просмотры/экспорты данных задач (интеграция имеет доступ на чтение к задачам, которые часто содержат имена клиентов, детали ошибок, а иногда и учетные данные, вставленные в тикеты)
- Особое внимание: в задачах Linear часто содержатся вставленные секреты из отладки разработчиков. Прочешите ваше рабочее пространство Linear на предмет распространенных шаблонов утечек (
AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, ----BEGIN). Все найденное должно быть ротировано.
Фаза 5: Проверка журналов нижестоящих систем
Ротация учетных данных в большинстве случаев аннулирует возможность закрепления злоумышленника, но они могли уже использовать доступ. Проверьте потребителей ваших ротированных секретов на наличие признаков использования в окне воздействия.
Окна для проверки
Используйте 1 апреля 2026 года по настоящее время в качестве консервативной нижней границы. Инцидент был раскрыт 19 апреля, но первоначальный доступ предшествовал раскрытию. Если Vercel опубликует более точную дату, мы соответствующим образом сузим это окно.
Что запрашивать
- AWS CloudTrail — необычные вызовы API от скомпрометированных ключей IAM, особенно всплески
GetObject против S3-бакетов, CreateUser, AttachUserPolicy, входы в консоль из новых ASN/стран.
- Журналы аудита базы данных — необычные
SELECT * по чувствительным таблицам, большие экспорты, подключения с неожиданных IP-адресов.
- Журналы платежей Stripe — необычное создание клиентов, создание переводов, создание ключей API.
- Журналы провайдера аутентификации (Auth0, Clerk, Cognito, Firebase) — входы с невозможным перемещением, сбросы паролей для администраторов, новые регистрации приложений.
- Почтовый провайдер (SendGrid, Postmark и т.д.) — неожиданные исходящие кампании, новые ключи API, изменения отправителя.
- GitHub — клонирования, создания форков, новые SSH-ключи в учетных записях пользователей с доступом к репозиториям.
Полезные примитивы охоты по IOCs
Вставьте любые управляемые злоумышленником hostname или IP, опубликованные Vercel или партнерами по IR, в:
- Журналы доступа HTTP вашего фронтенда (злоумышленники иногда предварительно проверяют доступ перед действием).
- DNS-логи — исходящее разрешение необычных доменов с ваших серверов.
- Исходящий прокси / VPC flow logs.
На момент публикации IOCs не были опубликованы Vercel. Следите за бюллетенем Vercel и публикациями известных IR-фирм для обновлений.
Фаза 6: Обнаружение остаточной компрометации
Закрепление злоумышленника после взлома на уровне платформы обычно принимает следующие формы. Активно ищите каждую:1. Новые члены команды или соавторы в вашей команде Vercel, организации GitHub, рабочем пространстве Linear или облачных аккаунтах. В пределах окна компрометации.
2. Новые авторизации OAuth в подключенных SSO-провайдерах (Google Workspace, Okta, Entra ID) для учетных записей ваших разработчиков.
3. Измененная конфигурация CI/CD — рабочие процессы, которые теперь отправляют данные на внешние серверы, новые собственные раннеры, новые секреты с безобидными именами.
4. Неожиданные развертывания в Vercel — проверьте историю развертываний на предмет тех, которые вы не можете сопоставить с известным коммитом от известного автора.
5. Индикаторы reverse shell в логах serverless-функций — base64-блоб, который записывается/выполняется, необычные исходящие соединения от Edge/Serverless Functions.
6. Изменения в DNS — новые поддомены, изменения CNAME, редиректы, добавленные через vercel.json или конфигурацию фреймворка.
7. Изменения в аутентификации — отключена MFA, сгенерированы новые коды восстановления, изменен пароль без действий пользователя.
Коммуникации
Внутренние
Назначьте руководителя инцидента. Минимум ежедневные стендапы, пока продолжается ротация. Единственный достоверный источник документа «что мы ротировали, что в ожидании, что мы нашли». Не храните в Linear, если Linear находится в зоне ответственности инцидента — используйте побочный канал.
Для клиентов
Проконсультируйтесь с юристом. Пороги уведомления различаются, но:
- GDPR: 72 часа для уведомляемых утечек, затрагивающих резидентов ЕС.
- Австралия (схема Notifiable Data Breaches, OAIC): уведомить как можно скорее, если вероятен серьезный вред.
- США: от штата к штату; в некоторых штатах есть окна в 30–60 дней, другие требуют немедленного уведомления для определенных категорий данных.
- Калифорния (CCPA): особые обязательства, если затронута личная информация жителей Калифорнии.
- Клиенты SOC 2 / ISO 27001: договорные положения об уведомлении часто требуют более раннего уведомления, чем установлено регулирующими минимумами. Прочтите ваши MSA.
Если у вас нет доказательств утечки данных из ваших систем, у вас может еще не возникнуть обязательство по уведомлению — но «мы используем Vercel, и у Vercel был инцидент» само по себе обычно недостаточно для триггера уведомления, если конфиденциальные данные не были существенно подвержены риску. Документируйте свои обоснования.
Заготовленные заявления
Составьте их до того, как они понадобятся:
- Внутреннее собрание для всех сотрудников
- Уведомление для клиентов
- Шаблон уведомления для регулятора
- Обновление страницы статуса (если публично)
Гигиена публичных заявлений
Не повторяйте публично утверждения атакующих как факт. Ссылайтесь на бюллетень Vercel как на первоисточник. Позвольте Vercel охарактеризовать свой собственный инцидент — вы находитесь в своей зоне ответственности, характеризуя свою собственную подверженность.
Среднесрочное усиление защиты (после инцидента)
Этот инцидент выявляет структурные проблемы, которые стоит исправить, даже если вы окажетесь незатронутыми.
- Перенесите все секреты в функцию чувствительных переменных окружения Vercel. Сделайте это стандартом команды. Обучите разработчиков отмечать их при создании.
- Используйте краткосрочные учетные данные, где это возможно. Используйте федерацию OIDC GitHub с AWS/GCP/Azure вместо долгоживущих ключей доступа, зеркалированных в переменные окружения Vercel. Используйте облачные менеджеры секретов (AWS Secrets Manager, GCP Secret Manager), доступные во время выполнения, вместо встроенных переменных окружения.
- Проведите инвентаризацию сторонних OAuth-приложений, подключенных к вашему Google Workspace, Microsoft 365, организации GitHub и команде Vercel. IAV Vercel был Context.ai — AI-платформа, интегрированная через OAuth в учетную запись сотрудника в Google Workspace. Тот же класс риска существует в каждой организации, которая щедро одобряла интеграции SaaS и AI-инструментов, и планка для «что получает одобрение» значительно снизилась во время золотой лихорадки AI-инструментов за последние 18 месяцев. Конкретные действия:
- Запросите отчет об OAuth-приложениях Google Workspace (Консоль администратора → Безопасность → Управление API → Контроль доступа к приложениям). Проверьте каждое приложение с чувствительными областями (
gmail.readonly, calendar, drive, admin.directory).
- Сделайте то же самое для Microsoft 365 (Entra ID → Корпоративные приложения).
- Установите ежеквартальный обзор. Требуйте одобрения службы безопасности для новых предоставлений OAuth, несущих чувствительные области.
- Рассмотрите возможность ограничения установки OAuth-приложений списком разрешенных, а не утверждением пользователем.
- Принцип минимальных привилегий для области приложения GitHub. Если Vercel не нужен доступ ко всем репозиториям организации, ограничьте его теми, которые он действительно развертывает.
- Ротация deploy hook как рутина. Ежеквартально.
- Внедрите сканирование секретов в ваш pre-commit и CI. Trufflehog, gitleaks или аналоги. Ретроспективно просканируйте историю репозитория на предмет того, что могло быть закоммичено, а затем ротировано — предполагайте, что однажды закоммиченное все еще находится в каком-нибудь клоне.
Справка
Список изменений
- 2026-04-20 (v2) — Обновлено после заявления генерального директора Vercel Гильермо Рауха от 20 апреля. Несколько пунктов переведены из разряда «сообщалось» в «подтверждено»: Context.ai назван скомпрометированным поставщиком выше по цепочке, учетная запись Google Workspace сотрудника Vercel как точка входа, перечисление нечувствительных переменных окружения как горизонтальное перемещение внутри платформы. Добавлено параллельное определение масштаба для прямого воздействия Context.ai. Добавлено заявление Vercel о том, что Next.js, Turbopack и проекты с открытым исходным кодом остаются в безопасности. Добавлено привлечение Mandiant. Усилена рекомендация по инвентаризации OAuth-приложений.
- 2026-04-20 (v1) — Первоначальная версия. Основана на бюллетене Vercel от 2026-04-19 и современных публичных сообщениях. Обновляйте по мере публикации Vercel дополнительных деталей, IOCs или более узкого окна компрометации.
opensourcemalware/vercel-april2026-incident-response
