КИБЕРБЕЗОПАСНОСТЬ

Безопасность ИИ требует мышления атакующего

Five Eyes в июне предупредил: передовые ИИ-модели меняют кибератаки и защиту. Командам безопасности придется действовать первыми.

✍️ Редакция iTech News | 02.10.2026 | ⏱ 4 мин | Источник: The New Stack
🔐

Альянс Five Eyes в июне предупредил: передовые ИИ-модели способны резко изменить и атаки, и защиту в киберпространстве. Для русскоязычных IT-команд это означает простую, неприятную вещь: безопасность ИИ больше нельзя строить в режиме ожидания алерта, патча или квартального аудита.

Об этом пишет The New Stack в колонке Чаима Мазала, CISO GitLab. Его тезис короткий: в безопасности ИИ не остается места чисто оборонительному мышлению. Если атакующие используют модели для разведки инфраструктуры, поиска слабых мест и генерации сценариев атак, защитникам придется делать то же самое раньше них.

Five Eyes — разведывательный альянс США, Великобритании, Канады, Австралии и Новой Зеландии — редко выпускает совместные предупреждения такого типа. В июньском заявлении он указал, что frontier-модели могут превзойти текущие ожидания индустрии и поменять баланс сил в offensive и defensive security. В переводе с дипломатического на инженерный: порог входа для атакующих снижается, скорость перебора гипотез растет, а старые процессы безопасности начинают скрипеть громче обычного.

Мазал отдельно подчеркивает, что проблема не теоретическая. Атакующие уже умеют обходить защитные ограничения моделей, а значит, наивная ставка на встроенные safeguards выглядит слишком оптимистично. Если раньше сложная атака требовала редкой экспертизы, времени и ручной работы, то теперь часть этой нагрузки можно переложить на ИИ-инструменты. Не целиком, без магии, но достаточно, чтобы SOC, AppSec и GRC-команды почувствовали разницу.

Главная претензия к классической обороне — пассивность. Модель «подождем логов, инцидента или отчета сканера» плохо работает, когда противник автоматизирует разведку и тестирование гипотез. По логике Мазала, защитная команда должна первой просканировать собственную среду так, как это сделал бы атакующий: инвентаризировать активы, искать пробелы, проверять цепочки доступа, моделировать злоупотребления и быстро закрывать найденное.

Отсюда его разделение на два типа мышления. Люди, пришедшие в CISO-роли из compliance, risk или классического IT, часто мыслят через контроль, регламенты и реакцию на события. Инженерный бэкграунд чаще толкает к другой привычке: не ждать сигнала, а разбирать систему на части, искать неожиданные состояния и проверять, где она ведет себя не так, как обещано в документации. Это не романтизация хакеров, а полезная профессиональная паранойя.

Для разработчиков здесь есть практический вывод. Безопасность ИИ не должна превращаться в отдельный театр теней рядом с SDLC. Если команда уже внедряет AI-агентов в разработку, тестирование или поддержку, ей нужны такие же инженерные контуры для риска: узкие задачи, понятные права, проверяемые результаты, журналирование действий и возможность отката. Агент, которому дали абстрактную цель «найди проблемы безопасности», быстро начнет производить шум. Агент, которому дали конкретный контекст и ограниченную задачу, полезнее и менее опасен.

Мазал предлагает две опоры. Первая — нейтральность к моделям и поставщикам. Не стоит зашивать security-процессы в одну модель, один API или одного вендора: лучший инструмент через полгода может оказаться не лучшим, а требования по хранению данных и защите IP иногда потребуют self-hosted или изолированных развертываний. Вторая — жесткий scope для агентных задач. Чем уже задача и богаче контекст, тем выше шанс получить действие, а не красивый отчет с уверенной ерундой.

Для бизнеса это звучит менее эффектно, чем обещания «автономного SOC», зато ближе к реальности. Речь не о том, чтобы завтра заменить аналитиков ботами. Речь о том, чтобы перестроить безопасность вокруг измеримых результатов: риск найден, приоритизирован, исправлен, подтвержден и объяснен владельцу сервиса. В такой схеме AI-агенты становятся не волшебной кнопкой, а ускорителем для скучных, повторяемых и болезненно важных операций.

Есть и редакционная оговорка: текст The New Stack — авторская колонка CISO GitLab, а не независимое исследование с новой статистикой по атакам. Поэтому тезисы стоит читать как позицию практика и поставщика DevSecOps-платформы. Но сама постановка вопроса выглядит точной: пока защитники спорят, какую модель безопаснее подключить к пайплайну, атакующим достаточно понять, где у компании забытый сервис, слабая зависимость или доступ, который никто не пересматривал с прошлого реорга.

Следующий этап безопасности ИИ, похоже, будет не про красивые политики использования LLM, а про способность команд действовать на скорости противника. Победит не тот, кто громче запретит инструменты, а тот, кто первым научится проверять собственную инфраструктуру чужими глазами — и исправлять найденное без недель согласований.

Поделиться: Telegram X LinkedIn