Поиск уязвимостей

По данным исследования «Солар», в коде 88% веб-приложений содержатся критические уязвимости, через которые хакеры могут атаковать информационные системы компании. Если начать поиск таких брешей с первых этапов разработки, выше шансы представить рынку надежное ПО и соблюсти требования регуляторов. К тому же раннее внедрение методов контроля безопасности позволит ускорить выпуск продуктов на рынок, поскольку не придется экстренно устранять проблемы непосредственно перед релизом. В статье рассказываем, в чем заключается поиск уязвимостей.

Что такое поиск уязвимостей

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

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

Кто занимается поиском уязвимостей в программном обеспечении

Бреши безопасности в ПО ищут инженеры ИБ, пентестеры, а иногда разработчики. У каждого специалиста свои задачи. Разработчики фокусируются на поиске ошибок в коде и недекларированных возможностей, секьюрити-инженеры — на обнаружении устаревших и потенциально уязвимых компонентов, пентестеры — имитируют атаки на системы, чтобы найти их дефекты. Поиском уязвимостей занимаются и хакеры. Они ищут слабые места в приложениях, чтобы затем через них атаковать.

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

Виды уязвимостей в веб-приложениях

OWASP Top 10 — это список наиболее критических уязвимостей веб-приложений и мобильных приложений. Перечислим самые распространенные из них:

• Различные виды инъекций кода.
• XSS (межсайтовый скриптинг).
• Слабая защита конфиденциальных данных.
• Непродуманные механизмы аутентификации.
• Проблемы с контролем доступа.
• Небезопасные конфигурации.

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

Уровни критичности уязвимостей

Поиск уязвимостей предполагает определение уровня критичности обнаруженных проблем для приоритизации их устранения. Выделяют четыре основных уровня:

• Критический. Уязвимости этой категории активно эксплуатируют злоумышленники для атак на информационные системы, что приносит существенный ущерб пользователям ПО.
• Высокий. К этому уровню относятся проблемы безопасности, которые сопряжены с серьезными угрозами конфиденциальности, целостности и доступности информации.
• Средний. Сюда относятся бреши безопасности, эксплуатация которых может принести серьезный ущерб, но использовать такие уязвимости для атаки достаточно сложно.
• Низкий. Этот уровень характеризует уязвимости, эксплуатация которых не приносит серьезного вреда либо она маловероятна.

Определение уровня критичности недостатков безопасности позволяет правильно оценить риски и понять, какие уязвимости нужно устранить в первую очередь.

Средства поиска уязвимостей

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

Вместо разрозненных инструментов для поиска уязвимостей можно использовать единую технологическую платформу Solar appScreener, которая позволяет комплексно подходить к контролю безопасности ПО и проводить несколько видов тестирований кода из одного интерфейса. Это решение — лидер среди отечественных продуктов по уровню поддержки количества языков программирования и форматов исполняемых файлов (36 языков и 10 форматов), за счет чего оно подходит для анализа любых приложений.

Основные методы поиска уязвимостей

Для комплексного контроля безопасности следует комбинировать разные виды анализа кода и тестирования функциональности приложений. Рассказываем о самых эффективных методах.

Статический анализ кода (Static Application Security Testing)

SAST — самый распространенный вид тестирования ПО, поскольку он может применяться уже на этапе написания кода без запуска программы. Главные преимущества такой проверки:

• Внедрение с первых этапов разработки, когда еще рано проводить другие тестирования.
• Различные методы поиска уязвимостей: синтаксический, лексический, семантический, taint-анализ, анализ графов потока управления и др.
• Возможность практически полностью охватить код и найти максимум проблем безопасности.

Если статическое тестирование проводится с помощью анализатора, возможны ложноположительные срабатывания — False Positive (FP). Они возникают, когда сканер воспринимает истинные условия как уязвимости. Это затрудняет интерпретацию результатов и вынуждает тратить ресурсы на ручную проверку, из-за чего без внимания остаются реальные бреши безопасности. В Solar appScreener проблема FP решается за счет технологии Fuzzy Logic Engine, которая сокращает количество ложноположительных срабатываний.

Для поиска уязвимостей методом статического анализа нужно иметь доступ к исходному коду, но Solar appScreener может проверять бинарный код, например, если ПО разрабатывал подрядчик и исходников нет. Бинарный анализ проводится с применением запатентованной технологии реверс-инжиниринга, которая с высокой точностью восстанавливает исходный код из исполняемых файлов в 10 форматах: JAR, WAR, EAR, AAR, DLL, EXE, APK, AAB, IPA, APP.

Динамическое тестирование — Dynamic Application Security Testing

DAST — метод поиска уязвимостей в программном обеспечении, которое уже выпущено. В связи с этим на первых этапах разработки такое тестирование не проводится.

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

• Проверка ПО без доступа к исходному коду.
• Меньше False Positive, чем при статическом анализе.
• Получение детальной картины уязвимостей при проведении комплексного анализа SAST+DAST.

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

Анализ сторонних компонентов — Open Source Analysis

OSA — совокупность нескольких методов поиска уязвимостей в программах, где используется код из общедоступных библиотек. Такие проверки позволяют выяснить, насколько безопасно использовать open-source-компоненты.

Первый тип анализа для поиска зависимостей в системах и программах, включенный в OSA, — Software Composition Analysis (SCA). Такой анализ нужен, чтобы обнаружить и проверить все фрагменты с открытым исходным кодом. SCA позволяет выявлять закладки и устаревшие компоненты, находить взаимосвязи с другими библиотеками внутри ПО. Такое тестирование удобно выполнять с помощью Solar appScreener. Для оценки безопасности Open Source анализатор использует общедоступные базы уязвимостей и собственные, созданные экспертами ГК «Солар» с учетом актуальных угроз для российского рынка.

Второй инструмент для поиска уязвимостей в рамках OSA — анализ лицензионных рисков при включении в ПО open-source-компонентов. Эта технология помогает отслеживать лицензионные политики, оценивает критичность использования той или иной библиотеки и позволяет избежать юридических рисков, связанных с лицензиями.

Третий тип анализа, включенный в OSA, — Supply Chain Security (SCS). Это контроль безопасности Open Source на протяжении всей цепочки поставок — с момента создания компонентов до их использования в разработке. Solar appScreener дает комплексную оценку безопасности сторонних библиотек с учетом 8 критериев (авторский состав разработчиков, дата создания и популярность библиотеки, реакция сообщества, количество версий и др.). Каждому звену цепочки поставок присваивается оценка доверия, на основе которой можно прогнозировать риски для того или иного open source-компонента.

Систему поиска уязвимостей OSA целесообразно внедрять на ранних этапах разработки. Для проведения тестирований нужно загрузить в анализатор SBOM-файл. Если его нет, Solar appScreener может создать спецификацию из архива с исходным кодом ПО.

В решении Solar AppScreener применяется комплексный подход к анализу программного обеспечения, объединяющий методы OSA и SAST для всесторонней оценки кода и состава ПО.