Тренд сохраняется и в 2026-м: по предварительным данным, за первый квартал новых CVE зарегистрировали примерно на треть больше, чем за тот же период 2025 года. Любая из этих уязвимостей потенциально превращается в точку входа для злоумышленника.

Проблема не только в объёме, но и в скорости. Промежуток между публичным раскрытием уязвимости и началом её эксплуатации за последние годы сжался с недель до считаных дней, а для растущей доли уязвимостей атака начинается ещё до выхода исправления: по данным Mandiant, в 2025 году эксплуатация в среднем опережала выпуск патча. Так было и с Log4Shell, и с ProxyLogon — массовое сканирование интернета в поисках свежей уязвимости разворачивается почти сразу после её обнаружения. Вручную отследить, какой из сотен программных компонентов в инфраструктуре только что стал уязвимым, физически невозможно.

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

Что такое сканер уязвимостей и чем он отличается от пентеста

Сканер уязвимостей — это программное средство, которое автоматически обследует ИТ-систему (серверы, сетевое оборудование, веб-приложения, СУБД, рабочие места) и сравнивает её состояние с базами известных уязвимостей и эталонными профилями безопасной конфигурации. По сути, он ищет то, что уже кому-то известно и описано, но пока не закрыто именно у вас.

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

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

Как это работает: CVE, CVSS и базы уязвимостей

В основе любого сканера лежат базы данных уязвимостей. Каждая публично известная уязвимость получает уникальный идентификатор — CVE (Common Vulnerabilities and Exposures). Реестр ведёт организация MITRE через сеть аккредитованных участников; идентификатор выглядит как CVE-2024-XXXXX, где указаны год регистрации и порядковый номер. Это единый язык, который убирает путаницу при описании одной и той же проблемы.

Записи обогащаются в базе NVD (National Vulnerability Database) и получают оценку критичности по шкале CVSS (Common Vulnerability Scoring System) — от 0 до 10. Эта оценка позволяет расставить приоритеты: сначала закрывать критичное, потом остальное. В России действует и собственная база — БДУ ФСТЭК (банк данных угроз), учёт которой обязателен при моделировании угроз для систем персональных данных, государственных информационных систем и объектов критической информационной инфраструктуры.

Работают сканеры с машиночитаемым контентом — стандартом SCAP и языком описания проверок OVAL. Базы обновляются ежедневно, и это ключевой момент: сканер полезен ровно настолько, насколько актуальны его базы. Вчерашняя база не увидит уязвимость, опубликованную сегодня утром.

Виды сканирования

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

По объекту проверки

• Сеть — периметр и внутренние сегменты: открытые порты, небезопасные протоколы, правила межсетевого экранирования, ошибки сегментации.

• Веб-приложения — формы, авторизация, API: устойчивость к SQL-инъекциям, XSS, CSRF, обходу аутентификации, раскрытию информации.

• Хосты и операционные системы — Windows, Linux и другие: наличие критических обновлений, версии служб, корректность прав доступа.

• СУБД и серверы приложений — здесь хранится самое чувствительное, поэтому важен контроль конфигурации и своевременная установка патчей.

• Конфигурации и соответствие — проверка настроек на соответствие эталонным профилям безопасности и требованиям стандартов.

По расположению источника

• Внешнее сканирование — взгляд со стороны интернета: показывает, что видит внешний злоумышленник на периметре и какие сервисы доступны извне.

• Внутреннее сканирование — изнутри сети: показывает, куда сможет добраться атакующий, если скомпрометирует один из хостов.

По наличию учётных данных

• Без аутентификации — режим «чёрного ящика» с минимальными знаниями о системе; имитирует внешнего атакующего и видит только то, что открыто наружу.

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

По воздействию на систему

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

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

Сканирование и требования регуляторов

Для организаций, которые подпадают под регулирование, сканирование — не только гигиена, но и часть соответствия закону. Методики ФСТЭК и требования 152-ФЗ предполагают регулярную оценку защищённости и анализ уязвимостей: их результаты используются при моделировании угроз и при аттестации информационных систем.

Здесь принципиальны два момента. Во-первых, чтобы протокол сканирования имел вес для регулятора, само средство сканирования должно иметь сертификат ФСТЭК. Во-вторых, базы уязвимостей должны включать БДУ ФСТЭК, а не только международные CVE. Организовать это внутри компании реально, но требует выделенного сервера, настройки сканера, ежедневного обновления баз и — главное — квалифицированного специалиста, который интерпретирует сотни находок. Поэтому многие компании берут сканирование как готовую услугу.

Организовать это можно и своими силами, и как готовую услугу по анализу уязвимостей — такой формат предлагают, в частности, российские облачные провайдеры (например, Cloud4Y). В этом случае сканирование ведётся сертифицированным ФСТЭК инструментом по базам, включающим БДУ ФСТЭК, а итоговый протокол с оценкой по CVSS подходит для аттестации и отчётности по 152-ФЗ.

Как часто сканировать и как встроить это в процесс

Сканирование — не разовое действие, а цикл, который в отрасли называют управлением уязвимостями: инвентаризация активов, сканирование, приоритизация находок по CVSS, устранение, повторная проверка для подтверждения, что уязвимость действительно закрыта.

Практический ориентир по периодичности — не реже раза в неделю и после каждого существенного изменения в инфраструктуре: обновления ПО, смены конфигурации, ввода новых сервисов. Причина проста: новые CVE появляются ежедневно, а эксплуатация всё чаще начинается в первые же дни после раскрытия — разовая проверка «раз в год» практического смысла уже не имеет. Ценность здесь не в самом списке «дыр», а в их закрытии: хороший отчёт даёт не только перечень находок, но и конкретные шаги, а повторное сканирование подтверждает, что исправление сработало.

На что смотреть при выборе решения или услуги

Чтобы сканирование приносило пользу, а не создавало иллюзию защищённости, стоит проверить несколько вещей:

• Сертификация — если нужна регуляторика (152-ФЗ, требования ФСТЭК, ГИС), сканер и его протоколы должны иметь вес для регулятора, иначе результат не примут при аттестации.

• Актуальность баз — ежедневное обновление и наличие БДУ ФСТЭК наряду с международными CVE и NVD.

• Глубина проверки — поддержка сканирования с аутентификацией, а не только внешний осмотр периметра.

• Покрытие — сеть, веб-приложения, ОС, СУБД, среда виртуализации, конфигурации — а не один тип объектов в отрыве от остальных.

• Приоритизация и рекомендации — оценка по CVSS и понятный план действий вместо тысячи строк лога.

• Повторная проверка — возможность подтвердить, что найденное действительно устранено.

• Влияние на прод — безопасные методы зондирования, режим пассивного сканирования для критичных систем и согласование окна проверки.

Итог

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