ВойтиПрограммы для анализа уязвимостей
Дверь, которую забыли закрыть
Проверять каждую дверь вручную невозможно. В корпоративной сети могут работать тысячи узлов, а в проекте с открытым кодом десятки тысяч зависимостей. Поэтому защитники автоматизировали поиск слабых мест, и появился целый класс инструментов, которые делают это без устали и по расписанию.
Чтобы понять, чем такие инструменты полезны, стоит разобраться, что они ищут и как принимают решения. Обычная программа для анализа уязвимостей не «взламывает» систему и не угадывает наугад. Она сверяет то, что обнаружила (версии программ, открытые порты, параметры конфигурации), с базами известных проблем и проверяет, есть ли совпадения. Результат приходит в виде отчёта: где найдена брешь, насколько она опасна и что с ней делать.
SolidPoint
Программа для анализа уязвимостей SolidPoint — единственная DAST-платформа, совмещающая динамический анализ приложений с продвинутым статическим анализом JavaScript-кода клиентской части. Исследования показывают: эта система обнаруживает до 40% больше конечных точек (эндпоинтов), чем традиционные инструменты. Как результат - полная видимость поверхности атаки при отсутствии ложных срабатываний.
На чём держится поиск: базы и шкалы
Инструменты опираются на общие справочники. Известные уязвимости получают идентификатор CVE. Это единая система нумерации, которую координирует организация MITRE. Подробные записи, со ссылками и оценками, собраны в Национальной базе уязвимостей США (NVD), которую ведёт NIST. В России параллельно работает Банк данных угроз безопасности информации ФСТЭК России. Отечественные сканеры используют его наравне с международными источниками.
Опасность оценивают по шкале CVSS. Её разработал международный форум FIRST, а баллы в ней идут от 0 до 10. Уязвимость в библиотеке Log4j, известная как Log4Shell (CVE-2021-44228), получила максимальные 10,0. Причина в том, что её можно эксплуатировать удалённо, без сложных условий, и она даёт возможность выполнить чужой код на сервере.
Одного балла CVSS всё же недостаточно. Уязвимость с высокой оценкой может сидеть на сервере, до которого никто извне не доберётся. А «средняя» окажется на публичном сайте, и именно её активно используют. Поэтому в отчётах всё чаще учитывают и другие сигналы. Один из них EPSS, оценка вероятности того, что брешь начнут эксплуатировать. Другой каталог KEV агентства CISA. В нём собраны уязвимости, которые уже применяют в реальных атаках.
Какие бывают программы и что каждая видит
Единого сканера «на все случаи» не существует. Инструменты делятся по тому, на какой объект они смотрят.
- Сетевые сканеры проверяют серверы, рабочие станции и сетевое оборудование: открытые порты, версии служб, отсутствие обновлений. Среди известных примеров Nessus от компании Tenable, OpenVAS (входит в проект Greenbone), Qualys, а из российских решений MaxPatrol VM от Positive Technologies и RedCheck от «АЛТЭКС-СОФТ».
- Сканеры веб-приложений имитируют действия посетителя сайта и проверяют формы, параметры и заголовки на типовые ошибки вроде SQL-инъекций и межсайтового скриптинга. Здесь используют OWASP ZAP, Burp Suite и Nikto.
- Инструменты анализа кода (SAST) читают исходники, не запуская приложение. Такие задачи решают SonarQube и Semgrep.
- Анализаторы состава ПО (SCA) разбирают зависимости проекта и сверяют их с базами известных уязвимостей. Этим занимаются Snyk и Dependabot.
- Сканеры контейнеров и облачной инфраструктуры проверяют образы и конфигурации, например Trivy.
- Инструменты разведки вроде Nmap. Он изначально служит для изучения сети, но с помощью встроенных скриптов NSE умеет находить и часть уязвимостей.
Отдельно стоит метод DAST: программа проверяет уже запущенное приложение снаружи. Он дополняет SAST. Первый показывает, что реально доступно атакующему. Второй объясняет, в какой строке кода искать причину.
Как выглядит проверка изнутри
Типичный цикл состоит из нескольких шагов. Сначала сканер обнаруживает узлы и определяет, что на них запущено. Затем он собирает сведения о версиях и настройках. Дальше идёт сравнение с базой, а иногда и безопасная проверка, которая подтверждает, что дыра действительно есть, а не просто предполагается по номеру версии. В конце формируется отчёт, который приоритизирует находки.
Большую роль играет режим сканирования. При проверке «снаружи» программа видит лишь то, что доступно любому прохожему. При проверке с учётными данными она входит в систему и читает реестр, список пакетов и параметры безопасности. Такой подход обычно находит гораздо больше проблем и реже ошибается, потому что не гадает по косвенным признакам.
Ложные срабатывания и слепые зоны
Сканер не всегда прав. Ложное срабатывание возникает, когда программа сообщает об уязвимости, которой на деле нет. Например, разработчики дистрибутива могли исправить проблему в пакете, не меняя номер версии, и сканер, глядя лишь на номер, поднимает тревогу. Бывает и обратное: уязвимость есть, а инструмент её не заметил. Особенно это касается ошибок в бизнес-логике. Сканер не поймёт, что интернет-магазин позволяет изменить цену товара в запросе, потому что для него это не нарушение, а обычная работа сайта.
Здесь проходит граница между автоматической проверкой и тестированием на проникновение. Сканер быстро и широко покрывает известные проблемы. Специалист по пентесту действует медленнее, но умеет связывать мелкие недочёты в цепочку и находить то, чего нет ни в одной базе. Эти подходы не заменяют друг друга.
Как выбрать программу и не утонуть в отчётах
Выбирать инструмент стоит по задаче, а не по популярности. Компании с большой сетью нужен сканер, который обходит тысячи узлов и интегрируется с системой учёта активов. Команде разработчиков важнее проверка кода и зависимостей прямо в конвейере сборки, чтобы дыра не дошла до продакшена. Небольшому бизнесу может хватить бесплатного OpenVAS или ZAP, если найдётся человек, который разберётся в настройках.
Есть и вопросы, которые часто упускают из виду. Как часто обновляются базы? Умеет ли программа работать с вашими системами, включая отечественные операционные системы и сертифицированные средства? Соответствует ли она требованиям регуляторов, если они применимы? Насколько понятно она подсказывает, что исправлять в первую очередь?
Последний вопрос самый важный. Отчёт на тысячу страниц без приоритетов почти так же бесполезен, как отсутствие отчёта. Команда, которая тонет в сотнях «критических» находок, начинает их игнорировать. Поэтому зрелый процесс строится не вокруг разового запуска, а вокруг регулярного цикла: находить, оценивать, исправлять и проверять, что исправление сработало.
