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

Три термина — «баг», «уязвимость», «риск» — звучат похоже и часто используются как синонимы. Это дорого обходится: команды тратят ресурсы не на то, пропускают критичные проблемы и тормозят релизы ради незначимых находок. Разберём, чем они реально отличаются и почему это важно прямо перед merge и деплоем.

Зачем разбираться в терминологии

Команды разработки пишут код быстрее, чем когда-либо — AI-ассистенты превратили разработку с человеческой скоростью в прошлое. По данным аналитиков, к концу 2024 года около 30% производственного кода уже генерировалось при участии ИИ [1]. К 2026 году ситуация стала более острой: по данным исследователей, AI-генерируемый код содержит уязвимости в 25–62% случаев в зависимости от методологии измерения [2], а плотность уязвимостей в таком коде в 1,88–2,7 раза выше, чем в человеческом [3].

В этих условиях слова «баг», «уязвимость» и «риск» всё чаще смешиваются в одну кучу в тикетах, code review и предрелизных чеклистах. Последствия предсказуемы: команды AppSec тратят время на дефекты без реального воздействия и пропускают то, что действительно блокирует выпуск.

Точная терминология — это не педантизм. Это операционная необходимость.

Ошибка (bug): когда что-то работает не так

Ошибка в программном обеспечении — это дефект, из-за которого система ведёт себя не так, как задумано: выдаёт некорректный результат, падает с исключением, зависает или теряет данные [4]. Ошибки возникают везде — в логике, в граничных условиях, в обработке исключений, в конфигурации, в интеграционном коде.

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

Таким образом:

• Не каждая ошибка является уязвимостью.
• Но каждая уязвимость — это ошибка (или набор ошибок).

Именно это соотношение описывает академическое исследование в области безопасности ПО: «аналитик безопасности интересуется только теми ошибками, которые имеют последствия для безопасности» [5]. Устранение всех ошибок уничтожило бы и все уязвимости — но это недостижимо, поэтому приоритизация имеет решающее значение.

Слабость (weakness): CWE и классы проблем

Прежде чем перейти к уязвимостям, важно ввести промежуточный уровень — слабость (weakness). Это понятие систематизировал MITRE через CWE — Common Weakness Enumeration, каталог типовых дефектов кода, архитектуры и конфигурации, которые могут порождать уязвимости [6].

CWE — это не каталог конкретных инцидентов, а таксономия классов проблем. Если CVE — «полицейский отчёт о конкретном взломе», то CWE — «нарушение строительного кодекса, которое сделало этот взлом возможным» [7].

Иерархия MITRE позволяет рассуждать на разных уровнях детализации:

1. Широкая категория: CWE-119 — некорректная работа с границами памяти.
2. Конкретная слабость: CWE-122 — переполнение динамической памяти (heap-based buffer overflow) как подтип CWE-119.

CISO интересует, что в приложениях есть «проблемы с memory safety» (высокий уровень). Разработчику нужно знать, что в конкретной функции парсинга — heap-based buffer overflow (детальный уровень) [7].

CWE используют в code review, статическом анализе (SAST), при threat modeling и как базу для приоритизации находок. Каталог содержит более 900 записей и обновляется ежегодно [6].

Уязвимость: когда ошибку можно эксплуатировать

Уязвимость — это конкретный экземпляр слабости в конкретном продукте или версии, который злоумышленник может использовать для компрометации конфиденциальности, целостности или доступности системы [5]. NIST SP 800-30 определяет уязвимость как «дефект или слабое место в системных процедурах безопасности, дизайне, реализации или внутренних контролях, которые могут быть случайно или намеренно активированы и привести к нарушению безопасности» [8].

Ключевые свойства уязвимости:

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

Конкретные уязвимости получают идентификаторы CVE (Common Vulnerabilities and Exposures) и оцениваются по шкале CVSS. По состоянию на апрель 2026 года в базе CVE зарегистрировано более 327 000 уязвимостей [10].

Цепочка выглядит так: слабость (CWE) → конкретный экземпляр в продукте (CVE) → оценка тяжести (CVSS). Один класс CWE (например, SQL Injection, CWE-89) порождает сотни конкретных CVE в разных продуктах [7].

Риск: вероятность ущерба с учётом контекста

Риск — это не сама уязвимость и не сама угроза. По определению NIST SP 800-30, «риск — это функция вероятности того, что источник угрозы воспользуется уязвимостью, и размера ущерба от этого события» [11]. Selectel и другие русскоязычные источники формулируют проще: риск = вероятность реализации угрозы × потенциальный ущерб [12].

Иначе говоря:

• Уязвимость без достижимого вектора атаки или без ценного актива рядом — это низкий риск.
• Уязвимость в публично доступном API с доступом к ПДн — это высокий риск.

Методология OWASP Risk Rating формализует расчёт: Риск = Вероятность × Воздействие [13]. Вероятность определяется факторами угрозы (уровень навыков атакующего, мотивация, возможности) и факторами уязвимости (лёгкость обнаружения, лёгкость эксплуатации). Воздействие разбивается на техническое (потеря конфиденциальности, целостности, доступности) и бизнесовое (финансовый ущерб, репутация, регуляторные штрафы).

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

Риск выпуска: отдельная категория оценки

Риск выпуска (release risk) — это не просто «есть ли в коде уязвимость». Это комплексная оценка: безопасно ли выпускать конкретное изменение в прод прямо сейчас, с учётом контекста.

Ключевые составляющие риска выпуска:

1. Что именно изменилось — новые зависимости, конфигурации, миграции, инфраструктурный код, секреты, API-контракты.
2. Куда это идёт — внутренний инструмент или публичный endpoint; staging или прод; какие данные затрагивает.
3. Когда это идёт — пиковая нагрузка, ночь, пятница, период регуляторных проверок.
4. Что сопровождает деплой — есть ли rollback-план, мониторинг, feature flags для изоляции радиуса взрыва.
5. Какие уязвимости и слабости уже известны в изменении — и насколько они эксплуатируемы прямо сейчас.

Исследование по практикам безопасного деплоя CISA подчёркивает, что многие инциденты возникают не из-за дефектного кода, а из-за провала контролей на стадии деплоя: подмены артефактов между сборкой и выкаткой, некорректных конфигураций окружения, слабого разграничения доступа, расхождения между окружениями [15].

Отдельный аспект — что CVSS-оценка уязвимости не равна риску выпуска. Уязвимость с CVSS 9.0 в компоненте, который недоступен извне и не обрабатывает чувствительные данные, может быть менее критичной для принятия решения о релизе, чем CVSS 6.5-находка в публичном авторизационном endpoint'е.

Как это работает на практике: три сценария

Сценарий 1: Баг без риска

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

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

В новой зависимости обнаружена CVE с CVSS 7.8 — SQL Injection (CWE-89). Если компонент используется во внутреннем аналитическом инструменте без доступа к интернету и без прямой работы с ПДн — это уязвимость с умеренным риском, требует патча по расписанию. Если тот же компонент стоит в публичном API авторизации, обрабатывающем платёжные данные, — это блокирует релиз до исправления.

Сценарий 3: Риск выпуска без уязвимости в коде

Команда выпускает новую конфигурацию Kubernetes с излишне широкими RBAC-правами. В самом коде нет ни одной CVE, SAST прошёл чисто. Но конфигурационная слабость (CWE-732: неверное управление правами доступа) создаёт серьёзный риск выпуска: злоумышленник, получивший доступ к кластеру через любой другой вектор, сможет эскалировать привилегии. SAST это не поймал — поймает только полноценный review конфигурации как части деплоя.

Где путаница возникает чаще всего

AI-генерируемый код усиливает разрыв. GitHub Copilot и аналоги генерируют код, прошедший функциональные тесты, но не прошедший security review. По данным исследования NYU, Copilot производит уязвимый код примерно в 40% случаев [16]. При этом 58% разработчиков доверяют AI-выводу без дополнительного тестирования [3]. Баг обнаруживают в QA. Уязвимость — нередко только после деплоя в прод.

Зависимости приезжают тихо. Транзитивная зависимость с CVE CVSS 9.0 может попасть в lock-файл незаметно — без изменений в коде и без review. Это не баг в коде команды. Это уязвимость в supply chain с потенциально высоким риском выпуска в зависимости от того, как используется компонент.

Конфиги и миграции читают хуже всего. По данным Microsoft, 80% атак ransomware в определённые периоды восходили к типовым ошибкам конфигурации [17]. Конфигурационная слабость — не баг в бизнес-логике и не CVE в коде, но она создаёт реальный риск. В предрелизном checklist'е она часто остаётся вне радара.

Ложная безопасность после SAST. Чистый прогон статического анализа не означает отсутствие уязвимостей, и тем более не означает приемлемый риск выпуска. SAST не видит runtime-поведение, не знает контекст деплоя, не анализирует конфигурации и не оценивает, насколько конкретный компонент доступен из интернета.

Decision framework: что с этим делать

Для каждой находки перед merge/release стоит задать четыре вопроса:

1. Это баг или уязвимость? Влияет ли дефект на безопасность, или только на функциональность?
2. Если уязвимость — какой класс CWE, насколько он известен и опасен в данном типе продукта?
3. Какова реальная вероятность эксплуатации в нашей конкретной среде: доступность извне, чувствительность данных, наличие компенсирующих контролей?
4. Каков контекст выпуска: куда идёт, когда, что рядом, есть ли rollback?

Ответы на эти вопросы дают три возможных решения:

• Блокировать merge/release: высокий риск, уязвимость эксплуатируема в текущем контексте, компенсирующих контролей нет.
• Релизить с тикетом: уязвимость присутствует, но риск управляем, патч нужен по расписанию.
• Информировать без блока: баг без security-последствий, риск выпуска минимален.

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

Как выстроить контроль в современных условиях

Практические меры, которые закрывают описанные gaps:

На стадии кода и PR:

• Использовать SAST для обнаружения слабостей (CWE) ещё в IDE и в CI до merge. Но понимать, что SAST — это фильтр слабостей, а не полная оценка риска.
• Включить SCA (Software Composition Analysis) для анализа зависимостей: прямых и транзитивных. В 2025 году 65% организаций зафиксировали атаку supply chain в прошедшем году [18].
• Читать конфиги и миграции так же внимательно, как бизнес-логику. Слабость в конфигурации не имеет CVE, но может стоить дороже любой CVE.

На стадии предрелизного gate:

• Оценивать не только «есть ли уязвимость», но и контекст: куда деплоится, какие данные затрагивает, насколько компонент доступен.
• Иметь чёткую политику: что является hard blocker, что — предупреждением. Автоматизированные quality gates должны блокировать выпуск при наличии критических уязвимостей, а не заваливать команду шумом [19].
• Включать rollback-план и мониторинг как обязательные условия деплоя — особенно в пятницу и перед выходными.

На стадии после деплоя:

• Продолжать отслеживать новые CVE для компонентов, уже находящихся в продакшне: уязвимость публикуется после того, как код уже год живёт в проде.
• Строить SBOM (Software Bill of Materials) как живой документ, а не snapshot в момент сборки: статические SBOM устаревают быстрее, чем мы думаем [1].

HighVibe: слой контроля между скоростью и безопасностью

Описанная проблема — не теоретическая. AI-кодинг ускорил разработку, но контроль изменений не успевает расти с той же скоростью. Рабочий pull request не обязательно безопасен. Дифы дочитывают не до конца. Новая транзитивная зависимость приезжает незаметно. Перед релизом времени мало, а ещё один длинный security-отчёт не помогает быстро понять, что действительно критично.

HighVibe работает как дополнительный слой контроля до merge и release: анализирует конкретные изменения в коде, конфигурации и служебных файлах, новые и обновлённые зависимости, а также контекст релиза. Он помогает команде получить короткий и понятный ответ: можно ли безопасно принять именно это изменение прямо сейчас — и что делать, если нет.

Это не замена SAST, SCA или SBOM. Это следующий слой, который работает с ними вместе и переводит их вывод в операционное решение: исправить, перепроверить или остановить merge/release.

Выводы и что делать дальше

Три понятия описывают разные вещи и требуют разных действий:

• Баг — это вопрос качества: исправлять по приоритету функциональности и воздействия на пользователя.
• Уязвимость — это вопрос безопасности: оценивать по типу (CWE), серьёзности (CVSS) и контексту среды, где она живёт.
• Риск выпуска — это вопрос операционного решения: что конкретно идёт в прод, в каких условиях, и каков потенциальный ущерб.

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

Следующий шаг — посмотрите на свой текущий предрелизный процесс: есть ли в нём явный ответ на вопрос «что именно блокирует выпуск прямо сейчас»? Если этот ответ занимает больше 30 секунд — процесс стоит пересмотреть.

Источники

[1] Apiiro — "Application Security Risk Assessment: The Complete 2026 Checklist for Dev Teams" — https://apiiro.com/blog/application-security-risk-assessment-checklist/

[2] Paperclipped — "AI-Generated Code Vulnerabilities 2026: Security Data & Statistics" — https://www.paperclipped.de/en/blog/ai-generated-code-security-vulnerabilities/

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

[4] ArXiv / Robot Vulnerability Database — "Introducing the Robot Vulnerability Database (RVD)" — https://arxiv.org/pdf/1912.11299

[5] ArXiv — "Cybersecurity: Past, Present and Future" — https://arxiv.org/pdf/2207.01227

[6] Orca Security — "CWE: Understanding Common Weakness Enumeration in Cloud Security" — https://orca.security/glossary/cwe/

[7] Automox — "CVE, CWE, CVSS, and NVD: A Complete Guide to Vulnerability Acronyms" — https://www.automox.com/blog/vulnerabilities-software-weaknesses-acronym-breakdown

[8] NASA / NIST SP 800-30 — "Vulnerability Assessment in Test Plan Design Verification" — https://www.nasa.gov/sites/default/files/585618main_VulnerabilityAssessmentTestPlanDesign.pdf

[9] Apiiro — "What Are Software Development Vulnerabilities? Types & Risks" — https://apiiro.com/glossary/software-development-vulnerabilities/

[10] Wikipedia — "Vulnerability (computer security)" — https://en.wikipedia.org/wiki/Vulnerability_(computer_security))

[11] NIST / CSRC — "NIST SP 800-30, Risk Management Guide for IT Systems" — https://csrc.nist.rip/library/alt-SP800-30.pdf

[12] Selectel — "Что такое риски информационной безопасности" — https://selectel.ru/blog/what-are-information-security-risks/

[13] OWASP Foundation — "OWASP Risk Rating Methodology" — https://owasp.org/www-community/OWASP_Risk_Rating_Methodology

[14] Snyk — "What is a Security Vulnerability? Exploits, Threats, Types & Remediation" — https://snyk.io/blog/security-vulnerability-exploits-threats/

[15] CISA / IC3 — "Safe Software Deployment: How Software Manufacturers Can Ensure Reliability" — https://www.ic3.gov/CSA/2024/241024.pdf

[16] ArXiv — "Security Degradation in Iterative AI Code Generation" — https://arxiv.org/pdf/2506.11022

[17] Forescout — "Vulnerability vs. Threat vs. Risk vs. 'Other'" — https://www.forescout.com/blog/vulnerability-vs-threat-vs-risk-vs-other/

[18] Linux Insurer — "AI Coding Boom Drives Surge in Open-Source Vulnerabilities" — https://www.linuxinsider.com/story/open-source-vulnerabilities-double-as-ai-coding-grows-177663.html

[19] GoReplay — "Software Deployment Checklist: 7 Essential Steps for 2025" — https://goreplay.org/blog/software-deployment-checklist/