Когда очередной "эксперт" говорит: "Ну, внедрите процесс управления уязвимостями, и всё будет хорошо". Спойлер: не будет. Я сам через это прошёл — и как инженер в SOC, и как руководитель, который потом разгребал последствия таких "внедрений".
Давайте честно разберем, что нас ждёт в 2026 году, почему старые подходы сломаются, и как вообще выживать, когда уязвимостей станет под 60 тысяч в год. Без воды, без маркетинга — только то, что работает в реальных российских реалиях.
Почему 50 000 CVE — это не просто цифра, а наш приговор? 📊
Я помню времена, когда 5000 уязвимостей в год казались катастрофой. Мы тогда сидели в небольшом SOCе, пили кофе литрами и думали: "Господи, куда катится мир?" Смешно вспоминать.
Сейчас ситуация другая. Forum of Incident Response and Security Teams (FIRST) опубликовал прогноз, от которого у меня лично глаза на лоб полезли. По их оценке, в 2026 году количество публично раскрытых уязвимостей может достичь 59 000 в медианном сценарии. А в оптимистичном — вообще под 118 тысяч.
Но вот что важно: это не значит, что хакеры вдруг стали умнее или код стал хуже. Причины гораздо прозаичнее, и если их понять, становится немного легче дышать.
Что реально происходит?
Во-первых, в экосистему CVE пришло гораздо больше игроков.
Если раньше уязвимости раскрывали только крупные вендоры и академические исследователи, то сейчас баг-хантеры с HackerOne и Bugcrowd штампуют отчёты пачками. Им за это платят — логично, что они стараются найти как можно больше.
Во-вторых... вы знаете, сколько лет некоторым кускам кода в open-source?
Я как-то копался в одной библиотеке для логирования — так там фрагменты 2003 года с ошибками, которые просто десятилетиями никто не замечал. Сейчас дошли руки. Legacy-код аукается нам всем.
И в-третьих, сам процесс присвоения CVE стал проще. MITRE и NVD расширили пул организаций, которые могут выдавать идентификаторы. Это правильно, но последствия мы расхлёбываем.
Операционный ад: почему 5% уязвимостей убивают 100% времени ⏳
Вот тут самое больное. По оценке FIRST, реальную угрозу представляют только около 5% всех публикуемых уязвимостей. Остальные 95%... ну, они есть. Где-то живут. Может, когда-нибудь кто-то и напишет под них эксплойт.
Но попробуйте объяснить это регуляторам или внутреннему аудиту. "А почему вы не закрыли CVE-2026-12345, которая висит в критических?" — "Потому что для неё нет эксплойта, она требует локального доступа и влияет только на конфиг, который у нас отключён". — "Мне плевать, закрывай, иначе предписание".
Знакомо? Уверен, что да.
По моему опыту, самое страшное начинается, когда поток уязвимостей превышает пропускную способность команды. Условно, если у вас в отделе 5 человек, и каждый может качественно проанализировать 10 уязвимостей в день — это 50 в день, 1000 в месяц. А приходит 4000. Всё, математика не сходится.
И вот тут люди начинают срезать углы. Перестают читать описания. Смотрят только на CVSS-балл. А CVSS, если честно, давно пора отправлять на свалку истории — но об этом позже.
CVSS врёт, или Почему баллы — зло 🎭
Давайте про CVSS. Common Vulnerability Scoring System — это, наверное, самое недооценённое и переоценённое одновременно изобретение человечества.
С одной стороны, круто, что есть хоть какой-то стандартизированный способ сравнить уязвимости. С другой... я сейчас буду ругаться матом, простите.
Кто реально работал в SOC, тот знает: уязвимость с CVSS 9.0 может быть абсолютно неопасна в вашем конкретном контексте. А с 4.5 — валить сервера пачками, если она правильно скомбинирована с другими.
Пример из жизни. Было у нас как-то сканирование, выявили кучу критических уязвимостей в старом софте на изолированном сегменте. CVSS кричит: 9.3! Ад! Пожар! Начинаем копать — а этот софт вообще не смотрит наружу, не имеет доступа в интернет, используется для внутренней разработки тремя сотрудниками, и патч для него ломает совместимость с кастомным кодом. Приоритет? Нулевой.
А рядом — уязвимость в библиотеке аутентификации с баллом 6.8. Которая используется во фронтенде. И под неё есть активный эксплойт в даркнете. И сканеры её даже не видят, потому что это не версия софта, а зависимость.
Как вам такая арифметика?
Что любопытно, FIRST и другие организации уже давно бьют тревогу. Нужен контекст. Нужна threat intelligence. Нужно понимать, эксплуатируется ли эта дыра прямо сейчас, есть ли под неё оружие, используется ли она в кампаниях APT-групп, которые нацелены на ваш сектор.
В 2026 году без этой информации — никуда. Просто тупо заливать патчи по вторникам — это путь к выгоранию команды и дырам в бюджете.
Автоматизация — не панацея, а топливо 🚀
Часто слышу: "Автоматизируем управление уязвимостями — и заживём". Ребята, я вас умоляю. Автоматизация без правильной логики — это как дать обезьяне гранату.
Да, без автоматизации вы просто умрёте под лавиной из 50 000 CVE. Но автоматизация решает только проблему скорости, а не проблему качества.
На практике всё чуть сложнее. Мы в своём SOCе прошли несколько этапов:
- Ручной ад. Каждую уязвимость смотрели глазами. Долго, дорого, много ошибок от усталости.
- Автоматизация по CVSS. Отсеивали всё ниже 7.0. Пропустили Log4Shell, потому что сначала ему дали низкий балл. Да-да, вы не ослышались — первоначальная оценка была копеечной.
- Автоматизация с обогащением. Подтягиваем данные из нескольких фидов threat intelligence, смотрим exploit-db, проверяем, есть ли активное использование в дикой природе. Уже лучше.
- Контекстная автоматизация. Система знает, какие активы у нас критические, где хранятся ПДн, какие сегменты изолированы. И приоритизирует уязвимости не по абстрактным баллам, а по реальному риску для бизнеса.
Вот это последнее — то, к чему нужно стремиться в 2026. Иначе ваша "автоматизация" будет просто быстрее генерировать тонны мусорных тикетов, которые никто не успевает закрывать.
И знаете, что удивляет? Многие до сих пор не используют простые штуки. Например, проверку по CISA KEV (Known Exploited Vulnerabilities). Там список небольшой, но каждая уязвимость в нём — реально горит. Закрывай — и спи спокойно.
Российская специфика: 152-ФЗ, ФСТЭК и импортозамещение 🇷🇺
Если вы работаете в российском банке, ОКИИ или госструктуре — вы и так знаете, о чём я. Если нет — поясню.
У нас к управлению уязвимостями добавляется ещё два слоя ада: регуляторные требования и вендорская зависимость.
По моим наблюдениям, самый частый сценарий сейчас: компания закупила импортное железо и софт до 2022 года, поддержка закончилась, вендор ушёл, а новые уязвимости в этих продуктах публикуются регулярно. И что делать? Патчей нет. Обновить нельзя. А ФСТЭК требует защиты.
Вот тут начинается джаз. Либо искать обходные пути (компенсирующие меры), либо срочно переходить на российское ПО, которое, скажем честно, тоже не всегда блещет качеством с точки зрения безопасности. Но по нему хотя бы вендор есть.
10 железных правил управления уязвимостями в 2026 📜
- Забудьте про CVSS как единственный критерий. Используйте его как фильтр первого уровня, не более. Дальше — только контекст и threat intelligence.
- Автоматизируйте сбор данных из всех источников. NVD, MITRE, exploit-db, Telegram-каналы (да, там часто информация появляется раньше), профильные форумы. Чем больше фидов, тем полнее картина.
- Сегментируйте активы по критичности. Условно: база данных с ПДн — золотой запас, а тестовый стенд разработчика — свалка. Уязвимости на них имеют разный вес. Точка.
- Внедрите процесс проверки по CISA KEV. Это бесплатно, просто и невероятно эффективно. Если уязвимость там — закрывать вчера.
- Используйте автоматическое обогащение. Каждая новая CVE должна автоматически проверяться на наличие эксплойтов, упоминаний в отчетах APT-групп, связей с вашим стеком технологий.
- Не пытайтесь закрыть всё. Это невозможно. Смиритесь. Закрывайте то, что реально опасно для вашего бизнеса.
- Стройте процессы под требования 152-ФЗ и 187-ФЗ заранее. Когда придёт проверка, будет поздно объяснять, что "мы не успели". Регулятору плевать на ваши проблемы с кадрами.
- Учите команду думать, а не просто нажимать кнопки. Автоматизация — это инструмент, а не замена мозгам. Самые страшные ошибки я видел, когда инженеры слепо верили сканеру.
- Тестируйте патчи перед массовым развертыванием. Сколько раз было: закрыли дыру, положили прод. Лучше неделя задержки с патчем, чем сутки простоя бизнеса.
- Сотрудничайте с коллегами по отрасли. Вступайте в отраслевые CERT, обменивайтесь информацией. Российский рынок небольшой, все друг друга знают. Помогайте — и помогут вам.
FAQ: 10 вопросов, которые мне задают чаще всего ❓
1. Сколько уязвимостей будет в 2026 году реально эксплуатироваться?
Около 3-5% от общего числа. Но эти 3-5% могут уничтожить вашу инфраструктуру, если их пропустить.
2. Обязательно ли внедрять дорогие коммерческие сканеры?
Не обязательно, но желательно. Open-source инструменты (OpenVAS, Nessus Essentials) хороши для базовой проверки, но для полноценного управления в большой инфраструктуре лучше использовать коммерческие решения с поддержкой и регулярным обновлением баз.
3. Как часто нужно проводить сканирование уязвимостей?
Зависит от динамики изменений в инфраструктуре. Если у вас всё статично — раз в месяц достаточно. Если активно разрабатываете и внедряете новое — непрерывно.
4. Что делать, если нет патча от вендора?
Искать компенсирующие меры: сегментация сети, ужесточение правил межсетевого экрана, отключение ненужных функций, усиленный мониторинг аномалий.
5. Как мотивировать разработчиков быстрее закрывать уязвимости в коде?
Только болью. Показывайте метрики инцидентов, которые произошли из-за неустранённых дефектов. Привлекайте руководство. Денежные мотивации тоже работают, но не везде бюджет позволяет.
6. Стоит ли участвовать в программах bug bounty?
Если есть бюджет — да. Это один из самых эффективных способов найти проблемы до того, как их найдут злоумышленники. Но будьте готовы к потоку отчётов, многие из которых окажутся дубликатами или невалидными.
7. Какие российские решения по управлению уязвимостями вы можете порекомендовать?
Я бы обратил внимание на продукты Positive Technologies, «Кода Безопасности», UserGate. Но каждый случай индивидуален — нужно тестировать под свои задачи.
8. Как оценить зрелость процесса управления уязвимостями в компании?
Посмотрите на среднее время закрытия критических уязвимостей. Если оно больше месяца — процесс незрелый. Если неделя — терпимо. Если сутки — молодцы.
9. Что важнее: профилактика или реагирование?
Без профилактики реагирование превращается в бесконечный пожар. Без реагирования профилактика бессмысленна, потому что вы всё равно пропустите атаку. Нужно и то, и другое.
10. Реально ли защититься от всех атак через уязвимости?
Нет. Абсолютной защиты не существует. Можно только снизить риски до приемлемого уровня. Смиритесь с этим и выстраивайте защиту так, чтобы атака была обнаружена до того, как случится катастрофа.
Что нас ждёт в 2026-2027? 🕐
Если смотреть в будущее, то тренды уже видны.
Во-первых, количество уязвимостей будет расти, но темпы роста замедлятся. Просто потому что конечное число ошибок в коде не бесконечно.
Во-вторых, роль threat intelligence вырастет колоссально. Кто быстрее получит информацию о реальной эксплуатации, тот и выиграл.
В-третьих, нас ждёт бум автоматизированной проверки кода на этапе разработки (DevSecOps). Чем раньше найдена ошибка, тем дешевле её исправление.
В-четвертых, регуляторы будут ужесточать требования. 152-ФЗ, 187-ФЗ, приказы ФСТЭК — никуда не денутся. Готовьтесь к ещё большему количеству бумажек и проверок.
И последнее. Самое главное в управлении уязвимостями — это люди. Не технологии, не сканеры, не регламенты. А люди, которые сидят в SOCе, которые умеют анализировать, сопоставлять, принимать решения под давлением.
Инвестируйте в людей. Учите их. Платите им достойно. Создавайте условия, чтобы они не выгорали через полгода. И тогда даже 100 000 уязвимостей в год не будут страшны.
══════
Больше материалов: Центр знаний SecureDefence.
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]