У меня есть сомнение в зрелости любого third-party risk management, который заканчивается после заполнения анкеты поставщиком.

Анкета полезна. Сертификаты полезны. Аудиты тоже нужны.

Но поставщик может корректно ответить на все вопросы в январе, а в феврале:

— потерять учётные данные администратора; — подключить нового субподрядчика; — изменить облачную инфраструктуру; — внедрить внешний AI-сервис; — выпустить скомпрометированное обновление; — оставить атакующему доступ к нескольким заказчикам.

По данным Verizon DBIR 2025, доля подтверждённых утечек с участием третьих сторон выросла с 15% до 30%. (Verizon⁠)

На мой взгляд, проблема не только в зрелости подрядчиков. Проблема в объёме доверия, которое компании им предоставляют.

Интегратор получает постоянный VPN-доступ. SaaS — корпоративные документы. Библиотека — место внутри десятков продуктов. CI/CD-компонент — возможность влиять на сборку. AI-агент — доступ к данным и инструментам.

После этого организация пытается компенсировать системный риск ежегодной проверкой документации.

Я считаю, что правильный вопрос к поставщику звучит не так: «Докажите, что вас не взломают».

Это невозможно доказать.

Правильный вопрос должен быть адресован прежде всего самой компании:

«Что мы потеряем, если поставщика уже взломали, и насколько быстро сможем ограничить последствия?»

Отсюда начинается более зрелая модель:

1. Классифицировать поставщиков по возможному ущербу, а не по стоимости договора. 2. Понимать их реальные доступы, данные и место в бизнес-процессах. 3. Ограничивать доверие даже для проверенных партнёров. 4. Мониторить внешние учётные записи и действия внутри собственной среды. 5. Знать критические open source-, SaaS- и AI-зависимости. 6. Иметь сценарий быстрого отключения интеграции. 7. Проверять, сможет ли бизнес продолжить работу без ключевого провайдера.

Особенно важно пересмотреть подход из-за AI.

Внешняя модель — это не один поставщик. За ней находятся облако, API, библиотеки, датасеты, векторные хранилища, плагины и субпроцессоры.

А AI-агент уже может не просто рекомендовать, а выполнять действия. Если он получает вредоносную инструкцию через документ, веб-страницу или сообщение от внешней стороны, риск цепочки поставок соединяется с prompt injection и excessive agency.

Моя позиция проста:

Third-party risk — это не оценка добросовестности поставщика. Это управление blast radius на случай его компрометации.

Сильная функция ИБ не строит защиту на предположении, что партнёры всегда останутся безопасными. Она заранее проектирует ограничения, наблюдаемость и устойчивость. Как вы считаете: кто должен быть владельцем third-party risk — ИБ, закупки, бизнес-заказчик или это всегда совместная ответственность?