Почему сканеры находят сотни проблем, а команда всё равно выпускает релиз

Разбираем механизм принятия риска в разработке — от alert fatigue до shadow policy

Введение: парадокс насыщенного сканирования

Представьте типичную сцену перед релизом. CI/CD выдал отчёт: 47 критических находок, 230 высоких, ещё несколько сотен medium и low. Дедлайн через 48 часов. Бизнес ждёт запуска. Что делает команда?

Выпускает.

Именно так устроено большинство современных процессов разработки. По данным Checkmarx за 2025 год, 81% команд осознанно шипают код с известными уязвимостями — каждая третья это делает, чтобы не сорвать дедлайн [1]. Ещё более показательная цифра: 33% признаются, что просто надеются — "авось не найдут" [1].

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

Статья для тех, кто хочет разобраться, почему так происходит — и что с этим делать.

Уровень первый: сканеры кричат «волк» слишком часто

Сколько на самом деле ложных срабатываний

NIST зафиксировал, что SAST-инструменты для Java показывают ложные срабатывания в 78% случаев [2]. Бенчмарк OWASP для DAST-инструментов — 82% [3]. Согласно опросу 2024 года среди SOC-команд, около 53% всех алертов являются ложными позитивами [6]. При этом опрос Orca Security показал: 43% ИТ-специалистов признают, что 40% их алертов — ложные, хотя они по-прежнему доверяют своим инструментам [7].

Для настроенных по умолчанию конфигураций, вроде SonarQube на типовой Java- или TypeScript-кодовой базе, процент нерелевантных находок составляет 40–60% [8]. Checkmarx при тестировании на benchmark-приложениях показал 36,3% ложных позитивов [9].

Исследование 2024 года, проанализировавшее 815 реальных уязвимых коммитов в C/C++-проектах, выявило более жёсткую картину: в коммитах, где SAST всё же сработал, не менее 76% алертов оказались не относящимися к реальной уязвимости [10]. При этом 22% известных уязвимых коммитов инструмент вообще пропустил — ни одного предупреждения [10].

Итог: когда большинство находок — не настоящие проблемы, команда вырабатывает рациональное поведение — игнорировать. Это не лень. Это адаптация к зашумлённой среде.

Почему вендоры настраивают инструменты так, а не иначе

Есть структурный причина. Вендоры предпочитают ложные позитивы ложным негативам: пропущенная уязвимость — это жалоба и потеря клиента, лишний алерт — просто шум [11]. Поэтому инструменты поставляются с настройками "на чувствительность", а не "на точность". Настройка под конкретную среду возможна, но требует времени — и большинство организаций этим никогда не занимаются.

Уровень второй: организация производит правильные стимулы для неправильного поведения

Кто отвечает за дедлайн vs. кто отвечает за безопасность

В большинстве команд существует структурный конфликт: product manager или бизнес отвечают за дату выхода фичи, а security-команда — за устранение уязвимостей. Метрики, KPI и премии настроены под первое. Когда сканер выдаёт стостраничный отчёт за 48 часов до релиза, решение о выпуске принимается не техническим лидом безопасности — оно принимается тем, у кого горит дедлайн.

По данным Black Duck за 2024 год, 86% респондентов считают, что проверки безопасности замедляют разработку хоть в какой-то мере [12]. При этом 43% говорят, что они "умеренно замедляют". Это системный конфликт — и он решается не уговорами, а архитектурой процесса.

По данным опроса на FS-ISAC Americas Fall Summit 2024, трение между командами безопасности и разработки заняло первое место в списке болевых точек AppSec, набрав 39% голосов [13].

Shadow policy: негласное правило "выпусти сейчас, исправь потом"

Исследование Checkmarx 2025 года описывает явление, которое называет "теневой политикой": формально никто не принял решение игнорировать алерты безопасности, но де-факто именно это происходит при каждом напряжённом спринте [1]. 38% разработчиков признают, что пушат небезопасный код под давлением дедлайна [1].

Эта практика нормализуется. По данным отчёта CIO о предприятиях с AI-разработкой, три четверти компаний осознанно деплоят уязвимый код под давлением требований ROI [14]. Ещё треть организаций держат больше половины известных уязвимостей неисправленными дольше 90 дней [14].

Уровень третий: CVSS не отвечает на вопрос "блокирует ли это релиз"

Почему 300 критических находок — не 300 реальных проблем

CVSS измеряет теоретическую серьёзность уязвимости, но не отвечает на ключевой операционный вопрос: "Эта уязвимость достижима в моей среде?" В первом квартале 2025 года 28% активно эксплуатируемых уязвимостей имели только средний балл CVSS [15]. Организации, ориентирующиеся исключительно на CVSS-приоритизацию, систематически игнорируют более четверти проблем, которые реально используют злоумышленники [15].

За 2025 год в NVD опубликовано 48 185 CVE [16]. Никакая команда не может закрыть их все. Задача — правильно выбрать, что действительно опасно сейчас.

Среди 40 000 CVE в год лишь ничтожная доля становится вектором атаки на конкретную организацию. По данным Picus Security, только 14% зафиксированной активности злоумышленников вообще генерирует алерт [17]. Это означает: большинство "критических" находок сканера никогда не будут использованы против вас — и в то же время реальные атаки проходят незамеченными.

Что работает: контекст, достижимость, бизнес-приоритет

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

1. CVSS как базовый уровень — понять класс угрозы.
2. EPSS (Exploit Prediction Scoring System) — оценить вероятность реальной эксплуатации в ближайшие 30 дней; EPSS v4, вышедший в марте 2025 года, обрабатывает более 250 тысяч точек данных об угрозах ежедневно [18].
3. CISA KEV (Known Exploited Vulnerabilities) — каталог уязвимостей, подтверждённых к эксплуатации в реальных атаках.
4. Reachability analysis — достижима ли уязвимая функция в конкретном коде реальным трафиком.
5. Бизнес-контекст — какой актив, насколько он публичен, какие данные обрабатывает.

Критическая уязвимость в коде, доступном через публичный API, который обрабатывает PII и генерирует 80% выручки — это блокирующий релиз. Тестовый пароль в конфигурации, которая никогда не деплоится, — это не блокирующий релиз [19]. Сканер без контекста не может сделать это различие. Команда без методологии — тоже.

Уровень четвёртый: security debt растёт быстрее, чем способность его устранять

Цифры, которые говорят сами за себя

По данным Veracode State of Software Security 2026, 82% организаций накопили security debt — уязвимости, не исправленные дольше года [4]. Это рост с 74% в 2025 году и 71% в 2024-м. Критический security debt (уязвимости одновременно высокой тяжести и высокой эксплуатируемости) сейчас есть у 60% организаций — рост на 20% относительно 2025 года [4].

Среднее время исправления дефектов безопасности выросло на 47% за последние пять лет [5]. Высокорискованные уязвимости выросли на 36% год к году [4]. 70% критического security debt происходит из кода третьих сторон — open source зависимостей [20].

По данным Sonatype за 2024 год, 80% зависимостей в проектах не обновляются дольше года, несмотря на доступные патчи [21].

Почему AI ускоряет создание долга

AI-инструменты кодинга резко повысили скорость написания кода — и одновременно скорость накопления security debt. По данным Veracode GenAI Code Security Report 2025, AI-инструменты вводят уязвимости в 45% случаев при анализе 80 задач на более чем 100 LLM-моделях [22]. Для Java — более 70% [22]. По данным Cloud Security Alliance, 62% решений, написанных с AI, содержат архитектурные ошибки или известные уязвимости даже при использовании последних моделей [23].

К июню 2025 года AI-generated код добавлял более 10 000 новых security findings ежемесячно в исследуемых репозиториях — в 10 раз больше, чем в декабре 2024-го [24]. При этом 56% разработчиков признают, что редко читают AI-сгенерированный код построчно [24]. А 58% доверяют его результатам без тестирования [24].

Получается следующий цикл: AI пишет быстро → PR никто не читает до конца → сканер выдаёт длинный отчёт → команда в него не верит → код уходит в прод.

Уровень пятый: tool sprawl и отсутствие единого ответа "можно ли сейчас выпускать"

Когда инструментов слишком много

AppSec-команды часто работают с десятками разрозненных инструментов: SAST для первой стороны, SCA для зависимостей, DAST для динамики, secret scanners, контейнерные сканеры, IaC-проверки, CI/CD-политики. Каждый выдаёт свой список. Нет единого места, где можно увидеть ответ на вопрос: "Что именно в этом конкретном изменении действительно блокирует релиз?"

По данным OX Security AppSec Report 2026 (анализ 216 миллионов находок в 250 организациях), объём алертов растёт, уровень шума — тоже [25]. 18% критических уязвимостей действительно стоят приоритизации в типовом DevSecOps-пайплайне — остальные 82% — это шум или нерелевантный контекст [25].

Разрыв между AppSec и разработкой как операционная проблема

Когда security живёт в отдельной команде с отдельным тулсетом, разработчики получают отчёты об уязвимостях, которые не просили, не могут быстро обработать и часто не понимают [26]. Результат предсказуем: алерты игнорируются, бэклог растёт, риск накапливается [26].

Исследование 2024 года в сфере DevSecOps показывает: только 30% организаций оценивают свой уровень как "зрелый DevSecOps" [21]. Большинство проходят через раннее сканирование, которое не сопровождается изменением культуры работы с результатами.

Что на самом деле работает: от длинного отчёта к решению по конкретному изменению

Принцип: блокируй немногое, объясняй понятно, не шуми

Ключевой сдвиг в зрелых AppSec-программах — переход от "отсканируй всё" к "дай понятный ответ по тому изменению, которое сейчас идёт на merge/release". Это принципиально другой вопрос:

Не "сколько всего уязвимостей в репозитории", а "что именно в этом PR/релизе создаёт реальный риск прямо сейчас".

По данным руководства по security gates в CI/CD от Secure.com, архитектура, которая работает, строится на трёх элементах: логике блокировки, основанной на эксплуатируемости и бизнес-риске одновременно; чётком процессе исключений (exception process); и actionable output — каждая находка должна иметь владельца, описание исправления и последствие неустранения [27].

Практический чек-лист: что проверять перед merge и релизом

Перед merge в основную ветку:

1. Добавлена ли новая зависимость? Проверить: есть ли для неё открытые CVE, поддерживается ли библиотека, нет ли в ней критических уязвимостей с EPSS выше порога.
2. Изменились ли конфиги, Dockerfile, IaC-файлы, CI/CD-пайплайны? Именно эти файлы читают хуже всего — и именно там часто появляются debug-настройки, широкий CORS, лишние права.
3. Нет ли в диффе секретов, fallback-ключей, хардкоженных credentials?
4. Если AI написал этот PR — просмотрен ли он построчно? Или только "проверена функциональность"?

Перед релизом в прод:

1. Какие из открытых находок имеют KEV-статус или EPSS выше 0.1?
2. Достижима ли уязвимая функция из публичного эндпоинта?
3. Какие компоненты изменились по сравнению с прошлым релизом — не весь репозиторий, а именно дельта?
4. Есть ли задокументированное решение по каждому принятому риску — с владельцем, сроком и обоснованием?

Ошибки, которые воспроизводятся везде

• Запускать сканер только раз — перед релизом, а не в каждом PR.
• Приоритизировать по CVSS без учёта достижимости и бизнес-контекста.
• Создавать бэклог из тысяч находок без SLA на исправление — он никогда не будет разобран.
• Не настраивать инструменты под свою среду — ложные позитивы гарантированы по умолчанию.
• Не иметь formal exception process — без него команда использует неформальный, и он всегда в пользу дедлайна.
• Не разделять "функционирует корректно" и "безопасно для деплоя" — это разные вопросы.

Контекст для России и СНГ

Отечественные данные добавляют локальный штрих к глобальной картине. По данным CNews, только 23% российских компаний реально уделяют внимание вопросам DevSecOps [28]. Почти половина тех, кто формально внедрил DevSecOps-инструменты, использует их исключительно для поверхностного сканирования свежего кода [28]. Характерный сценарий, описанный на Хабре: команда два месяца пишет модуль, за неделю до релиза ИБ-отдел запускает сканер и выдаёт пятидесятистраничный отчёт — разработчикам приходится экстренно переписывать половину кода [29].

Это классическая "болтовня в конце пайплайна" — security как блокирующий финальный гейт вместо непрерывного контроля по ходу разработки. Результат предсказуем: либо задержка релиза, либо игнорирование отчёта.

Тренды: куда движется индустрия

Несколько направлений очевидны на основе публичных данных 2025–2026 годов:

По данным Team8 CISO Village Survey, 50% CISO переходят от традиционного AppSec, ориентированного на сканирование кода на баги, к модели Product Security, охватывающей весь жизненный цикл ПО [30]. Reachability analysis — анализ того, достижима ли уязвимая функция реальным трафиком — становится обязательным слоем после SBOM. Академическое исследование по SBOM-based vulnerability management 2024 года прямо указывает: точный SBOM — необходимое, но не достаточное условие; без анализа достижимости сканеры будут неизбежно флагировать недостижимые уязвимости [31].

Развитие EPSS v4 (март 2025) делает вероятностную оценку эксплуатации практичным инструментом для ежедневной приоритизации [18].

AI в самом AppSec — не только как угроза, но и как инструмент триажа. По данным OX Security, 67% организаций уже используют AI для генерации кода или code review, при этом зрелые инструменты начинают применять его же для автоматической политики по результатам ревью [25].

Как HighVibe вписывается в эту картину

Проблема, описанная в статье, существует не потому, что у команд нет сканеров. У большинства они есть. Проблема — в отсутствии короткого понятного сигнала именно по тому изменению, которое уходит в прод прямо сейчас.

HighVibe — это слой контроля до merge и релиза, дополняющий существующий AppSec-стек. Он анализирует конкретный PR или набор изменений в контексте релиза: какие зависимости добавились, что изменилось в конфигах, нет ли секретов или debug-настроек, что во всём этом критично именно сейчас. Вместо ещё одного длинного отчёта — короткий ответ: что действительно блокирует выпуск, что стоит перепроверить, а что можно принять.

Это не замена SAST, SCA или SBOM. Это дополнительный слой, который помогает команде принять осознанное решение — не "выпустить и надеяться", а "понять риск и принять его явно".

Подробнее — на highvibe.dev.

Заключение: проблема не в том, что сканеры молчат

Данные за 2025–2026 годы дают однозначный ответ: организационный узкий брючок — не обнаружение уязвимостей. Это человеческое решение выпустить всё равно, подавить находку или отложить до следующего спринта [14].

Сканеры стали лучше. Но без контекста они всё равно выдают сотни алертов, из которых реально важны единицы. Разработчики адаптировались: научились не верить шуму — и вместе с ним перестали реагировать на сигнал.

Путь вперёд — не ещё один сканер, а изменение архитектуры обратной связи: security-информация в момент написания кода, приоритизация по достижимости и реальному риску, короткий и понятный сигнал перед merge и релизом, явный процесс принятия исключений.

Команды, которые это реализуют, не замедляются — они выпускают быстрее, потому что знают, что именно сейчас безопасно.

Источники

[1] Checkmarx / Eran Kinsbruner, Medium — "Risky Code Business: Why 81% of Devs Play Fast and Loose with Vulnerabilities" — https://ek121268.medium.com/risky-code-business-why-81-of-devs-play-fast-and-loose-with-vulnerabilities-a53488882298

[2] NIST SP 500-326 — "Interlinking Software Attack Manifestations and Security Measurement" — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.500-326.pdf

[3] Contrast Security — "AppSec Noise and Fatigue by the Numbers" — https://www.contrastsecurity.com/infographics/appsec-noise-and-fatigue-by-the-numbers

[4] Veracode — "2026 State of Software Security Report Reveals Four Out of Five Organizations Are Drowning in Security Debt" — https://www.businesswire.com/news/home/20260224526703/en/Veracode-2026-State-of-Software-Security-Report-Reveals-Four-Out-of-Five-Organizations-Are-Drowning-in-Security-Debt

[5] Veracode — "State of Software Security 2025" — https://www.veracode.com/resources/analyst-reports/state-of-software-security-2025/

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

[7] TuxCare — "False Positive Vulnerability: Causes, Risks & How to Avoid" — https://tuxcare.com/blog/false-positive-vulnerability/

[8] Autonoma — "SAST Tools Compared: 40–60% False Positive Rates" — https://getautonoma.com/blog/sast-tools

[9] Mobb — "Top SAST Tools Compared by False Positive Rate" — https://www.mobb.ai/blog/sast-tools-false-positive-comparison

[10] Endor Labs — "False Negatives in SAST: Hidden Risks Behind the Noise" — https://www.endorlabs.com/learn/false-negatives-in-sast-hidden-risks-behind-the-noise

[11] Praetorian — "Alert Fatigue and False Positives: Why More Alerts Mean Less Security" — https://www.praetorian.com/security-101/alert-fatigue-and-false-positives/

[12] Black Duck — "Key Insights from Black Duck's 2024 Global State of DevSecOps Report" — https://www.blackduck.com/blog/black-duck-devsecops-report.html

[13] OX Security — "A Costly Divide: 5 Ways to Stop AppSec and Dev from Working Against Each Other" — https://www.ox.security/blog/a-costly-divide-5-ways-to-stop-appsec-and-dev-from-working-against-each-other/

[14] CIO / CSO Online — "Enterprises Know AI-Generated Code Is Vulnerable; They're Shipping It Anyway" — https://www.cio.com/article/4183209/enterprises-know-ai-generated-code-is-vulnerable-theyre-shipping-it-anyway.html

[15] Picus Security — "Vulnerability Prioritization in 2026: Why CVSS Isn't Enough" — https://www.picussecurity.com/resource/blog/vulnerability-prioritization-why-cvss-isnt-enough

[16] Secure.com — "From CVE to Business Risk in One View: Why CVSS Scores Are Not Risk Scores" — https://www.secure.com/blog/risk-and-governance/cvss-scores-not-risk-scores

[17] Picus Security — "The Blue Report 2025" (упоминается в контексте 14% logged adversarial activity generating an alert) — https://www.picussecurity.com/resource/blog/vulnerability-prioritization-why-cvss-isnt-enough

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

[19] DEVOPSdigest — "2024 DevSecOps Predictions — Part 1" — https://www.devopsdigest.com/2024-devsecops-security-predictions-1

[20] Veracode — "Breaking Free from Security Debt: Lessons from Leading Organizations" — https://www.veracode.com/blog/breaking-free-from-security-debt/

[21] AppSecSanta / DevSecOps Statistics 2026 — https://appsecsanta.com/research/devsecops-statistics

[22] Veracode — "AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks" — https://www.businesswire.com/news/home/20250730694951/en/AI-Generated-Code-Poses-Major-Security-Risks-in-Nearly-Half-of-All-Development-Tasks-Veracode-Research-Reveals

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

[24] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[25] OX Security — "Application Security Trends Every DevSecOps Team Should Watch in 2026" — https://www.ox.security/blog/application-security-trends-in-2026/

[26] Arnica — "Dev-First AppSec Programs — Building a Security Program" — https://www.arnica.io/blog/dev-first-appsec-building-security-program-developers-want

[27] Secure.com — "How to Implement Effective AppSec Security Gates in CI/CD Pipelines" — https://www.secure.com/blog/appsec/appsec-security-gates-cicd-pipelines

[28] CNews — "И так сойдёт. Российские компании массово «забывают» проверить свои ИТ-продукты на безопасность" — https://safe.cnews.ru/news/top/2025-09-18_i_tak_sojdetrossijskie_kompanii

[29] Хабр — "Почему безопасность на этапе релиза обходится в десять раз дороже и как это исправить" — https://habr.com/ru/articles/1044656/

[30] Team8 — "AI, Risk, and the Road Ahead: Key Findings from the 2025 CISO Village Survey" — https://team8.vc/ciso-village-survey-2025/

[31] arXiv — "A Reality Check on SBOM-based Vulnerability Management: An Empirical Study and A Path Forward" — https://arxiv.org/pdf/2511.20313