Традиционные модели безопасности работали по циклу: сканирование, сортировка, устранение через заявки. Ответственность была неявной. Разработка на основе ИИ меняет это, предоставляя контекст. ИИ-сортировка переопределяет роль команд безопасности, смещая фокус с ручной работы на управление качеством решений системы. — csoonline.com
Традиционно операционные модели корпоративной безопасности работали по фиксированному и регулярному циклу: результаты сканирования выявляли проблемы, команды безопасности сортировали их, а устранение происходило через рабочие процессы на основе заявок. Это было своего рода стандартной операционной процедурой; ответственность существовала, но часто была неявной и фрагментированной. Устранение проблем перемещалось между инструментами, командами и передачами, а не было встроено в саму систему. Результат? Ваш продукт уже был запущен, команды безопасности подняли тревогу и перешли к выявлению рисков в следующем крупном проекте, но устранение отставало, а команды реагирования на инциденты продолжали заниматься MSIs (Medium Severity Issues, проблемы средней степени критичности).
Эта модель во многом держалась на том, что скорость принятия решений по устранению иногда приносилась в жертву инновациям, требующим быстрого выявления сбоев и быстрого внедрения изменений. Структура покрытия, основанная только на ручных проверках, ограниченных обещанным к выпуску кодом, периодической сортировке отчетов сканеров и отложенной приоритизации, была достаточной, когда разработка программного обеспечения шла размеренными темпами.
Разработка продуктов на основе ИИ (AI-native product development) коренным образом изменила это равновесие.
Внедрение сортировки безопасности с помощью ИИ на основе больших языковых моделей (LLM) помогает ускорить обнаружение, сортировку и приоритизацию этих уязвимостей, устраняя задержку между выявлением проблем и принятием решений. Уязвимости больше не поступают в виде набора выходных данных сканирования, ожидающих в очереди, пока их кто-то подхватит и отсортирует без какого-либо метаданных. Они поступают с контекстом: индикаторы возможности эксплуатации (как внешние, так и специфичные для вашего приложения/платформы), метаданные о владельце и сигналы о влиянии на бизнес.
Этот сдвиг не просто увеличивает скорость сортировки. Он вынуждает команды переосмыслить, кто несет ответственность за уязвимости, кто решает, что именно должно быть исправлено, и как быстро принимаются эти решения. Существующие операционные модели не могут угнаться за этим — они не были созданы для обработки проблем, поступающих с полной контекстуализацией и требующих немедленных действий.
Ответственность была неявной, пока ИИ не сделал ее видимой
Традиционное управление уязвимостями в значительной степени полагалось на абстракцию. Сканеры передавали результаты на панели мониторинга, которые генерировали заявки, накапливавшиеся в бэклогах. Команды рассматривали сам рабочий процесс как назначение ответственности, но никто заранее явно не указывал ответственную команду или роль.
На практике это создавало путаницу. Когда уязвимая зависимость обнаруживалась в нескольких сервисах или когда степень критичности менялась на основе новых данных, выяснение «кто за это отвечает?» становилось процедурным упражнением, а не тем, что система знала по умолчанию.
Платформы на основе ИИ меняют эту динамику. Сопоставляя результаты на протяжении всего жизненного цикла, от обнаружения до устранения, они выявляют владельца на момент обнаружения. Когда уязвимость напрямую сопоставляется с репозиторием, конвейером и ответственной командой, ответственность перестает быть вопросом маршрутизации заявок. Она встраивается в архитектуру системы.
То, что когда-то было проблемой координации, становится вопросом управления: если ответственность становится ясной в тот момент, когда что-то обнаружено, кто несет ответственность за принятие мер?
Сортировка с помощью ИИ переопределяет роль команды безопасности
Поскольку системы ИИ все чаще сортируют уязвимости с высокой степенью достоверности, команды безопасности сталкиваются с тонким, но значительным сдвигом в обязанностях.
Люди больше не спорят о том, может ли ИИ уменьшить информационный шум. Он это демонстрируемо делает. Более сложный вопрос заключается в том, какие обязанности остаются за командами безопасности после автоматизации сортировки. Несут ли они ответственность за обработку отдельных обнаружений, обеспечение точности модели или управление самой системой принятия решений?
На практике эффективные программы приходят к гибридной модели. Пусть ИИ сортирует рутинные оповещения и помечает элементы с высоким риском. Аналитики расследуют необычные сигналы, настраивают правила принятия решений и утверждают исключения. Метрики соответствующим образом смещаются. Вместо подсчета дефектов команды теперь отслеживают частоту ложных срабатываний, уверенность в покрытии и то, как со временем меняется производительность модели.
Этот переход меняет способ использования экспертизы в области безопасности. Команды тратят меньше времени на ручную сортировку и больше времени на обеспечение качества решений, принимаемых системой.
Почему «человек в контуре» по-прежнему важен в масштабе
Полностью автономное тестирование безопасности часто преподносится как конечная цель, но на практике оно создает новые пробелы в ответственности. Когда системы принимают решения без определенных контрольных точек для человека, ответственность становится размытой, особенно когда эти решения влияют на производственные среды.
Некоторые из наиболее эффективных программ безопасности на основе ИИ намеренно сохраняют точки принятия решений человеком. Не как узкие места, а как контрольные точки ответственности. Автоматизация ускоряет обнаружение и обогащение данных. Люди сохраняют полномочия в отношении результатов с высокими ставками.
Полезная аналогия существует в более широких исследованиях безопасности ИИ. Например, проект Google «Big Sleep» доказал, что ИИ может выявлять уязвимости, которые можно использовать, раньше, чем это сделают злоумышленники. Но ему все еще требовался надзор человека для проверки результатов и принятия соответствующих мер.
В корпоративной безопасности применяется тот же принцип. Автоматизация масштабирует понимание. Люди несут ответственность за последствия.
Функции ИИ создают новую границу ответственности
По мере того как организации добавляют генеративный ИИ в свои продукты, возникает новый класс вопросов безопасности. Внедрение подсказок (prompt injection), утечка обучающих данных и манипулирование моделями не вписываются в существующие категории безопасности.
Это создает новую границу ответственности. Команды по безопасности продуктов теперь должны тесно сотрудничать с командами инженеров по ИИ и машинному обучению. Необходимо решить, кто будет отвечать за безопасность кода, поведение модели и предотвращение неправомерного использования.
Рассмотрение функций ИИ как самостоятельных поверхностей риска, а не как расширений существующих, требует ясности. Назначьте четких владельцев сейчас, чтобы эти риски были выявлены до того, как они превратятся в инциденты или замечания аудита.
ИИ не просто ускоряет рабочие процессы безопасности. Он выявляет места, где ответственность, владение и принятие решений изначально никогда не были четко определены. Организации, которые рассматривают ИИ как мультипликатор силы без пересмотра своих операционных моделей, могут двигаться быстрее, но не обязательно безопаснее. Успех ждет те команды, которые перестроят процессы, ориентируясь на явное владение, управляемые решения и ответственность человека в тех точках, где последствия имеют наибольшее значение.
Эта статья публикуется в рамках сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Apoorv Mehta