Ваша программа CTEM, скорее всего, игнорирует MCP. Как это исправить

Протокол контекста модели (Model Context Protocol, MCP) является связующим звеном современного инструментария ИИ и незаметно превратился в одно из самых значительных «слепых пятен» в современных программах безопасности. Подобно теневому ИТ (shadow IT) до него, теневой ИИ — особенно в части рисков, связанных с MCP — порождает новый класс уязвимостей, для обнаружения и устранения которых у команд безопасности нет адекватных инструментов. Интеграция рисков MCP в программу непрерывного управления подверженностью угрозам (Continuous Threat Exposure Management, CTEM) может помочь командам безопасности не отставать, предоставляя структурированную методологию и операционную гибкость, необходимые для выявления уязвимостей MCP до того, как это сделают злоумышленники.

Безопасность всегда была гонкой между скоростью роста поверхности атаки и скоростью, с которой защитники могут ее обнаружить. Управление уязвимостями (Vulnerability Management) было первой серьезной попыткой вести эту гонку систематически. Это работало до тех пор, пока среда не стала слишком сложной, и команды безопасности обнаружили, что приоритизируют то, что громче заявляет о себе, а не то, что наиболее опасно. CTEM основан на том же основном инстинкте — находить уязвимости до злоумышленников, но он лучше отражает бизнес- и технические реалии современных ИТ-сред. Большинство зрелых программ безопасности уже имеют его основу. Вопрос с MCP не в том, применим ли CTEM. Вопрос в том, расширена ли его область применения для его включения.

Представленный Anthropic в конце 2024 года, MCP выступает в роли архитектуры плагинов для агентного ИИ. Если ваша команда не сканирует, не картирует и не отслеживает риски MCP, у вас есть «слепое пятно», которое растет каждый раз, когда разработчик устанавливает новый инструмент. MCP берет «старые» риски, такие как атаки на цепочку поставок, жестко закодированные учетные данные, повышение привилегий, удаленное выполнение кода, и делает их снова новыми.

Вот как это происходит:

Теневой ИИ: Нельзя защитить то, чего не видишь

В 2025 году исследователи задокументировали первый подтвержденный вредоносный MCP-сервер в дикой природе. Средством послужил пакет npm под названием postmark-mcp — инструмент, помогавший разработчикам интегрировать ИИ-помощников со службой электронной почты Postmark. Злоумышленник был терпелив. Со временем он выпустил пятнадцать легитимных версий, набрал около 1500 еженедельных загрузок и завоевал искреннее доверие в сообществе разработчиков. Затем в одну из версий была внедрена одна строка кода, которая ставила в копию (BCC) все исходящие электронные письма на внешний адрес.

Около 300 организаций пострадали, прежде чем кто-либо это заметил. Сбросы паролей, счета-фактуры, внутренние служебные записки, конфиденциальные документы — все это эксфильтровалось неделями, не вызвав ни одного оповещения. Тактика повторяет сценарий SolarWinds: сначала завоевать легитимность, затем совершить компрометацию и рассчитывать на то, что однажды что-то получившее доверие перестает подвергаться проверке.

Предприятия накопили слои управления для работы с рисками стороннего программного обеспечения — проверки при закупках, оценки поставщиков, согласования безопасности. В экосистеме MCP этого пока нет. Разработчики загружают серверы из npm так же, как и любую другую зависимость с открытым исходным кодом: быстро, на веру, не особо задумываясь о том, что произойдет, когда инструмент подключится к их ИИ-агенту, а через него — к внутренним данным. Это не критика; это проблема видимости. Проблемы видимости решаются не политикой. Они решаются знанием того, что находится в вашей среде.

Ключи под ковриком: Жестко закодированные учетные данные в конфигурациях ИИ

В 2023 году вредоносное ПО для кражи информации похитило более 225 000 учетных записей ChatGPT. Многие из них содержали ключи API, которые разработчики жестко закодировали непосредственно в конфигурационных файлах — не по халатности, а по той же логике, которая всегда двигала компромиссами в безопасности: это быстрее, это работает, а последствия кажутся абстрактными, пока они не становятся реальными.

Более поучительный сценарий проще: разработчик случайно фиксирует (commits) производственный файл .env, содержащий ключи API для OpenAI, Stripe, AWS и SendGrid. Автоматизированные боты находят его в течение нескольких часов. Затем следуют мошеннические списания за облачные сервисы. Сложный злоумышленник не требуется — достаточно ошибки, которая пролежала в репозитории достаточно долго, чтобы ее нашел сканер.

MCP структурно усугубляет эту ситуацию, поскольку для функционирования ИИ-агентам требуются учетные данные. Им нужны ключи для LLM, ключи для облачных сервисов и ключи для сторонних интеграций. Эти ключи должны находиться там, где агент может их получить: переменные среды в конфигурационных файлах, открытый текст в файлах инструкций Markdown или жестко закодированные в самой конфигурации сервера. Все это — статическая текстовая цель. Хакер не нужно взламывать, если он может просто войти в систему. Вопрос в том, направлены ли ваши программы сканирования на конфигурации MCP-серверов, файлы контекста Markdown, которые потребляют ИИ-агенты, и блоки переменных среды, где хранятся учетные данные. Большинство — нет.

«Режим Бога»: Когда скомпрометированы чрезмерно привилегированные ИИ-агенты

Запуск ИИ-агентов с повышенными привилегиями — обычное дело. В 2025 году исследователям понадобились два CVE, чтобы начать доказывать свою точку зрения. CVE-2025-6514, уязвимость удаленного выполнения кода в mcp-remote со скором 9.6 по шкале CVSS, стала первым продемонстрированным полным RCE в клиентской системе через соединение MCP — срабатывающим просто при подключении к недоверенному серверу. CVE-2025-49596, затронувший собственный MCP Inspector от Anthropic, получил оценку 9.4 и достиг того же результата через цепочечную уязвимость браузера, предоставив злоумышленникам полный доступ к машинам разработчиков.

Помимо CVE, исследователи обнаружили, что MCP-серверы изначально настраивались с командами повышенных привилегий — sudo, doas, runas — поскольку административные права упрощали разработку, а никто не ужесточил их впоследствии. Эта закономерность была задокументирована в рамках исследования IDEsaster, проведенного исследователем безопасности Ари Марзуком, которое каталогизировало более 30 уязвимостей в Cursor, GitHub Copilot, Windsurf и других. ИИ-IDE фактически исключили базовое ПО из своей собственной модели угроз — существующие функции считались безопасными, поскольку они были там годами, пока не появился автономный агент, способный вызывать их без запроса.

Если агент в вашей сети скомпрометирован, вопрос не в том, может ли он эксфильтровать данные, — вопрос в том, имеет ли он разрешение на удаление сервера или установку программ-вымогателей. Это вопрос конфигурации, и большинство организаций не знают ответа.

Как CTEM решает эту проблему — и что для этого нужно

CTEM — это правильный фреймворк не потому, что он был разработан с учетом MCP, а потому, что он создан для поверхностей атак, которые расширяются быстрее, чем команды безопасности могут их отслеживать; все пять фаз имеют прямое применение здесь:

• Определение области действия (Scoping) требует честного признания: инструментарий ИИ еще не включен в область действия, а должен быть. Это означает явное определение рабочих станций разработчиков, сред кодирования ИИ и конфигураций MCP как активов, которые необходимо защищать. Это также требует раннего согласования с руководством инженерных служб, поскольку работа по устранению последствий ложится на команды разработки, и они должны понимать риск, прежде чем начнут действовать.
• Обнаружение (Discovery) следует далее. MCP-серверы не появляются в традиционных инвентаризациях активов. Они находятся на рабочих станциях разработчиков, в конфигурациях ИИ-инструментов и пакетах npm, установленных за двадцать секунд — без заявки на изменение. Их обнаружение требует активной инвентаризации настроенных MCP-серверов и выявления изменений между сканированиями. Сервер, который обновляется незаметно, — это повторение сценария postmark-mcp.
• Приоритизация (Prioritization) означает отказ от соблазна помечать все подряд и работать с этим линейно. Лучшая рамка — это влияние злоумышленника: что кто-то может реально сделать из-за этой уязвимости и с чем это связано? Сигналы риска, такие как сетевые каналы передачи данных, ключи API в переменных среды или файлах инструкций, и команды с повышенными привилегиями в определениях серверов помогают отделить серьезные проблемы от менее срочных.
• Проверка (Validation) проверяет, являются ли помеченные уязвимости действительно эксплуатируемыми в контексте, используя такие методы, как картирование путей атаки и симуляция взлома и атаки для подтверждения того, что является реальным риском, а что — теоретическим.
• Мобилизация (Mobilization) сложнее, чем техническая работа. Разработчики воспринимают MCP-серверы как инфраструктуру, которая ускоряет их работу, а не как проблему безопасности. Разговоры о безопасности с разработчиками проходят лучше, когда они конкретны: вот инструмент, вот к чему он имеет доступ, вот путь атаки. Конкретика превращает совет в заявку на устранение, которая действительно закрывается.

Ничто из этого не требует новой программы, только расширения существующей. Безопасность догнала облачные технологии. Теперь она догоняет ИИ. Единственный вопрос в том, успеет ли ваша программа до того, как это сделает злоумышленник.

Эта статья публикуется в рамках сети экспертных авторов Foundry.
Хотите присоединиться?