Это слабое место в системе, приложении, сетевой инфраструктуре, настройках или действиях пользователей, которое может быть использовано злоумышленником для нарушения конфиденциальности, целостности или доступности данных и сервисов
Обновлено: 9 июля 2026
Это слабое место в системе, приложении, сетевой инфраструктуре, настройках или действиях пользователей, которое может быть использовано злоумышленником для нарушения конфиденциальности, целостности или доступности данных и сервисов
Важно понять ключевую мысль сразу, сама по себе уязвимость — это ещё не атака и не инцидент. Это условие, которое делает атаку возможной. Пока уязвимость не обнаружена злоумышленником или не эксплуатирована, прямого ущерба нет. Но если слабое место найдено и использовано — последствия могут быть серьезными.
Несколько простых примеров из практики:
Во всех трёх случаях система или процесс функционируют, но содержат слабое место, которое при определенных условиях открывает дверь для атаки.
В основе понятия уязвимости лежит классическая модель информационной безопасности — триада CIA:
В области информационной безопасности часто путают несколько близких понятий. Это приводит к тому, что компании либо недооценивают реальную опасность, либо тратят ресурсы не туда. Разберём ключевые термины.
Уязвимость — слабое место или недостаток в системе, программном обеспечении, конфигурации или процессах, через которое можно нарушить безопасность.
Угроза — потенциальное событие или действие, способное использовать уязвимость и причинить ущерб компании: от кражи данных до полной остановки бизнес-процессов.
Риск — вероятность реализации угрозы и возможный ущерб от неё, измеряемый в финансовых, репутационных или операционных потерях.
Эксплойт — инструмент или техника, с помощью которых злоумышленник целенаправленно использует уязвимость на практике: будь то вредоносный код, специально сформированный запрос или последовательность действий, превращающая теоретическую слабость системы в реальную точку взлома.
Инцидент — зафиксированный факт нарушения безопасности, когда угроза перестала быть потенциальной и эксплойт сработал: данные утекли, системы скомпрометированы, бизнес-процессы нарушены. Именно с этого момента начинается работа по реагированию, расследованию и устранению последствий.
Уязвимость — это возможность, угроза — это намерение, эксплойт — это действие, инцидент — это свершившийся факт, а риск — это цена того, что вся эта цепочка окажется успешной.
Понимание этих различий критически важно для правильной расстановки приоритетов. Не каждая уязвимость несет одинаковый риск, и не каждый риск требует немедленного исправления.
Уязвимости можно классифицировать по нескольким осям: по тому, в каком объекте они находятся, по причине возникновения и по уровню критичности. Такой подход помогает не просто знать термин, а понимать, где именно искать слабые места в конкретной инфраструктуре.
Важно понимать: одна и та же уязвимость может одновременно относиться к нескольким категориям. Например, неверно настроенный облачный сервис — это и уязвимость конфигурации, и уязвимость облачной среды, и результат человеческой ошибки.
Уязвимости встречаются в каждом слое современной инфраструктуры.
Это один из наиболее распространённых типов. Разработчики допускают ошибки в коде, библиотеки содержат слабые места, а обновления не всегда выходят вовремя или устанавливаются оперативно. Примеры: переполнение буфера, use-after-free, уязвимости в парсерах форматов файлов.
Особый класс, поскольку веб-приложения напрямую доступны из интернета. Сюда входят SQL-инъекции, XSS (межсайтовый скриптинг), CSRF, небезопасная аутентификация, незащищенные API. Методология OWASP Top 10 систематизирует наиболее критичные из них.
Открытые порты, небезопасные протоколы (например, использование Telnet вместо SSH), отсутствие шифрования трафика, ошибки в конфигурации сетевого оборудования, слабые правила межсетевого экрана.
С переходом компаний в облако появился новый класс проблем: публично доступные S3-бакеты с конфиденциальными данными, избыточные права IAM-ролей, неверно настроенные группы безопасности, отсутствие шифрования данных в хранилищах.
Незащищенные рабочие станции, устаревшие прошивки роутеров, уязвимые IoT-устройства, контроллеры промышленных систем без обновлений безопасности.
| Тип объекта | Пример уязвимости | Возможное последствие |
| ОС и ПО | Уязвимость в ядре ОС без патча | Повышение привилегий, выполнение кода |
| Веб-приложение | SQL-инъекция в форме поиска | Утечка базы данных |
| Сетевая инфраструктура | Открытый RDP на периметре | Brute force, несанкционированный доступ |
| Облако | Публичный доступ к S3-бакету | Утечка файлов клиентов |
| Конечные устройства | Устаревшая прошивка роутера | Перехват трафика, MITM |
Многие считают, что уязвимости — это исключительно ошибки программистов. На практике картина значительно шире.
Классические баги: некорректная обработка входных данных, отсутствие проверки прав доступа, небезопасное использование памяти. Эти уязвимости возникают на этапе разработки и могут годами оставаться незамеченными.
По статистике, misconfiguration — одна из самых частых причин инцидентов, особенно в облачных средах. Примеры: сервис запущен с правами root без необходимости, включены ненужные функции, не применены стандарты hardening, открыты лишние порты.
Использование библиотек и фреймворков с известными уязвимостями, для которых уже существуют эксплойты. Это особенно актуально для приложений со сложными цепочками зависимостей.
Отсутствие регламентов управления доступом, несоблюдение принципа минимальных привилегий, отсутствие процесса патч-менеджмента, неконтролируемый shadow IT.
Слабые пароли, отсутствие MFA, переход по фишинговым ссылкам, неосторожное обращение с данными. По данным разных исследований, человеческий фактор присутствует в большинстве реализованных инцидентов ИБ.
Топ-7 причин появления уязвимостей в корпоративных инфраструктурах:
Для стандартизации описания и оценки уязвимостей используется несколько международных систем.
Это уникальный идентификатор конкретной известной уязвимости. Формат: CVE-[год]-[номер]. Например, CVE-2021-44228 — это знаменитая уязвимость Log4Shell в библиотеке Log4j. Наличие CVE означает, что уязвимость публично задокументирована, и для нее могут существовать готовые эксплойты.
Это классификатор типов слабостей в коде и архитектуре. Если CVE — конкретный «экземпляр» проблемы, то CWE — её «класс». Например, CWE-89 — SQL Injection, CWE-79 — XSS.
Числовая оценка критичности уязвимости от 0 до 10, учитывающая вектор атаки, сложность эксплуатации, требования к привилегиям и потенциальное воздействие.
| CVSS Score | Уровень критичности | Рекомендуемый SLA устранения |
| 9.0–10.0 | Критический | До 24–72 часов |
| 7.0–8.9 | Высокий | До 7 дней |
| 4.0–6.9 | Средний | До 30 дней |
| 0.1–3.9 | Низкий | По расписанию |
Высокий балл CVSS не всегда означает высокий бизнес-риск. Уязвимость с CVSS 9.8 во внутренней тестовой системе без доступа из интернета может быть менее приоритетной, чем уязвимость с CVSS 7.2 на публичном сервисе обработки платежных данных. Приоритизация всегда должна учитывать контекст: доступность актива извне, критичность для бизнеса, наличие компенсирующих мер.
Распространенное заблуждение — считать, что уязвимости появляются только в момент разработки кода. На практике слабые места могут возникать на любом этапе жизненного цикла информационной системы: при проектировании архитектуры, в процессе разработки, при внедрении и настройке, в ходе эксплуатации, при интеграции со сторонними сервисами и даже при обновлении — когда новая версия компонента вносит новые проблемы.
Уязвимости — это не единичное событие, а постоянный процесс. Даже хорошо спроектированная и проверенная система может стать уязвимой завтра: выйдет новый эксплойт, изменится конфигурация, появится новый сотрудник с доступом, будет подключён внешний сервис.
Понимание причин помогает не просто реагировать на уже найденные проблемы, но и предотвращать появление новых.
Устаревшее программное обеспечение. Производители регулярно выпускают обновления безопасности. Если патч не установлен, уязвимость остаётся открытой, даже если её публично описали и для неё существует рабочий эксплойт.
Отсутствие или слабость патч-менеджмента. Во многих компаниях нет системного процесса: кто отвечает за обновления, в какие сроки, как проверяется факт установки. В результате критические патчи применяются с задержкой в недели или месяцы.
Уязвимые сторонние библиотеки и зависимости. Современные приложения используют десятки и сотни внешних компонентов. Уязвимость в одной популярной библиотеке может затрагивать тысячи продуктов одновременно — как это было с Log4Shell.
Неверные конфигурации. Сервисы с настройками по умолчанию, ненужные открытые порты, избыточные права — всё это создаёт дополнительную поверхность атаки без какого-либо злого умысла, просто из-за операционных ошибок.
Отсутствие инвентаризации активов. Компания не может защитить то, о чём не знает. «Забытые» серверы, старые тестовые среды, подключенные сторонние сервисы — классический источник проблем.
Низкая зрелость процессов ИБ. Отсутствие формальных политик, регламентов, контроля доступа и обучения сотрудников создает системные уязвимости организационного характера.
Ошибки сотрудников и подрядчиков. Неправильно настроенный сервис, случайно открытый порт, неверные права при онбординге нового подрядчика.
Понимание жизненного цикла уязвимости позволяет понять, почему важно действовать быстро после публикации информации о проблеме.
Исследователь, сотрудник компании-разработчика или злоумышленник обнаруживает слабое место. На этом этапе уязвимость может быть неизвестна публично.
При ответственном раскрытии (responsible disclosure) исследователь уведомляет вендора и даёт время на исправление. При публичном раскрытии без предупреждения или утечке информация появляется в открытом доступе до выхода патча.
Уязвимость регистрируется, получает идентификатор CVE и описание. С этого момента информация доступна всем — включая злоумышленников.
Публикуется proof-of-concept код или рабочий эксплойт. Порог для атаки существенно снижается — теперь воспользоваться уязвимостью может значительно более широкий круг атакующих.
Вендор выпускает исправление. Однако между выходом патча и его фактической установкой в инфраструктуре компании часто проходит значительное время.
Патч применяется, конфигурация исправляется или применяются компенсирующие меры. Это самый долгий и сложный этап в большинстве организаций.
Контроль факта устранения: уязвимость действительно закрыта, патч применен везде, где это необходимо.
Zero-day — это уязвимость, которая эксплуатируется злоумышленниками до того, как вендор узнал о ней или выпустил патч. Название отражает суть: у защищающейся стороны было «ноль дней» на подготовку. Zero-day особенно опасны, поскольку стандартные меры патч-менеджмента против них не работают — патча просто не существует.
Самое опасное окно — период между публикацией CVE и фактической установкой патча в инфраструктуре. Именно в это время злоумышленники наиболее активно сканируют и атакуют уязвимые системы.