Alert fatigue в AI-кодинге: причины, цена и практический план

Почему alert fatigue убивает защиту быстрее, чем атакующий, и что с этим делать

Введение: когда защита мешает защите

В 2013 году компания Target стала жертвой одного из крупнейших ритейл-взломов в американской истории: данные более 40 миллионов платёжных карт были похищены. При этом инструменты безопасности среагировали правильно. FireEye поднимал тревогу минимум пять раз. Аналитики SOC видели алерты. Они их проигнорировали — потому что к тому времени утонули в потоке похожих уведомлений, большинство из которых неделями оказывались ложными [1].

Этот случай не исключение. Он — структурное следствие того, как устроена современная безопасность: инструменты кричат постоянно, люди перестают слышать.

В эпоху AI-кодинга проблема только обострилась. Команды пишут больше кода быстрее. PR'ов стало больше. Каждый PR генерирует больше находок от сканеров. И всё это ложится на тех же людей, которые уже не справлялись с объёмом до внедрения Copilot.

Эта статья — для CTO, Tech Lead, AppSec и DevSecOps-инженеров, которые хотят разобраться: что такое alert fatigue, почему стандартные подходы не работают и как выстроить систему, где важное действительно получает внимание.

Часть 1. Что такое alert fatigue и почему это не просто «много уведомлений»

Alert fatigue (усталость от предупреждений) — это состояние когнитивной десенсибилизации, которое наступает, когда специалист по безопасности длительное время получает поток алертов, значительная часть которых оказывается ложными срабатываниями или малозначимыми событиями [2].

Важно понять: это не операционная проблема типа «надо нанять ещё аналитиков». Это психофизиологический феномен. Термин пришёл из медицины — из исследований больниц, где медсёстры перестают реагировать на сигналы мониторов пациентов, потому что 95% из них оказываются ложными [3]. Мозг адаптируется к постоянному раздражителю и начинает его подавлять.

В кибербезопасности механизм тот же. Когда аналитик видит сотый «критический» алерт за смену, который снова оказывается false positive — реакция угасает. Следующий алерт — уже реальная угроза — попадает в тот же когнитивный шаблон «скорее всего, снова шум».

Масштаб проблемы в цифрах

Данные 2025–2026 годов рисуют неприятную картину:

• В среднем организация получает около 2992 предупреждений безопасности в сутки, при этом в крупных компаниях (от 20 000 сотрудников) этот показатель превышает 3000 [3].
• 63% алертов остаются нерассмотренными [3].
• 73% команд безопасности называют ложные срабатывания главной проблемой детектирования [3].
• 76% организаций относят alert fatigue к приоритетным проблемам SOC [3].
• Почти 90% SOC переполнены бэклогом и false positives, более 80% аналитиков постоянно ощущают, что не успевают [2].

По данным Verizon DBIR 2025, в 96% взломов именно атакующие, а не команда безопасности, первыми сообщают об инциденте [2]. То есть большинство детектирований происходит post factum — и alert fatigue напрямую этому способствует.

Это не только SOC-проблема

Ошибочно думать, что alert fatigue касается только SOC-аналитиков. В DevSecOps-командах та же картина, только со своей спецификой:

• SAST-сканеры выдают ложные срабатывания в диапазоне от 36% до свыше 80% в зависимости от инструмента и настроек [4].
• По данным 2024 SOC Survey, около 53% алертов от security-инструментов в разработке — ложные [4].
• Разработчики, получающие 1000 находок за спринт с 70% false positive rate, тратят суммарно более 58 часов на разбор ложных тревог — это больше полной рабочей недели [5].
• В итоге они вырабатывают «alert blindness»: автоматически игнорируют предупреждения безопасности, не вникая [5].

По данным State of ASPM 2024, средняя команда разработки использует 49 различных инструментов. Каждый генерирует свой поток уведомлений [6]. Агрегировать и приоритизировать этот шум вручную не реально.

Часть 2. Четыре корневые причины, а не одна

Исследование ACM Computing Surveys по alert fatigue в SOC выделяет четыре ключевые причины [1]. Для DevSecOps-контекста их стоит переформулировать:

Причина 1. Слишком много инструментов, каждый кричит по-своему

Добавление нового сканера в CI/CD-пайплайн редко воспринимается как риск. На практике каждый новый инструмент — новый поток алертов, новый формат находок, новая логика severity. Без единой модели данных аналитик вынужден переключаться между контекстами. Через год после старта DevSecOps у большинства компаний появляется 5–10 security-инструментов и полная потеря управляемости [7].

Причина 2. Нет контекста — нет приоритета

Большинство инструментов статического анализа работают по принципу «обнаружил паттерн — поднял флаг». Они не знают: открыт ли сервис в интернет; находятся ли рядом чувствительные данные; есть ли компенсирующий контроль на уровне сети или IAM; реальна ли эксплуатация в вашей конкретной среде. Результат — абстрактная критичность, не привязанная к реальному риску [8].

Причина 3. CVSS-оценка как единственный критерий приоритизации

Традиционный подход: отсортировать по CVSS, начать с Critical. Проблема в том, что CVSS измеряет теоретическую тяжесть, а не реальную эксплуатируемость в вашей среде. В Q1 2025 года 28% эксплуатируемых уязвимостей имели лишь Medium CVSS base score [9]. Организации, ориентирующиеся только на CVSS, систематически депrioritизируют более четверти угроз, которые реально используют атакующие [9].

Причина 4. AI-кодинг увеличивает объём, но не качество ревью

По данным исследования CodeRabbit на основе 470 open-source PR (декабрь 2025), AI-ассистированные pull requests содержат в среднем в 1,7 раза больше дефектов, чем написанные людьми [10]. Critical issues выше на 40%, Major — на 70%. Security findings — в 1,57 раза больше. Конкретные паттерны: XSS-уязвимости встречаются в 2,74 раза чаще, небезопасная десериализация — в 1,82 раза, ненадлежащее обращение с паролями — вдвое чаще [11].

При этом объём PR вырос: по данным Cortex Engineering Benchmark 2026, PR на разработчика увеличилось на 20% год к году, а incidents per pull request — на 23,5% [12]. Инструменты безопасности видят больше кода с большим числом находок. Ревьюеры не успевают разбирать всё.

Часть 3. Чем платят за alert fatigue

Цена усталости от предупреждений — не абстрактный «риск». Это измеримые потери.

Финансовые потери

• Средняя стоимость утечки данных в 2025 году составила 4,44 млн долларов (IBM 2025) [3].
• Ручной триаж алертов обходится в среднем в 3,3 млрд долларов в год только в США [3].
• Организации с сильно фрагментированным SOC тратят на операционный труд на 40% больше, чем компании с консолидированным инструментарием [3].

Кадровые потери

Alert fatigue ведёт к выгоранию. Выгорание ведёт к увольнению. По данным SANS 2025 SOC Survey, 70% аналитиков с опытом до 5 лет уходят в течение трёх лет [2]. Средний оборот кадров в security-командах в США — порядка 20% в год [13]. В условиях глобальной нехватки 4,8 млн специалистов по кибербезопасности (ISC² 2025) потеря каждого опытного сотрудника — критическая проблема [3].

Кейс Target — предупреждение, которому не вняли

Атака на Target в 2013 году остаётся хрестоматийным примером. Инструменты сработали корректно, уведомления были отправлены. Но команда, погружённая в рутинный поток ложных тревог, не смогла выделить реальный сигнал. Малварь работала почти две недели до того, как вмешались правоохранители [1].

Схожая динамика прослеживается в инциденте с 3CX (2023): пользователи привыкли к тому, что их endpoint-защита неверно маркирует легитимный 3CX как угрозу. Когда программа реально оказалась скомпрометирована в рамках supply chain атаки, алерты снова проигнорировали — как очередное ложное срабатывание [13].

Часть 4. CVSS недостаточно: как правильно приоритизировать

Если CVSS не работает как единственный инструмент приоритизации, что использовать вместо?

Ответ исследований 2025–2026 годов — контекстная, риск-ориентированная приоритизация. Не замена CVSS, а надстройка над ней.

Три сигнала, которые нужно добавить к CVSS

EPSS (Exploit Prediction Scoring System) — вероятность реальной эксплуатации в ближайшие 30 дней на основе данных об угрозах в дикой природе. Помогает отфильтровать теоретически тяжёлые, но реально не эксплуатируемые уязвимости [9].

CISA KEV (Known Exploited Vulnerabilities catalog) — официальный каталог CISA с уязвимостями, для которых зафиксированы реальные атаки. Если уязвимость есть в KEV — это автоматически высокий приоритет вне зависимости от CVSS [9].

Критичность актива и контекст среды — открыт ли сервис в интернет; есть ли рядом чувствительные данные; работает ли уязвимый пакет в runtime или только установлен. По данным исследования, переход к контекстной приоритизации позволяет сократить количество критических находок с 569 354 до 11 836 по одной организации [8]. Это не потеря данных — это фокус на реально важном.

Практический подход: composite score, комбинирующий CVSS (максимально возможный ущерб), EPSS (вероятность эксплуатации) и критичность актива (бизнес-контекст). Такая формула дефенсибельна перед аудиторами и руководством, и при этом отражает реальный операционный риск [9].

Часть 5. Специфика AI-кодинга: новый класс шума

С массовым внедрением AI-инструментов разработки появился отдельный вектор alert fatigue — более коварный, чем традиционный.

Почему AI-код генерирует больше шума от сканеров

LLM-инструменты производят синтаксически корректный код, который плохо понимает контекст конкретной системы. Традиционные SAST-сканеры работают на шаблонном сопоставлении: они видят потенциально опасный паттерн и поднимают флаг. LLM-код содержит много новых вариаций классических ошибок, которые инструменты маркируют как находки — часть из них реальные, часть — ложные срабатывания, часть — в серой зоне [14].

Результат: статический сканер флагует 37 «критических» проблем в PR, написанном за обеденный перерыв. Большинство — шум. Несколько — реальны. Команда учится кликать «dismiss» — и пропускает настоящую угрозу [14].

Что показывают данные

По данным Veracode (2025), 45% AI-генерируемого кода содержит минимум одну уязвимость из OWASP Top 10 [12]. В 2025 году в OWASP Top 10 обновилась структура рисков: Supply Chain Failures переместились на 3-е место, Security Misconfiguration — на 2-е, появилась новая категория «Mishandling of Exceptional Conditions» [15] — именно то, что AI-инструменты воспроизводят системно (пустые catch-блоки, fail-open поведение).

Реальный инцидент из практики: в августе 2025 года AI-сгенерированный PR для NX build tool внёс уязвимость command injection — заголовки PR использовались в shell-командах без санитизации. Атакующий получил NPM-токены публикации, что повлекло компрометацию обновления для более чем 1400 разработчиков [16].

Парадокс скорости

При том что PR на разработчика выросло на 20%, incidents per pull request увеличилось на 23,5%, а change failure rates — примерно на 30% [12]. AI ускорил производство кода, но не ускорил его понимание. Ревью не масштабировалось вместе со скоростью.

Это именно тот момент, где ручной security-review перестаёт справляться, а автоматический — без должной настройки — лишь добавляет шум поверх шума.

Часть 6. Что реально работает: практический фреймворк

Победить alert fatigue не значит заглушить все предупреждения. Это значит перейти от шума к сигналу. Вот конкретный операционный план.

Шаг 1. Аудит перед добавлением нового инструмента

Прежде чем добавлять ещё один сканер — посчитайте, сколько алертов в сутки генерирует ваш текущий стек и какой процент из них закрывается реальными действиями. Если закрывается меньше 20% — проблема не в количестве инструментов, а в качестве сигнала.

Рекомендуемые метрики для начального аудита:

1. Общее количество алертов в сутки по каждому инструменту.
2. Доля алертов, по которым предприняты действия.
3. Время от алерта до реакции (MTTD/MTTR).
4. Доля подтверждённых false positives (можно оценить выборочно).

Шаг 2. Инкрементальное, а не полное сканирование

Запуск SAST по всему репозиторию при каждом коммите — гарантированный способ утонуть в результатах. Эффективный подход: анализировать только конкретное изменение и связанный контекст [7]. Это снижает шум и ускоряет ревью.

В реальном DevSecOps-пайплайне рекомендуется:

1. SCA (анализ зависимостей) — на каждый PR, блокировать только критические CVE из активно эксплуатируемых.
2. SAST — инкрементально по диффу, с предварительной настройкой под ваши фреймворки и библиотеки.
3. Secret scanning — на каждый коммит, автоматически.
4. Полное сканирование — по расписанию или перед major release.

Шаг 3. Контекстная приоритизация, а не сортировка по CVSS

Для каждой находки добавляйте контекстные вопросы:

1. Является ли этот актив интернет-доступным?
2. Есть ли рядом чувствительные данные или привилегированные доступы?
3. Есть ли уязвимость в CISA KEV или активно эксплуатируется по EPSS?
4. Реально ли уязвимый компонент загружается в runtime?

Даже простая четырёхфакторная модель резко сокращает количество «критического», требующего немедленного внимания.

Шаг 4. Разные gate для разных ситуаций

Не все предупреждения требуют одинакового ответа. Структурируйте gates:

• Жёсткая блокировка (merge не пройдёт): критические CVE в активно эксплуатируемых зависимостях; hardcoded secrets; критические уязвимости в интернет-доступных эндпоинтах.
• Предупреждение с обязательным ревью: высокая severity без активной эксплуатации; новые внешние зависимости без audit.
• Информационный сигнал: medium/low severity; известные false positives данного проекта; технический долг без срочного риска.

Критически важно документировать логику каждого gate и давать разработчику конкретный следующий шаг — не «посмотри отчёт», а «измени X или объясни, почему можно принять».

Шаг 5. Tuning как постоянный процесс

Настройка инструментов — не разовое действие при внедрении. Это непрерывная работа. Рекомендуется:

1. Собирать обратную связь от разработчиков: какие алерты они считают бесполезными.
2. Отслеживать метрику false positive rate по каждому инструменту и правилу.
3. Проводить регулярный ретроспективный анализ: что из найденного оказалось реальным.
4. Добавлять кастомные исключения для ваших паттернов (например, внутренние функции санитизации, которые SAST не знает) [4].

Шаг 6. Security Champion как мост между командами

Российская практика DevSecOps показывает: одна из главных проблем — разрыв между security-командой и разработчиками [7]. Security Champion в каждой продуктовой команде решает это структурно. Это не «безопасник, который умеет кодить» — это разработчик, обученный думать о безопасности и способный объяснить коллегам, почему конкретный алерт важен [17].

Часть 7. Специфика AI-кода: что проверять дополнительно

В контексте AI-ассистированной разработки alert fatigue имеет дополнительное измерение. Потому что ревьюер устаёт не только от предупреждений — но и от самого объёма кода, который нужно просмотреть.

Несколько операционных выводов из актуальных исследований:

Для AI-генерируемых PR нужно дольше смотреть на логику и граничные случаи — AI-код часто синтаксически корректен, но ломается на нестандартных вводах и concurrency-сценариях [12].

Зависимости в AI-коде — особый риск. LLM иногда галлюцинирует несуществующие пакеты (slopsquatting), предлагает устаревшие версии или библиотеки с известными уязвимостями. Каждая новая зависимость требует проверки: существует ли пакет реально, поддерживается ли, нет ли в нём известных CVE [16].

Hardcoded credentials появляются в AI-коде вдвое чаще, чем в человеческом. Secret scanning на уровне коммита — не опция, а обязательная проверка [10].

Конфигурационные файлы и CI/CD-скрипты, написанные AI, читают хуже всего. Именно там часто скрываются широкий CORS, отключённые проверки, debug-настройки, оставленные «на потом».

Перед релизом нужен сфокусированный ответ на вопрос: «что из найденного реально блокирует выпуск прямо сейчас?» — не длинный отчёт об историческом техдолге, а конкретный список критического для данного релиза. Именно так устроен подход HighVibe: не тотальное сканирование репозитория без повода, а анализ конкретного изменения и его контекста, с коротким и понятным сигналом для команды вместо многостраничного отчёта.

Часть 8. Типичные ошибки и как их избежать

Ошибка 1: «Добавим ещё один сканер, будет безопаснее»

Каждый новый инструмент без интеграции с общим workflow и без настройки — это новый источник шума. Прежде чем добавлять инструмент, ответьте: кто будет разбирать его алерты, в какое время, по какому процессу.

Ошибка 2: «Заблокируем merge по любому критическому алерту»

Избыточный gate ведёт к тому, что разработчики начинают воспринимать security как препятствие, а не союзника. Это разрушает культуру. Жёсткий gate должен быть узким и точным — только там, где риск реален и неприемлем.

Ошибка 3: «Решим alert fatigue с помощью AI-автоматизации»

AI-триаж алертов — полезный инструмент, но не панацея. Gartner предупреждает: AI-enabled SOC не сокращает автоматически потребность в людях, он меняет требования к навыкам [3]. Автоматизация tier-1 триажа освобождает время, но не заменяет опытного специалиста, принимающего решения по эскалированным сигналам.

Ошибка 4: «Мы настроили инструменты при внедрении — значит, всё ок»

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

Ошибка 5: «Длинный отчёт = полная безопасность»

Пятисотстрочный security-отчёт перед релизом — не помощь команде, а дополнительный источник усталости. Нужна чёткая структура: что критично для этого релиза, что важно, но можно зафиксировать в backlog, что можно принять как известный риск. Формат «зелёный/жёлтый/красный» по каждому изменению работает лучше, чем полный список findings.

Часть 9. Будущее: меньше шума, больше контекста

Тренды 2025–2026 годов указывают на несколько направлений развития:

Контекстно-ориентированное сканирование станет стандартом. Уже сейчас ведущие платформы строят security-граф, соединяющий находки с реальными активами, путями атак, данными и идентичностями — а не просто выдают список CVE с оценками [8].

LLM-ассистированный триаж алертов развивается активно. Исследование показывает, что LLM в качестве слоя триажа между SAST и аналитиком снижает долю false positives и повышает доверие к инструменту [18]. Однако качество сильно зависит от того, насколько хорошо модель понимает контекст конкретного кодовой базы.

Интеграция безопасности в момент генерации кода — следующий рубеж. Ряд команд уже передаёт контекст безопасности AI-ассистентам через MCP-серверы, чтобы небезопасные паттерны не попадали в код изначально, а не обнаруживались на этапе PR [19].

Стандартизация форматов данных (OCSF — Open Cybersecurity Schema Framework, принятый в Linux Foundation в ноябре 2024) открывает путь к унификации алертов из разных инструментов в единую модель. Это фундаментальное условие для корреляции и умного триажа [20].

Заключение: не больше инструментов, а лучше сигнал

Alert fatigue — это не признак слабой команды. Это системная проблема, которая возникает в любой организации при несоответствии между объёмом генерируемых предупреждений и способностью команды на них реагировать.

Ключевые выводы:

1. Добавление инструментов без настройки и интеграции усугубляет проблему.
2. CVSS-сортировка без контекста систематически расставляет приоритеты неверно.
3. AI-кодинг увеличивает объём кода и предупреждений — и требует адаптации процессов ревью.
4. Решение — не в тишине, а в точности: меньше алертов, которые требуют реакции, больше уверенности в том, что важное не проскочит.
5. Gate перед merge и release должен давать команде конкретный следующий шаг — исправить, перепроверить или остановить выпуск.

Именно в этом и заключается смысл правильно выстроенного слоя контроля: не бесконечный отчёт, не тотальная блокировка, а короткий и понятный сигнал в нужный момент.

Источники

[1] ACM Computing Surveys — "Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities" — https://dl.acm.org/doi/10.1145/3723158

[2] Dropzone AI — "Alert Fatigue: What It Is & How to Fix It" — https://www.dropzone.ai/glossary/alert-fatigue-in-cybersecurity-definition-causes-modern-solutions-5tz9b

[3] Vectra AI — "Alert fatigue: causes, real cost, and how to fix it" — https://www.vectra.ai/topics/alert-fatigue

[4] Astra Security — "What's a False Positive & How to Triage It in SAST+DAST?" — https://www.getastra.com/blog/dast/false-positive-triage/

[5] Endor Labs — "From Shift Left to Shift Down: Making SAST Work for Developers" — https://www.endorlabs.com/learn/from-shift-left-to-shift-down-making-sast-work-for-developers

[6] Cycode — "Stopping Alert Fatigue in 3 Simple Steps" — https://cycode.com/blog/stopping-alert-fatigue-3-simple-steps/

[7] Cloud.ru — "DevSecOps в 2026 году: лучшие практики безопасного CI/CD" — https://cloud.ru/blog/luchshiye-praktiki-devsecops-v-2026-godu

[8] Cybersecurity News — "Prioritizing Vulnerabilities in a Sea of Alerts" — https://cybersecuritynews.com/prioritizing-vulnerabilities/

[9] Zafran — "Prioritizing Vulnerabilities: Best Practices for Risk-Based Patching" — https://www.zafran.io/ctem-academy/prioritizing-vulnerabilities-risk-based-patching

[10] CodeRabbit — "State of AI vs Human Code Generation Report" — https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

[11] The Register — "AI-authored code needs more attention, contains worse bugs" — https://www.theregister.com/2025/12/17/ai_code_bugs/

[12] QASource — "AI-generated Code Security Risks: Why Incidents Per Pull Request Have Increased by 23.5%" — https://www.qasource.com/blog/ai-generated-code-security-risks

[13] Expel — "Alert fatigue, burnout, turnover: lather, rinse, repeat" — https://expel.com/blog/alert-fatigue-burnout-turnover-lather-rinse-repeat/

[14] Augment Code — "AI Code Security: Essential Risks and Best Practices for Developers" — https://www.augmentcode.com/guides/ai-code-security-essential-risks-and-best-practices

[15] Medium (Vitalii Petrenko) — "40% of AI-Generated Code Has Security Flaws. Your Code Review Won't Catch Them" — https://vitalii4reva.medium.com/40-of-ai-generated-code-has-security-flaws-your-code-review-wont-catch-them-0a02a13848fe

[16] ClackyAI — "Code Review Checklist for AI-Generated Code" — https://clacky.ai/blog/code-review-checklist-ai-generated-code

[17] Bell Integrator — "DevSecOps: как российским компаниям выстроить процессы безопасной разработки" — https://bellintegrator.ru/node/1595

[18] arXiv — "LLM-Driven SAST-Genius: A Hybrid Static Analysis Framework for Comprehensive and Actionable Security" — https://arxiv.org/pdf/2509.15433

[19] Cloud Security Alliance — "Understanding Security Risks in AI-Generated Code" — https://cloudsecurityalliance.org/blog/2025/07/09/understanding-security-risks-in-ai-generated-code

[20] Databahn — "The Cybersecurity Alert Fatigue Epidemic" — https://www.databahn.ai/blog/siem-alert-fatigue-false-positive