Cursor-marketplace скомпрометировали: как не пустить AI-расширение с SSH-бэкдором на ноутбуки разработчиков

Я — Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany, и в DennisCraft AI Studio я запускаю production AI-системы для DACH B2B на стеке Claude, Supabase, n8n, Doppler и self-hosted Postgres. Если AI-расширение редактора пытается прописать SSH-ключи на ноутбуке разработчика, это уже не история про удобство IDE, а прямой путь к доступу в Git, bastion, staging и иногда в production.

История с компрометацией marketplace у Cursor важна не потому, что это “очередной supply chain incident”. Она важна потому, что AI tooling сегодня живет внутри самой доверенной зоны: локальная машина разработчика, shell, токены, SSH-agent, git-credential helper и доступ к внутренним репозиториям. Если вы уже используете Claude Code, редакторные плагины или agent workflows, вопрос не в том, случится ли попытка злоупотребления. Вопрос в том, на каком слое вы ее остановите.

Почему AI-расширение опаснее обычного плагина

Обычный плагин IDE тоже опасен, но AI-расширение получает дополнительный кредит доверия. Разработчик ожидает, что оно будет читать кодовую базу, запускать shell-команды, работать с файлами и предлагать правки. То есть поведение, которое в другом контексте выглядело бы как подозрительное, здесь выглядит “нормально”. Именно это и делает атаку такой неудобной для защиты.

Где проходит реальная граница риска

На практике атакующий не обязан сразу красть секреты. Ему достаточно сделать 1 из 3 вещей: записать persistence в ~/.ssh/config, подменить git hooks или внедрить команду в локальный workflow через shell script. После этого он получает тихую долговременную точку опоры. По моей практике в enterprise-командах, самые слабые места — это не прод-серверы, а ноутбуки инженеров с “временными” правами, которые никто не считает production perimeter.

Что ставить в защиту: не один контроль, а цепочку

OWASP давно фиксирует supply chain и insecure software integrity как отдельный класс риска. Для LLM-приложений полезно смотреть и на OWASP Top 10 for LLM Applications 2025: там отдельно разобраны tool misuse и excessive agency. Источник: OWASP, 2025, https://genai.owasp.org/. Но для разработческой машины важнее не список, а последовательность реальных блокировок.

1. Разделите среду разработки и доступы

Если AI-инструмент работает на том же хосте, где лежат постоянные SSH-ключи и production VPN, вы уже проиграли половину боя. Я рекомендую выносить AI-assisted coding либо в отдельный dev container, либо в отдельный user profile без наследования долгоживущих ключей. Даже если расширение скомпрометировано, его blast radius должен упираться в изолированную среду.

#!/usr/bin/env bash
set -euo pipefail

mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"

if grep -R "ProxyCommand\|IdentityFile" "$HOME/.ssh/config" 2>/dev/null; then
  echo "Review SSH config before starting AI tooling"
fi

export GIT_CONFIG_GLOBAL="$HOME/.gitconfig-ai"
git config --global --file "$GIT_CONFIG_GLOBAL" core.hooksPath "$HOME/.config/git-hooks-empty"
mkdir -p "$HOME/.config/git-hooks-empty"
chmod 700 "$HOME/.config/git-hooks-empty"

2. Сканируйте расширения и скрипты как обычный код

Команды часто гоняют semgrep, bandit и gitleaks по application repositories, но не прогоняют по локальным bootstrap-скриптам, editor settings и automation snippets. Это ошибка. Если расширение тянет postinstall script или shell wrapper, этот код должен идти через тот же review-путь, что и backend change.

name: local-tooling-audit
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
      - run: pip install bandit
      - run: bandit -r scripts tools
      - uses: gitleaks/gitleaks-action@v2

3. Уберите постоянные секреты с ноутбуков

Если у разработчика локально лежат production credentials, любой вредоносный плагин выигрывает мгновенно. У меня рабочая схема простая: короткоживущие токены, Doppler для выдачи секретов по роли, Supabase/Postgres доступы с узкими ролями, а production-операции только через отдельно журналируемый путь. Не храните секрет, который не готовы потерять.

Как проверить, что расширение уже не прописало бэкдор

Постфактум нужен быстрый triage. Ниже минимальная проверка артефактов, которые я бы смотрел на любой dev machine после инцидента: изменения в SSH, shell startup files, git hooks и подозрительные фоновые процессы.

from pathlib import Path
import os

paths = [
    Path.home() / ".ssh" / "config",
    Path.home() / ".bashrc",
    Path.home() / ".zshrc",
    Path.home() / ".gitconfig",
]

for path in paths:
    if path.exists():
        text = path.read_text(errors="ignore")
        for marker in ["ProxyCommand", "core.hooksPath", "curl ", "wget ", "nc -e"]:
            if marker in text:
                print(f"[!] Review {path}: found {marker}")

На что смотреть руками

Ищите не только вредоносные бинарники. Ищите легитимные механизмы persistence: LaunchAgents на macOS, cron entries, systemd user units на Linux, новые git hooks, неожиданные authorized_keys, новые known_hosts и любые shell aliases, маскирующие ssh, git, curl. Атака на разработчика любит выглядеть как “обычная автоматизация”.

Политика для AI tooling, которая работает в regulated среде

В regulated European market я не советую политику “каждый инженер ставит что хочет, если удобно”. Нужен короткий allowlist: какие расширения можно ставить, откуда, кто утверждает версию, как быстро откатывать, какие права запрещены. Отдельно фиксируйте запрет на запись в SSH-конфиги, глобальные git hooks и shell init files без явного approval.

Это можно оформить без бюрократии. 1 страница policy, 1 репозиторий с проверенными настройками, 1 автоматическая проверка drift. Этого обычно достаточно, чтобы перевести обсуждение из вкусовщины в инженерный контроль.

FAQ

Достаточно ли antivirus на ноутбуке разработчика?

Нет. В этой атаке проблема не только в malware signature, а в том, что вредоносное действие выглядит как допустимая developer automation. Вам нужен контроль прав и артефактов, а не только сигнатуры.

Нужно ли запрещать все AI-расширения?

Нет, полный запрет обычно ведет к теневому использованию. Лучше короткий allowlist, изоляция среды и журналируемый процесс обновлений.

Если команда уже использует Claude Code, что менять первым?

Сначала уберите постоянные секреты и SSH-ключи из той среды, где работает инструмент. Потом настройте сканирование shell scripts, editor configs и git hooks.

Можно ли решить проблему только через MDM?

MDM помогает с baseline и запретами, но не заменяет review локальных automation-скриптов и секрет-менеджмент. Это один слой, а не вся защита.

Это касается только Cursor?

Нет. Любой marketplace, extension host или agent runtime с доступом к локальной машине создает тот же класс риска. Название инструмента меняется, поверхность атаки — нет.

На каком этапе вашей AI-цепочки вы реально ловите больше всего проблем на практике: при установке tooling, в статическом анализе, в runtime isolation или уже после инцидента на ноутбуках инженеров? Я правда хочу это сравнить с тем, что вижу у DACH B2B команд в production.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.