Сканер нашел на сервере 38 уязвимостей, пять из них получил оценку «критическая». Значит ли результат, что сервер можно взломать? Не обязательно. Пентестер за два дня проник во внутреннюю сеть через одну ошибку. Значит ли успешная атака, что специалист проверил все остальные уязвимости? Тоже нет.
Сканирование уязвимостей и пентест, то есть тестирование на проникновение, отвечают на разные вопросы. Сканирование помогает систематически находить известные или распознаваемые технические слабости на большом числе ресурсов. Пентест проверяет сопротивляемость конкретной системы активной атаке и показывает, какие слабости можно превратить в работающий сценарий компрометации. NIST рассматривает сканирование уязвимостей и тестирование на проникновение как разные методы технической оценки безопасности.
Поэтому выбирать победителя между двумя подходами бессмысленно. Зрелая защита использует автоматические проверки постоянно или регулярно, а ручное тестирование подключает там, где нужны глубина, контекст и проверка реальных путей атаки. У компании с ограниченным бюджетом порядок действий зависит от состояния инфраструктуры и вопроса, на который требуется ответ.
Сначала разберемся с терминами
Сканирование уязвимостей часто смешивают с полноценной оценкой уязвимостей. Разница не академическая. Сканирование представляет собой автоматизированный технический этап. Инструмент обнаруживает узлы и службы, собирает сведения о программном обеспечении, отправляет проверочные запросы и ищет признаки известных слабостей. Оценка уязвимостей шире и может включать ручную проверку результатов, определение приоритета, анализ риска и контроль исправлений.
Сами сканеры тоже сильно различаются. Инфраструктурный сканер исследует серверы, рабочие станции, сетевые устройства, открытые порты, версии служб, параметры шифрования и конфигурацию. Сканер веб-приложений взаимодействует с сайтом или программным интерфейсом через HTTP и пытается обнаружить инъекции, ошибки аутентификации, проблемы управления доступом и другие дефекты приложения. Облачные среды и контейнерные платформы требуют собственных типов проверок.
Пентест строится иначе. Команда получает согласованную область проверки, модель предполагаемого нарушителя, разрешенные методы и ограничения. Специалисты применяют автоматические инструменты, но не останавливаются на их отчете. Они проверяют гипотезы вручную, анализируют права и бизнес-логику, ищут обходные пути, комбинируют слабости и в допустимых пределах подтверждают последствия эксплуатации.
Как работает сканирование уязвимостей
Представим сервер с открытыми портами 22 и 443. Сканер определяет доступные службы, пытается установить используемые продукты и версии, проверяет настройки протоколов, сертификаты и другие параметры. Затем инструмент сопоставляет сведения с базой известных уязвимостей либо выполняет безопасную техническую проверку, которая подтверждает наличие конкретной проблемы.
Проверка без учетной записи показывает сервер примерно так, как его видит удаленный пользователь. Проверка с учетными данными способна заглянуть глубже. Инструмент получает сведения об установленных пакетах, исправлениях и локальной конфигурации, поэтому часто точнее определяет состояние системы. Слова «мы все просканировали» мало что значат без уточнения области, типа и глубины проверки.
Сильная сторона автоматизации заключается в повторяемости. Один и тот же набор ресурсов можно проверять после обновлений, появления новых уязвимостей или изменения инфраструктуры. Сотни и тысячи однотипных технических проверок машина выполняет гораздо быстрее человека. Поэтому сканирование хорошо подходит для постоянного управления уязвимостями, но один отчет сканера еще не превращается в полноценную систему управления риском.
Почему пять критических уязвимостей не обязательно опаснее одной средней
Самая частая ошибка при чтении отчетов заключается в механической сортировке по CVSS, системе оценки технической серьезности уязвимостей. Высокий балл говорит о свойствах самой уязвимости, но не знает всей обстановки конкретной компании. Система может быть недоступна из опасного сегмента, уязвимая функция может не использоваться, эксплуатацию может блокировать дополнительная защита.
Встречается обратная ситуация. Ошибка со скромной оценкой находится на доступном из интернета сервере, для нее уже существует рабочий способ эксплуатации, а сам сервер открывает путь к критичной инфраструктуре. Практический приоритет такой проблемы может оказаться выше. Поэтому современная работа с уязвимостями учитывает не только CVSS, но и доступность ресурса, ценность системы, наличие рабочего кода эксплуатации, факты атак и действующие средства защиты.
Для дополнительного приоритета специалисты используют, например, каталог реально эксплуатируемых уязвимостей CISA KEV и EPSS, систему прогнозирования вероятности эксплуатации опубликованной CVE в ближайшие 30 дней. Ни один показатель сам по себе не дает готовую оценку риска конкретной организации. Хорошая очередь исправлений появляется только после соединения технической опасности с контекстом инфраструктуры.
Что пентестер увидит там, где сканер может пройти мимо
Допустим, интернет-магазин позволяет пользователю открыть заказ по адресу с числовым идентификатором. Покупатель меняет номер заказа в запросе, и сервер возвращает документ другого клиента. Программное обеспечение может быть полностью обновлено, а стандартный инфраструктурный сканер покажет чистый результат. Проблема находится не в версии библиотеки, а в логике проверки прав.
Специалист исследует поведение приложения дальше. Возможно, тот же идентификатор работает в функции загрузки счета, возврата товара или изменения адреса. Одна ошибка контроля доступа превращается в возможность массово читать или менять чужие данные. Для обнаружения цепочки недостаточно просто сравнить версии программ с каталогом CVE.
Человеческий анализ особенно полезен при сложном разграничении прав, многошаговых операциях, восстановлении доступа, работе программных интерфейсов, нестандартной бизнес-логике и соединении нескольких слабостей. Хороший пентест проверяет не только наличие «дыр», но и маршрут атаки. Где нарушитель войдет, сможет ли повысить права, перейти на соседнюю систему и какой ущерб способен причинить.
Но пентест тоже ничего не гарантирует
Название «тестирование на проникновение» иногда создает опасную иллюзию полного экзамена. Пентест всегда ограничен временем и областью работ. Если подрядчику дали десять рабочих дней на большое приложение, специалист физически не проверит каждую комбинацию функций, ролей и входных данных. Закрытая от тестеров система вообще останется вне исследования.
На результат влияет и формат проверки. При «черном ящике» специалисты получают минимум сведений и имитируют внешнего нарушителя. Подход хорошо показывает взгляд атакующего, но часть времени уходит на разведку, поэтому некоторые внутренние слабости могут остаться незамеченными. При «белом ящике» команда получает архитектуру, учетные записи или другую внутреннюю информацию и тратит больше времени непосредственно на анализ. Между крайностями существует множество промежуточных вариантов.
Пентест также представляет собой снимок состояния системы в конкретный период. Завтра разработчик выкатит новую функцию, администратор изменит сетевое правило или исследователи опубликуют новую уязвимость. Вчерашний отчет не защищает от завтрашней ошибки. Поэтому ежегодный пентест без постоянного управления уязвимостями дает скорее чувство контроля, чем сам контроль.
Главные различия на практике
| Критерий | Сканирование уязвимостей | Пентест |
|---|---|---|
| Главный вопрос | Какие известные или распознаваемые слабости присутствуют | Какие слабости можно превратить в реальную атаку |
| Основной метод | Автоматические проверки | Ручной анализ с автоматическими инструментами |
| Масштаб | Хорошо подходит для большого числа ресурсов | Работает в ограниченной согласованной области |
| Повторяемость | Можно регулярно запускать один набор проверок | Результат сильнее зависит от специалистов и сценария |
| Известные уязвимости ПО | Одна из сильных сторон | Используются как возможная часть маршрута атаки |
| Ошибки бизнес-логики | Автоматизация видит лишь часть таких проблем | Ручная проверка значительно эффективнее |
| Цепочки атак | Возможности ограничены | Одна из главных ценностей ручной работы |
| Эксплуатация | Часть проверок только определяет признаки проблемы | Выбранные слабости подтверждаются в разрешенных пределах |
| Стоимость одной проверки | Обычно ниже после внедрения инструмента | Выше из-за квалифицированной ручной работы |
| Типичный результат | Множество находок для проверки и исправления | Подтвержденные проблемы, последствия и маршруты атаки |
Чего сканер не умеет и почему ложные результаты неизбежны
Автоматический инструмент принимает решение по правилам и доступным данным. Иногда сканер определяет версию продукта по баннеру и связывает ее с известной уязвимостью, хотя производитель уже перенес исправление в старую ветку программы. Получается ложное срабатывание. В другом случае сервер скрывает версию или защитное средство блокирует проверочный запрос, и реальная проблема остается незамеченной.
Сканирование веб-приложений добавляет другие ограничения. Автоматике трудно разобраться в необычном процессе покупки, распределении полномочий между несколькими ролями, одноразовых операциях и функциях, где опасность возникает только после определенной последовательности действий. Сканер может обнаружить отдельные признаки ошибки контроля доступа, но человеческое понимание логики по-прежнему дает преимущество.
Поэтому качество сканирования зависит не только от выбранного продукта. Нужно правильно определить ресурсы, дать инструменту нужный сетевой доступ, настроить учетные данные, выбрать профиль проверки и следить за обновлением базы правил. Самый дорогой сканер бесполезен против сервера, о существовании которого команда безопасности не знает.
Инвентаризация иногда важнее еще одного сканера
Забытый тестовый сервер с открытым административным интерфейсом может представлять больший риск, чем десятки аккуратно контролируемых рабочих систем. Проблема проста. Нельзя исправить уязвимость на ресурсе, который отсутствует в реестре и не попадает в область проверки.
Поэтому нормальный процесс начинается не со знаменитого продукта и красивой панели, а с понимания собственной инфраструктуры. Нужно знать внешние адреса, домены и поддомены, облачные ресурсы, приложения, программные интерфейсы, сетевое оборудование и владельцев систем. Динамические облачные среды усложняют задачу, поскольку ресурсы появляются и исчезают гораздо быстрее традиционных серверов.
Сканер помогает находить неизвестные узлы, но не заменяет учет ресурсов. Если организация проверяет только заранее составленный перечень адресов, любой забытый адрес автоматически выпадает из контроля. Поэтому управление внешней поверхностью атаки и инвентаризация хорошо дополняют классическое сканирование уязвимостей.
Когда выбирать сканирование
Начинать со сканирования разумно, если компания никогда системно не проверяла инфраструктуру. Заказывать дорогой пентест сервера, где годами не ставили исправления и наружу торчит ненужная административная служба, обычно невыгодно. Специалист быстро найдет очевидные проблемы, за обнаружение которых дешевле заплатить автоматике.
Сканирование также подходит для постоянного контроля большой среды. Новые уязвимости появляются между пентестами, а сама инфраструктура меняется после обновлений и развертывания новых систем. Автоматические проверки можно запускать по расписанию, после изменений или при появлении особенно опасной уязвимости.
Хороший процесс не заканчивается выдачей PDF. Находка попадает ответственному сотруднику, приоритет учитывает риск, команда исправляет проблему, затем выполняет повторную проверку. Если никто не исправляет результаты, еженедельный скан лишь производит еженедельную коллекцию одинаковых проблем.
Когда нужен пентест
Пентест нужен, когда вопрос звучит не «какие у нас CVE», а «сможет ли атакующий получить доступ и что произойдет дальше». Проверка особенно полезна перед запуском критичного веб-приложения, программного интерфейса, удаленного доступа, новой сетевой архитектуры или системы, которая хранит ценные данные.
Еще один хороший момент появляется после устранения массовых технических проблем. Сканеры убрали очевидный «шум», и специалисты могут потратить оплачиваемое время на сложные сценарии, проверку разграничения доступа, повышение привилегий, обход защитных механизмов и переход между системами.
Пентест полезен и как независимая проверка работы процесса управления уязвимостями. Если подрядчик регулярно находит десятки элементарных проблем, которые внутренние сканеры должны были увидеть раньше, вопрос возникает уже не только к конкретным серверам. Возможно, компания неправильно определяет область сканирования, использует плохие настройки или не успевает исправлять найденное.
Почему стандарты не считают пентест и сканирование взаимозаменяемыми
Хороший пример дает индустрия платежных карт. На август 2026 года актуальной опубликованной редакцией остается PCI DSS 4.0.1. Стандарт отдельно регулирует сканирование уязвимостей и тестирование на проникновение. Сам факт разделения хорошо показывает, что процедуры закрывают разные задачи. PCI SSC продолжает публиковать PCI DSS 4.0.1 как текущую версию, хотя в 2026 году совет уже собирал предложения для следующей редакции.
Для систем, на которые распространяются соответствующие требования, внешнее сканирование по пункту 11.3.2 проводится как минимум раз в три месяца с привлечением одобренного PCI SSC поставщика сканирования. Внутреннее и внешнее тестирование на проникновение регулируется отдельными требованиями 11.4 и проводится как минимум раз в 12 месяцев, а также после существенных изменений инфраструктуры или приложений. Найденные эксплуатируемые проблемы требуется исправить и проверить повторно.
Из требований нельзя выводить универсальный календарь для любой компании. «Раз в квартал» и «раз в год» в данном случае относятся к конкретному стандарту и его области действия. Организация с ежедневными изменениями интернет-сервиса может нуждаться в более частых автоматических проверках и дополнительных пентестах после крупных релизов.
Почему пентест не должен превращаться в соревнование со сканером
Плохая закупка выглядит знакомо. Подрядчику передают несколько адресов, через пару дней приходит документ на 150 страниц с перечнем портов, версий программ, номеров CVE и стандартных рекомендаций. Большая часть текста автоматически сгенерирована инструментом. На обложке при этом красуется слово «пентест».
Количество страниц ничего не говорит о глубине работы. Перед проектом заказчик должен понимать модель нарушителя, область проверки, выданные доступы, роли пользователей, разрешенную эксплуатацию и запрещенные действия. Для веб-приложения полезно заранее определить, проверят ли горизонтальное и вертикальное разграничение прав, бизнес-логику, программные интерфейсы и разные типы учетных записей.
В хорошем отчете существенная находка содержит условия возникновения проблемы, понятный способ воспроизведения, подтвержденное влияние и рекомендации. Если эксплуатация могла повредить рабочую систему, специалисты должны выбрать безопасный способ доказательства либо согласовать действия отдельно. Пентест не дает лицензии ломать рабочую инфраструктуру ради эффектного скриншота.
Что спросить у подрядчика до покупки пентеста
Техническое задание лучше обсуждать до подписания договора. Формулировка «проверить сайт на безопасность» оставляет слишком много пространства для разных трактовок. Две компании могут назвать пентестом совершенно разный объем работы и выставить несопоставимые цены.
Особенно опасно сравнивать предложения только по числу IP-адресов и человеко-дней. Для простого сетевого периметра такой расчет еще дает ориентир. В сложном приложении одна роль пользователя может открыть десятки функций, а одна интеграция с внешним сервисом полностью изменить модель угроз.
- Какие системы и приложения входят в область проверки?
- Какую модель нарушителя имитирует команда?
- Будут ли тестировщикам выданы учетные записи разных ролей?
- Какие автоматические и ручные методы планируется применять?
- Будут ли специалисты подтверждать эксплуатацию найденных проблем?
- Проверят ли бизнес-логику и цепочки из нескольких слабостей?
- Какие действия запрещены из-за риска повредить рабочую систему?
- Что войдет в отчет и можно ли воспроизвести находки по его описанию?
- Входит ли повторная проверка после исправления серьезных проблем?
Что делать, если денег хватает только на одну проверку
Для давно работающей инфраструктуры без регулярного управления уязвимостями первым вложением чаще становится не пентест, а инвентаризация и сканирование. Нужно найти очевидные слабости, исправить критичные проблемы и настроить повторные проверки. Иначе значительная часть дорогого времени пентестера уйдет на работу, которую могла выполнить автоматика.
Если перед компанией находится конкретная новая система и требуется понять реальную возможность компрометации, преимущество смещается в сторону пентеста. Особенно когда приложение использует собственную бизнес-логику, несколько ролей, чувствительные данные или сложные интеграции. Обычный перечень известных CVE не даст полноценного ответа на такой вопрос.
Выбор можно свести к простой формуле. Вопрос «где у нас массовые и известные технические слабости» ведет к сканированию. Вопрос «каким путем нас реально могут атаковать и до чего добраться» ведет к пентесту. После первого этапа зрелости развилка исчезает, поскольку компании нужны оба процесса.
Рабочая схема для большинства компаний
Сначала организация составляет и поддерживает реестр ресурсов. Затем подключает подходящие типы сканеров, проверяет инфраструктуру регулярно и связывает находки с процессом исправления. Приоритет определяют не только по красивому красному значку «Critical», но и по доступности ресурса, ценности системы и реальной активности злоумышленников.
Для критичных приложений и важных участков инфраструктуры периодически проводят ручное тестирование на проникновение. Дополнительный пентест имеет смысл после существенных архитектурных изменений, а после исправления серьезных находок нужна повторная проверка. Сканирование продолжает работать между такими проектами.
Главное различие можно сформулировать совсем коротко. Сканирование дает ширину и регулярность, пентест дает глубину и контекст. Сканер помогает увидеть множество потенциально слабых дверей. Пентестер проверяет, какие двери действительно открываются, можно ли пройти дальше и что окажется за ними. Ни один подход не заменяет второй, потому что защищают они от разных видов слепоты.