Привет, Хабр! Меня зовут Артем, я являюсь руководителем центра технической экспертизы по анализу защищенности в AKTIV.CONSULTING. Сегодня я хочу затронуть тему поиска уязвимостей программного обеспечения при эксплуатации и разобраться, чем это является на практике: базовым минимумом или все-таки роскошным максимумом. Ориентироваться будем на 24 процесс ГОСТ Р 56939-2024 по разработке безопасного программного обеспечения (БРПО, РБПО, DevSecOps).
Три кита БРПО (РБПО)
Для начала давайте вспомним три основных метода анализа уязвимостей ПО: статический, динамический и композиционный. Статический — это анализ исходного кода (тестирование «белым ящиком»). Динамический анализ — классический пентест, когда мы тестируем уже работающее приложение в «черном» или «сером» ящике. Композиционный анализ — сканирование и поиск уязвимостей в используемых компонентах, что позволяет расширить поверхность атаки.
Но просто знать эти методы мало, важно понимать, кто и как их будет применять на практике, а также что лучше использовать: автоматизированные сканеры уязвимостей или живых специалистов. Давайте разбираться.
Автоматизированный и ручной поиск: как провести анализ уязвимостей ПО
На мой взгляд, в современных реалиях автоматизированный поиск уязвимостей является базовым необходимым минимумом. Еще 3-4 года назад для меня, как для пентестера, такое заявление было бы неприемлемым, но мир изменился. Сегодня сканеры уязвимостей серьезно выросли, научились находить реальные проблемы и покрывают огромный пласт задач. В прошлой статье на Хабре я делал подборку таких сканеров. Ими может воспользоваться любой пентестер при аудите инфраструктуры и внешнего периметра.
Однако важна точная настройка инструментов, ведь при неумелом или слишком интенсивном их использовании можно навредить своей же системе. Сканерами нужно пользоваться аккуратно, грамотно подбирая параметры, или доверить это профессионалам.
В идеале автоматизированный поиск уязвимостей должен приводить к двум составляющим:
1. Пентест-континьюс (Pentest Continious)
Регулярное сканирование системы или ПО в автоматизированном режиме с формированием отчета, который показывает динамику (какие новые уязвимости появились, какие порты открылись, что изменилось в ПО и т.п.)
2. Мониторинг (SOC)
Отслеживание как новых уязвимостей, так и тех, что могут использоваться для атак на ваше ПО и информационную систему. Это дает актуальную картину угроз в реальном времени.
И если автоматизированный поиск уязвимостей мы называем необходимым минимумом, то ручной поиск уязвимостей можем считать роскошным максимумом. Квалифицированных специалистов на рынке мало, и их работа стоит дорого. Таких экспертов привлекают не для галочки, а для реальной проверки безопасности ПО.
По своему опыту могу сказать, что такие специалисты часто находят то, что было упущено даже у тех заказчиков, которые серьезно занимаются информационной безопасностью. Важно помнить, что полностью защищенных систем не бывает (разве что компьютер в бункере без интернета). Опыт, критическое мышление и смекалка пентестера позволяют выстроить цепочки атак так, чтобы в итоге достигнуть нужных результатов доступа к информации или системе.
Этапы анализа уязвимостей ПО: как OWASP TOP-10 может помочь
Процесс тестирования на уязвимости можно разделить на четыре ключевых этапа:
Разведка
На этом этапе важно понять, что мы атакуем, и найти все потенциальные точки входа, то есть максимально расширить поверхность атаки.
Поиск уязвимостей
После получения результатов разведки мы ищем уязвимости, опираясь на версии ПО, базу данных общеизвестных уязвимостей информационной безопасности (CVE) и личный опыт.
Эксплуатация уязвимостей и проведение атак
Здесь мы верифицируем найденные уязвимости и пытаемся их использовать, а именно проникнуть вглубь системы, расшириться на смежные узлы, повысить привилегии и т.д.
Отчет
Важнейший этап, ценность которого заключается в рекомендациях. В отчете присутствуют как общие советы по улучшению безопасности ПО и информационной системы, так и конкретные меры для каждой найденной уязвимости.
Для описания основных уязвимостей давайте возьмем OWASP TOP-10. Хотя данный список уязвимостей создан для веба, все описанные проблемы характерны для большинства видов ПО:
A01:2025 Нарушение контроля доступа
A02:2025 Неправильная конфигурация системы безопасности
Обе эти проблемы несколько похожи и часто возникают из-за неверных настроек ПО.
A03:2025 Сбои в цепочке поставок ПО
Поскольку любое ПО состоит из нескольких компонентов, заражение одного из них в процессе разработки может привести к уязвимости ПО в целом.
A04:2025 Криптографические сбои
Тут речь идет об ошибках в шифровании и настройках SSL.
A05:2025 Внедрение вредоносного ПО
A06:2025 Небезопасный дизайн
A07:2025 Сбои аутентификации
Некорректная настройка или возможность обойти механизмы входа.
A08:2025 Сбои целостности ПО или данных
A09:2025 Сбои ведения журнала безопасности и в оповещениях
Если происходит сбой или журналы безопасности настроены неверно, события атак могут остаться незамеченными.
A10:2025 Неправильная обработка исключительных условий
Это мой любимый пункт, потому что разработчики не всегда учитывают, как система поведет себя в крайних ситуациях. Такие недочеты часто дают доступ к памяти и другим ресурсам.
Как внедрить процесс поиска уязвимостей
Внедрение процесса поиска уязвимостей при эксплуатации является сложной задачей. Одна из главных трудностей — донести до разработчиков новые обязанности и необходимость этих действий. Возникает вопрос: кому доверить работу по внедрению? Есть два основных пути:
Во-первых, Security Champion — человек из команды разработки, который заинтересован в безопасности, «горит» этой идеей. Он обучается и внедряет процессы защиты на этапе создания ПО, стараясь минимизировать количество уязвимостей. Во-вторых, консалтинг, т.е. привлечение внешних пентестеров.
В чем разница между Security Champion и пентестером? У них принципиально разное мышление. Пентестер любит решать головоломки, и поиск уязвимостей для него превращается в квест с элементами деструктива (найти, сломать, проникнуть). Security Champion же своего рода строитель. Его задачей становится создание некой «крепости» и предотвращение уязвимостей еще на этапе разработки.
Ни тот, ни другой подход не идеален. Нельзя исключать человеческий фактор, поэтому рекомендую использовать совокупность методов. Пусть Security Champion выстраивает процессы внутри компании, а внешние пентестеры на финальном этапе ищут то, что было упущено, донастраивают систему и делятся опытом с внутренним специалистом.
Кейсы из практики
В завершение приведу несколько ярких и показательных примеров из моей практики.
Кейс 1. Внедрение БРПО (РБПО) у крупного вендора СЗИ
Заказчик сам инициировал внедрение процессов по ГОСТ, понимая, что стандарт пока не обязателен. Несмотря на это, от постановки задачи до создания рабочей группы прошло достаточно много времени. Этот случай показал, что даже при готовности бизнеса внедрение требует терпения и времени на решение организационных вопросов.
Кейс 2. Внедрение безопасной разработки ПО после инцидента
Крупный вендор начал внедрять процессы БРПО (РБПО) только после того, как у него произошел реальный инцидент. Ситуация заставила компанию переосмыслить подход к безопасности и показала важность ИБ. Но лучше все же не дожидаться такого случая, а брать пример с первого кейса.
Кейс 3. Пентест торговой системы
При тестировании крупной торговой системы мы столкнулись с интересной ситуацией. На первом прогоне при сканировании и анализе ни один автоматизированный сканер не нашел уязвимостей. Ни высокого, ни среднего, ни низкого уровня. Заказчик был уверен в своей защите и убежден, что мы ничего не найдем. Однако на этапе ручного исследования я обнаружил около 10 уязвимостей среднего и низкого уровня. По отдельности они казались неопасными, но комбинация пяти из них позволила выстроить полноценный вектор атаки и полностью скомпрометировать информационную систему. Этот случай наглядно показывает, почему важно обращать внимание на уязвимости любого уровня риска и ответственно подходить к их закрытию.
Итог
Автоматизированный поиск уязвимостей сегодня является базовым необходимым минимумом, который должен быть грамотно настроен и работать на постоянной основе. Но полагаться только на сканеры не стоит: ручной поиск силами опытных специалистов остается роскошным максимумом, который позволяет найти то, что было упущено. Оптимальным вариантом будет сочетание регулярного автоматизированного поиска и привлечения пентестеров для тщательного анализа уязвимостей. Такой комплексный подход даст наиболее точную оценку защищенности вашего программного обеспечения. Памятку по анализу защищенности можно найти тут.