Уязвимости в системе безопасности MCP: убедитесь в наличии уязвимости перед установкой исправления

Когда в вашем фиде появляется информация об уязвимости MCP, первый оперативный вопрос заключается не в том, «насколько серьезна эта уязвимость, судя по заголовку?», а в том: касается ли это предупреждение компонента, который действительно запущен в моем агенте? Ответьте на этот вопрос, прежде чем запускать эксплойт, проводить массовое обновление всех пакетов или объявлять, что сканирование без обнаружения угроз является достаточным. Обоснованный вывод основывается на пяти доказательствах: 1. точные данные о рекомендации и идентификационные данные пакета; 2. установленная и запущенная версия; 3. результат определения диапазона воздействия, полученный консультативным издателем; 4. доступность уязвимой точки входа и любые временные меры по снижению риска; 5. инструмент для проверки результатов рекультивации, а также подтверждение выполнения поставленной задачи. В результате этого соединения получается небольшой набор полезных состояний: absent , unknown , not affected , affected not reachable , exposed , patched unverified , remediation regression или remediated . Кроме того, это исключает два опасных упрощения: рассмотрение наличия пакета как подтверждённого заражения и рассмотрение успешного выполнения команды обновления как восстановления. Сформируйте сопоставление экспозиций, прежде чем выбирать реакцию Каталог уязвимостей полезен для выявления проблем, но он не является инвентаризацией среды выполнения. В уведомлении может быть указан пакет, присутствующий только в файле блокировки, в заброшенной среде, в слое контейнера, который никогда не запускается, или в транзитивной зависимости для разработки. Обратная ситуация еще хуже: клиент MCP может запустить пакет через оболочку или глобальную установку, которые никогда не проверялись при сканировании вашего репозитория. Соберите доказательства с границы среды выполнения, на которой запущен процесс MCP. Не загружайте запросы, аргументы инструментов, токены, абсолютные пути или бизнес данные. Краткий отчет может выглядеть следующим образом: matchStatus должен быть получен из пакетного менеджера, инструмента SBOM или структурированного канала уведомлений, который поддерживает синтаксис версий данной экосистемы. Не следует проводить лексическое сравнение строк версий. Проверенное уведомление GitHub для mcp remote , например, указывает = 0.0.5, < 0.1.16 в качестве уязвимой версии, а 0.1.16 — в качестве первой исправленной версии. В рассмотренном рекомендательном сообщении по @modelcontextprotocol/server filesystem содержит как устаревшую линейку, так и линейку, основанную на датах, причем 2025.7.1 является первым исправленным выпуском для этой линейки. Один написанный вручную компаратор — не лучшее место для нормализации обеих схем. Информация о пакете и версии по прежнему не позволяет однозначно определить доступность. Текущая версия MCP: Рекомендации по обеспечению безопасности показывает, почему настройка имеет значение. В его анализе по принципу «запутавшегося заместителя» перечислены несколько условий, которые должны совпадать, в том числе использование прокси сервером статического идентификатора клиента стороннего поставщика, динамическая регистрация клиента, файл cookie согласия и отсутствие индивидуального согласия для каждого клиента. В тех же рекомендациях и в Спецификация авторизации MCP запретить пропуск токена и обязать сервер ресурсов проверять, был ли для него выдан токен. Эти средства контроля должны стать полями в отчете, относящемся к конкретной уязвимости, а не общим флажком «безопасность включена». Для рекомендации по авторизации необходимо собрать данные о проверке аудитории, сопоставлении перенаправлений, ответственности за получение согласия и поведении прокси. Для рекомендации, касающейся файловой системы, необходимо собрать данные о версии запущенного сервера, разрешенных корневых каталогах, доступных инструментах и точных мерах по устранению уязвимости, которые делают уязвимую точку входа недоступной. В случае рекомендации, касающейся внедрения команд, необходимо собрать данные об оболочке клиента, версии, границе доверия удаленного сервера, а также информацию о том, можно ли вызвать данный маршрут соединения. Компонентом, в котором подтверждено отключение точки входа, является affected not reachable , а не not affected . Это полезное доказательство локализации угрозы, но его действие со временем заканчивается. Зафиксируйте ответственное лицо и срок внедрения исправления, поскольку изменение конфигурации, откат развертывания или подключение нового клиента могут привести к тому, что путь снова станет доступным. Запустите классификатор без контента, а не эксплойт Для обработки инцидента не требуется наличие вредоносного кода. Приведенное ниже правило принятия решений является намеренно консервативным: Названия штатов определяют следующее решение: Штат Что подтверждают факты Ограниченное следующее действие absent Указанный компонент отсутствует на проверяемой границе выполнения Зафиксировать объем запасов и закрыть данные для данной границы unknown Отсутствуют или противоречат друг другу данные об идентификаторе, версии, соответствии рекомендациям или доступности Сохранить неопределённость; заполнить первое пустое поле not affected Установленный компонент находится за пределами диапазона, на который распространяется проблема издателя Сохраняйте исходный текст и свежесть; не делайте выводов о защите на основании схожего названия пакета affected not reachable Уязвимый код существует, но указанная точка входа заблокирована проверенным механизмом локализации Сохранить локализацию, назначить ответственного за исправление и установить срок действия exposed Версия, на которую это влияет, и доступная точка входа совпадают Ограничить доступ, отозвать ненужные полномочия и установить исправления patched unverified Версия вышла за пределы диапазона, но функциональные данные являются неполными Запустите тестовую проверку с помощью инструмента «Canary» и убедитесь, что результат соответствует ожидаемому remediation regression Исправление или ограничительная мера привела к сбою необходимого инструмента или результата Ограничьте распространение рискованного пути; восстановите совместимость или используйте проверенный вариант отката remediated Версия, безопасное поведение инструмента и ожидаемый результат — все соответствуют требованиям Контролируйте срок годности и оформляйте сделку с помощью квитанции о получении Я проверил это правило на восьми примерах без контента — по одному для каждого состояния. Все восемь соответствовали ожидаемому результату. Наиболее ценным является «неудобный» случай: @modelcontextprotocol/server filesystem присутствует в исправленной версии, указанной в рекомендации, но проверка инструментом «safe» для него завершается с ошибкой. Классификатор возвращает remediation regression , а не remediated . Эта граница важна, поскольку работы по обеспечению безопасности могут привести к инциденту, связанному с работоспособностью агента. Обновление зависимостей может изменить команду запуска, схему возможностей, разрешенный корневой каталог, поток OAuth или совместимость с клиентами. Уязвимый код может быть удален, но при этом необходимые функции агента по прежнему будут работать некорректно. Этот отчет имеет ограничения. Он не доказывает, что неизвестный эксплойт не может затронуть данный компонент. Он не заменяет результаты криминалистической экспертизы в случае подозрения о взломе. Кроме того, его достоверность зависит от точной идентификации пакета и актуальных данных из рекомендаций; если данные из двух источников расходятся, следует вернуть код unknown и сохранить обе ссылки. Запись NVD для CVE 2025 6514, например, содержит дополнительную запись с датой, касающуюся проблемы с внедрением команд mcp remote , однако диапазон пакетов по прежнему должен быть привязан к конкретному проверенному рекомендательному сообщению, используемому вашим модулем сопоставления. Патч в последовательности, сохраняющей здоровье агента Для мер по локализации и ликвидации последствий требуются отдельные разрешения, поскольку радиусы их взрывной волны различаются. Практическая последовательность действий следующая: 1. Зафиксировать идентификационные данные. Зафиксировать идентификатор уведомления, пакет, запущенную версию, владельца клиента или сервера, а также время фиксации. 2. Содержит указанный путь. Отключите уязвимый сервер, удаленное соединение, инструмент или маршрут авторизации, внеся минимально возможное обратимое изменение. 3. Ограничить права доступа. Отменить ненужные учетные данные и разрешения, связанные с данным компонентом. Производить ротацию секрета только в тех случаях, когда это требуется в связи с фактами утечки или в соответствии с политикой; ротация может привести к уничтожению полезных доказательств и вызвать несвязанные с этим сбои в работе. 4. Установите исправление, поддерживаемое издателем. Используйте указанную исправленную версию, а не произвольную последнюю версию, и сохраните результат, полученный с помощью менеджера пакетов. 5. Перезапустите реального владельца. Обновления файла блокировки или тега образа недостаточно, если давно запущенный клиент агент по прежнему владеет старым процессом. 6. Проведите тестирование инструмента в безопасном режиме. Используйте синтетическую цель с минимальными привилегиями. Не запускайте эксплойт повторно и не настраивайте «канарейку» на производственные данные. 7. Проверьте конечный результат. Убедитесь, что файл, билет, запись, сообщение или иной ожидаемый результат существует и является правильным. 8. Следите за окном стабильности. Убедитесь, что компонент остается доступным в ожидаемые моменты времени, не попадает повторно в уязвимый диапазон и не выходит из строя неоднократно после установки исправления. Не следует путать отчет об инструменте с подтверждением результата. Инструмент файловой системы может вернуть статус «успешно», даже если запись была выполнена в неправильный разрешенный корень. Инструмент обработки заявок может принять запрос, хотя запись впоследствии будет отклонена. Транспорт MCP может оставаться в рабочем состоянии, даже если результат работы агента отсутствует. Первое подтверждение доказывает, что отремонтированная функция может безопасно выполняться; второе — что результат работы пользователя действительно поступил. Закрывайте инцидент только в том случае, если все наиболее веские имеющиеся доказательства указывают на следующее: рекомендация больше не соответствует запущенному компоненту, ранее уязвимый путь находится под контролем, тест «безопасного канарейки» прошел успешно и достигнут ожидаемый результат. Если какое либо поле содержит устаревшую или противоречивую информацию, сохраняйте состояние явно, а не помечайте его зеленым цветом. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Направление развития этого продукта — создание «уровня мониторинга работоспособности» для существующих сред выполнения агентов: выявление конкретных доказательств, различение состояний «работает», «ожидает» и «завис», обеспечение участия человека на этапе принятия решений и проверка результатов после вмешательства. Текущая публичная версия представляет собой демонстрационную версию в рамках раннего доступа, а не готовый сканер MCP, адаптер мониторинга или механизм автоматического восстановления.