Виды Application Security Testing. Как различать SAST, DAST и IAST

Информационная безопасность

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

По данным исследования Positive Technologies в 2019 году, 82% всех зафиксированных уязвимостей вызваны ошибками, допущенными при написании исходного кода. По мнению экспертов, в среднем, в каждой второй системе есть дефект безопасности с высоким уровнем риска. Один из основных источников этой проблемы – отсутствие проверок исходного кода на наличие уязвимостей во время его написания. Также один из косвенных факторов – нежелание разработчиков уделять внимание безопасности, они чаще сосредотачиваются на функциональности приложения.

Тем не менее, рост числа уязвимостей и риск их использования злоумышленниками форсирует развитие рынка безопасности приложений. Это особенно заметно из результатов исследования, проведённого Grand View Research:

Рисунок 1. Рынок безопасности приложений США по конечному, 2014–2025 гг. (млн долл. США).

Есть мнение, что не все уязвимости потенциально опасны. Некоторые из них могут быть в исходном коде годами и так ни к чему и не привести. Для выставления приоритета исправления уязвимости разработчики ориентируются на стандарт CVSS (Common Vulnerability Scoring System), но:

• она не универсальна для различных сфер;
• часть экспертов в кибербезопасности считают эту систему устаревшей (ссылка недоступна для просмотра из России) и, как следствие, опасной.

Да, можно уверенно сказать, что качество тестирования кода с годами растёт благодаря многообразию инструментов, их развитию. Старые уязвимости закрываются, но, к сожалению, появляются новые. Кроме того, развиваются инструменты и методы злоумышленников для обнаружения неправильного кода, недостатками которого можно воспользоваться.

Кроме поиска уязвимостей злоумышленники придумываются новые способы атак. Немного отвлекусь от основной темы статьи и расскажу об интересном примере. В ноябре 2021 года исследовательская группа Кембриджского университета опубликовала итоги анализа новой атаки Trojan Source, открывающей возможность заражения ПО на стадии написания исходного кода. Методика этой атаки основана на применении в комментариях к коду специальных Unicode-символов, которые меняют порядок отображения двунаправленного текста. При использовании таких управляющих символов часть текста будет отображаться слева-направо, а другая – справа-налево. То есть, если комбинировать строки с различным направлением текста в одной строке, отрывки текста, отображаемые справа-налево, могут перекрыть уже имеющийся обычный текст, отображаемый слева-направо.

Этот метод позволяет добавить в код вредоносную конструкцию и сделать текст с этой конструкцией незаметным при просмотре кода. Для этого в идущий следом комментарий или внутрь литерала добавляются символы, показываемые справа-налево, что приводит к наложению на вредоносную вставку совершенно других символов. Подобный код останется семантически корректным, но будет по-разному интерпретироваться и отображаться. Подробнее об этом можно прочитать в статье "Атака Trojan Source для внедрения в код изменений, незаметных для разработчика".

Заражённый код может привести к критическим потерям – от утечки личных данных до падения спутника прямо на дом разработчика, который решил пренебречь тестированием кода на уязвимости.

Важно понимать, что любые проблемы с безопасностью влекут не только финансовые, но и репутационные потери для компании. Если появляется соблазн не заморачиваться и пустить решение проблемы на самотёк, то крайне рекомендую держать перед глазами историю о Chrysler Jeep Cherokee, который взломали прямо во время движения.

Если вам интересны другие исследования в области информационной безопасности, то советую ознакомиться с отчётами Gartner Magic Quadrant.

AST

Итак, вернемся к нашим терминам. В ответ на постоянно растущую угрозу и увеличение кодовой базы разработчики используют инструменты AST (Application Security Testing). AST – это процесс повышения безопасности приложений путём выявления уязвимостей в исходном коде. Изначально такое тестирование проводилось вручную. Однако рост количества строк кода и случаев применения стороннего открытого кода, который тоже нужно проверять, привели к необходимости автоматизации процесса.

Использование инструментов тестирования является важной частью концепции DevSecOps. А теперь немного подробнее. В отчёте "Application Security Testing Market — Global Industry Analysis, Size, Share, Growth, Trends, and Forecast 2017–2025" от Transparency Market Research рынок тестирования безопасности приложений сегментирован на следующие классы продуктов:

• Static Application Security Testing (SAST),
• Dynamic Application Security Testing (DAST),
• Interactive Application Security Testing (IAST),
• Mobile Application Security Testing (в данной статье этот класс рассматриваться не будет).

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

SAST

Несмотря на то, что расшифровку любой аббревиатуры можно легко найти на просторах сети, я всё же не буду игнорировать эту обязанность ознакомительной статьи. SAST (Static Application Security Testing) – это процесс тестирования приложения на наличие ошибок и уязвимостей в исходном коде с применением статического анализа.

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

• специалисты по безопасности тестировали код на наличие уязвимостей и после этого передавали результаты предварительного сканирования разработчикам для исправления;
• после получения результатов от "безопасников" разработчики пытались разобраться с большим объёмом неясных результатов и ложных срабатываний, часто появляющихся на поздних этапах SDLС (Software Development Life Cycle – жизненный цикл безопасной разработки).

К счастью, современные технологии SAST значительно упростили описываемый процесс, сместив акцент на разработчиков.

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

В качестве плюсов SAST также выделю:

• возможность интеграции статического анализа в процесс разработки, в IDE;
• автоматическое выявление критических уязвимостей, таких как переполнение буфера, SQL-инъекция, межсайтовый скриптинг (XSS) и других;
• и самое классное – указание на точное расположение подозрительного фрагмента кода, что особенно актуально для крупных проектов с сотнями тысяч и миллионами строк кода.

Но, конечно же, не всё так радужно, как хотелось бы: у SAST есть недостатки. Одним из основных – считается большое количество ложных срабатываний. Из-за этого существует риск длительной проверки каждого такого результата. Разработчики статических анализаторов уделяют пристальное внимание работе с ложными срабатываниями и создают решения для их нивелирования.

Присутствие потенциальных уязвимостей в исходном коде несёт серьёзные риски для безопасности. Использование SAST-инструментов снижает эти риски и помогает контролировать качество разработки.

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

• Checkmarx,
• PVS-Studio,
• Micro Focus,
• Synopsys,
• Veracode и другие.

DAST

В предыдущем разделе я писал о статическом тестировании, в этом – я уделю внимание динамическому тестированию. DAST (Dynamic Application Security Testing) – это процесс тестирования приложений, имитирующий вредоносные внешние атаки, пытающиеся использовать распространенные уязвимости.

Главная задача DAST – обнаружение уязвимостей до того, как их обнаружит кто-то, кроме разработчиков. Такие инструменты ищут проблемные места, проверяя точки доступа и моделируя работу пользователей. Динамическое тестирование позволяет выявлять уязвимости, обусловленные различного рода инъекциями кода в запрос (например, к веб-странице) или связанные с некорректной конфигурацией (самый простой пример – возможность аутентификации по пустому паролю).

Чем отличается DAST от SAST? Отсутствием доступа к исходному коду.

Расскажу о плюсах DAST:

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

Изначально DAST-инструменты использовались реже статического анализа. Но в связи с увеличивающимся спросом на безопасность и высокую динамику распространения смартфонов, в которых становится всё больше приложений, связанных с конфиденциальной информацией, доля DAST-решений значительно увеличилась и продолжает расти. IndustryARC провели исследование "Dynamic Application Security Testing Market – Forecast (2020–2025)", согласно которому рынок DAST-решений в среднем увеличивается на 17,4 % за год.

Основные игроки этого сегмента, по мнению аналитиков IndustryARC:

• WhiteHat Security,
• Synopsys,
• Veracode,
• IBM,
• Accenture,
• Pradeo Security Solutions,
• Trustwave Holdings и другие.

SAST против DAST

Как думаете, какой из указанных типов AST наиболее распространён? Если вы скажете, что в данном вопросе очевидное преимущество у SAST, то будете неправы. Но если выберете вариант DAST, то снова ошибётесь.

Согласно данным Grand View Research о распределении типов анализаторов по долям продаж в масштабах мирового рынка доли SAST и DAST практически равны.

Почему именно эти два вида AST наиболее распространены? В первую очередь это связано с тем, что они существуют дольше остальных, множество начальных недостатков уже исправлено и большинство специалистов уверенно с ними работают.

Можно ли сказать, что равенство означает, что указанные инструменты являются альтернативой друг другу? Нет.

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

• DAST работает с различными наборами входных данных, что позволяет выявить их некорректную/небезопасную обработку;
• SAST хорошо показывает себя при обнаружении ошибок в исходном коде, но печально известен большим числом ложных срабатываний;
• технологии DAST не позволяют отмечать ошибки кодирования точно до номера строки кода;
• SAST легко интегрировать в работу над проектом и автоматизировать процессы. Это помогает устранить часть проблем, связанных с тестированием кодовой базы на безопасность;
• DAST понимает вызовы функций и аргументы;
• SAST умеет работать с вызовами функций и аргументами, но лишь отчасти.

Самое главное – помнить, что для разработчика важно не количество отчётов по результатам тестирования, а проверка и исправление найденных уязвимостей.

IAST

Итак, я рассказал о том, что такое SAST и DAST. Но что такое IAST? IAST (Interactive Application Security Testing) – это относительно новый (в сравнении, опять же, с SAST и DAST) тип тестирования приложений, который фокусируется на обнаружении проблем безопасности в коде приложений. Технология интерактивного тестирования позволяет анализировать приложение изнутри во время его работы.

Т. е., говоря простым языком:

• SAST работает с кодом без запуска приложения;
• DAST может работать с функционирующим приложением, но без доступа к коду;
• IAST работает с кодом изнутри функционирующего приложения.

IAST отслеживает выполнение кода и ищет конкретные события, которые могут привести к уязвимости. Далее эти события анализируются с целью проверить, всё ли с ними хорошо и не закралась ли какая-либо ошибка.

IAST разрабатывался как современное решение, позволяющее устранить недостатки SAST и DAST благодаря объединению подходов к тестированию. Технология интерактивного тестирования обеспечивает обнаружение проблем безопасности в режиме реального времени, анализируя трафик и поток выполнения приложений.

Т. к. IAST работает внутри приложения, он может анализировать:

• код приложения;
• потоки данных;
• конфигурации;
• HTTP-запросы и ответы;
• библиотеки, фреймворки и другие компоненты;
• информацию о внутреннем подключении.

Доступ ко всей этой информации позволяет механизму IAST охватывать больший объем кода, давать более точные результаты и проверять более широкий набор правил безопасности, чем SAST или DAST.

Кроме того, благодаря точности IAST обнаруживает больше существующих рисков. Для наглядности приведу пример по работе с покрытием OWASP Benchmark:

• некоторые IAST-инструменты достигают 100 % покрытия без ложных срабатываний;
• в то время как SAST предлагают только частичное обнаружение (не лучше 80% от OWASP Benchmark) и выдают много ложных срабатываний;
• инструменты DAST обеспечивают низкий уровень обнаружения, около 10–15% от OWASP Benchmark.

Несмотря на определённое превосходство над SAST и DAST, у интерактивного тестирования безопасности также есть минусы.

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

Также крайне тяжело подготовить входные данные и сценарии работы, позволяющие достичь высокого покрытия кода. Т. е. теоретически IAST действительно позволяет покрыть 100 % кода, но на практике это может быть очень сложно и трудозатратно. В этом смысле SAST выглядит предпочтительнее, так как эти инструменты анализируют все ветки программы, независимо от вероятности их исполнения.

Заключение

Application Security Testing – важная часть концепции DevSecOps, которую нельзя игнорировать в современных реалиях разработки. AST необходимо использовать для проверки исходного кода на уязвимости, безопасности входов, соединений и интеграции между внутренними системами.

В заключении статьи хочу выделить несколько важных аспектов:

• нет универсального решения для обеспечения 100 % безопасности разработки. Тем не менее своевременное использование инструментов тестирования позволяет находить потенциальные уязвимости и исключать возможность превращения их в реальные угрозы безопасности;
• SAST и DAST не являются взаимоисключающими инструментами. Совместное применение обеих технологий на соответствующих этапах разработки позволит достичь лучших показателей безопасности исходного кода;
• инструменты SAST по своей природе предназначены для использования в рамках непрерывной интеграции. Инструменты DAST часто ошибочно воспринимаются как непригодные для автоматизации, но вопреки таким мнениям передовые решения DAST успешно используются в конвейерах CI/CD многими предприятиями;
• внедрение IAST в SDLC часто является более сложным, но оно того стоит ввиду универсальности инструмента;
• IAST совмещает в себе как достоинства, так и некоторые недостатки SAST и DAST;
• методы AST должны применяться к любому стороннему коду, используемому в разработке. Нет гарантий, что компонент от третьей стороны является безопасным, независимо от того, коммерческий он или с открытым исходным кодом.