Моделирование угроз помогает команде понять, как изменение программы может открыть доступ к данным или разрешить постороннему выполнить действие. Для этого участники описывают компоненты системы и обмен данными между ними. Затем отмечают границы доверия — места, где меняется уровень доверия к данным, пользователям или компонентам, — и проверяют, какие угрозы действительно возможны.
В сессиях, где анализ вели инженеры с помощью ИИ, эксперт подтвердил восемь угроз безопасности. Когда анализ готовил ИИ, а люди проверяли его предложения, подтверждение получили пять угроз. В одной из таких сессий эксперт отклонил 11 из 12 предложений ИИ. При этом участники этой сессии сообщили, что отклонили или переписали менее 20% предложений. [1]
В эксперименте сравнивали способы совместной работы людей и ИИ при анализе безопасности. Если человек проверяет готовый ответ, он может замечать другие проблемы, чем при самостоятельном разборе системы. Участников было мало, поэтому по этим результатам нельзя сделать общий вывод о том, какой подход эффективнее.
Инженеры и ИИ по очереди вели анализ безопасности
22 октября 2026 года компания по кибербезопасности Codific опубликовала сравнение двух подходов. Команды разбирали изменения в двух её продуктах: воспроизведение облачных записей в приложении Videolab CVR и запись данных через сервер SAMMY MCP. В каждой команде было три человека. Один продукт команда анализировала под руководством инженеров, другой — с ведущей ролью ИИ. Всего провели четыре сессии по 120 минут. Все предложенные угрозы проверил эксперт по безопасности приложений с опытом более 15 лет. [1]
В первом подходе инженеры сами рисовали схему потоков данных, обсуждали границы доверия и обращались к большой языковой модели за дополнительным мнением. Доступа к исходному коду у ИИ не было. Во втором подходе специальный ИИ-инструмент получал описание системы и исходный код, строил схему и предлагал угрозы. Люди разбирали и проверяли его предложения. Разница в доступных ИИ данных важна для оценки результатов. [1]
Анализ ведут инженеры с помощью ИИ
8 подтверждённых угрозИнженеры описывают устройство системы и просят ИИ найти возможные пробелы.
Предложена 31 угроза
Эксперт подтвердил 26% угроз: 8 из 31, с округлением
6 подтверждённых угроз не нашли в сессиях, где анализ вёл ИИ
Анализ готовит ИИ, люди проверяют
5 подтверждённых угрозИИ строит схему и предлагает угрозы. Участники проверяют эти предложения.
Предложено 25 угроз
Эксперт подтвердил 20% угроз: 5 из 25
3 подтверждённые угрозы не нашли в сессиях, где анализ вели инженеры
Источник — собственный эксперимент Codific, опубликованный 22 октября 2026 года. В подходе под руководством инженеров тоже использовали ИИ: это не сравнение с работой человека без ИИ. Статистически значимых различий между подходами не выявлено.
Результаты зависели от продукта. Для SAMMY MCP доля подтверждённых угроз была выше при ведущей роли ИИ: 31% против 23%. Для Videolab CVR — при ведущей роли инженеров: 40% против 8%. Из одиннадцати разных подтверждённых угроз только две нашли обоими способами. То есть подходы помогали замечать разные угрозы. [1]
Команда приняла предложения, которые эксперт затем отклонил
В сессии по Videolab CVR, где анализ готовил ИИ, эксперт подтвердил только одну угрозу из двенадцати. Однако все три участника сообщили, что отклонили или переписали менее 20% предложений ИИ. По их оценке, содержательность ответов составила в среднем 4,3 балла из 5. Исследователей заинтересовала разница между оценкой участников и результатом экспертной проверки. [1]
Столько предложенных ИИ угроз для Videolab CVR отклонил эксперт.
Такую долю предложений ИИ участники, по их словам, отклонили или переписали. Это их собственная оценка, а не независимо проверенная запись действий.
Участники также отмечали пользу совместного рисования схемы потоков данных. Команде приходилось договариваться, как устроена система и где проходят границы доверия. Схемы ИИ выглядели подробными и аккуратными, но не обязательно помогали сосредоточиться на проверяемом изменении. Совместная работа и общее понимание системы также входят в принципы Threat Modeling Manifesto. [1] [2]
Для проверки нужны понятный порядок работы и подтверждающие данные. Само по себе назначение проверяющего ещё не показывает, насколько внимательно он разобрал ответ ИИ.
Инженеры тоже ошибались: многие неподтверждённые угрозы возникли из-за неверного понимания архитектуры. Поэтому результат нельзя свести к выводу «люди лучше ИИ». Если участники неправильно представляют устройство системы, ошибки возможны и при поиске угроз, и при проверке предложений. [1]
Три шага для проверки анализа безопасности с ИИ
Для рабочего процесса полезен такой вопрос: какие знания и подтверждения нужны проверяющему, чтобы отклонить убедительный, но необоснованный отчёт? Применение этого вопроса за пределами безопасности ПО — вывод Maak.Digital. В эксперименте не измеряли результаты в закупках, инженерной работе или обработке документов.
Описать систему и решить, когда считать угрозу подтверждённой
Команда уточняет, какое изменение рассматривает, на какие данные можно опираться и кто отвечает за окончательные решения.
Попросить ИИ предложить то, что команда могла упустить
ИИ может назвать другие возможные угрозы и слабые места анализа. Каждое предложение сначала рассматривают как гипотезу, которую ещё нужно проверить.
Проверить предложения и записать результаты
Для каждой угрозы нужны подтверждения, связанные с конкретной системой или документом. Полезно учитывать принятые и отклонённые предложения, время на их разбор и расхождения с экспертной оценкой.
Чего нельзя заключить по этому эксперименту. В нём участвовали только две опытные команды самой Codific. Они провели четыре сессии с ограничением по времени и использовали один вариант ИИ-инструмента. Авторы допускают, что могли бы лучше подготовить сам ИИ-инструмент. Обе команды сначала работали под руководством инженеров, поэтому на следующие сессии могли повлиять порядок заданий и усталость. Codific не выявила статистически значимых различий и сообщила, что готовит полную научную статью с описанием методов и данными. [1]
Каждую предложенную ИИ угрозу нужно сверять с устройством программы и подтверждающими данными.
Небольшое исследование Codific ставит вопрос о качестве проверки. Проверяющему нужны знания о системе и доступ к подтверждениям, чтобы замечать ошибки даже в убедительных ответах. Одного этапа согласования в конце работы для этого недостаточно.
Небольшой эксперимент компании с ограничениями метода
Codific — «Human-Led vs AI-Driven Threat Modeling: A Controlled Experiment». Опубликовано 22 октября 2026 года. Описание эксперимента, результатов, отзывов участников и факторов, которые могли повлиять на сравнение.
Threat Modeling Manifesto. Принципы анализа систем и совместной работы над угрозами безопасности. Помогают понять, зачем команде самой рисовать схему и обсуждать устройство программы.
Это независимый разбор эксперимента сторонней компании, подготовленный Maak.Digital. Материал не описывает клиентский проект Maak.Digital или повторение эксперимента Codific для проверки результатов. Исследование не показывает, как такие подходы работают в других отраслях. На момент подготовки материала Codific ещё не опубликовала полную научную статью и исходные данные. Рекомендации в разделе 03 — выводы Maak.Digital, а не измеренные результаты эксперимента. Все числа и результаты исследования приведены по отчёту Codific.