# Виды Application Security Testing\. Как не запутаться среди SAST, DAST и IAST

Какие плюсы есть у SAST? Чем он отличается от DAST? Что такое IAST? Что значат все эти слова?\! Об этом \(и не только\) расскажем в статье\-разборе основных видов Application Security Testing \(далее AST\)\.

![0972_types_of_ast_ru/image1.png](https://import.viva64.com/docx/blog/0972_types_of_ast_ru/image1.png)

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

Прежде чем приступить к подробной расшифровке этих терминов, давайте разберёмся, зачем вообще заморачиваться с тестированием безопасности? В современных реалиях ПО встраивается в процессы автоматизации практически во всех сферах, количество строк кода приложений [увеличивается](https://www.informationisbeautiful.net/visualizations/million-lines-of-code/)\. Как следствие, растёт число возможных уязвимостей и ошибок, что формирует потребность в эффективной проверке и тестировании исходного кода\.

По [данным исследования](https://www.ptsecurity.com/ru-ru/about/news/positive-technologies-82-uyazvimostey-veb-prilozheniy-soderzhitsya-v-iskhodnom-kode/) Positive Technologies в 2019 году, 82% всех зафиксированных уязвимостей вызваны ошибками, допущенными при написании исходного кода\. По мнению экспертов, в среднем, в каждой второй системе есть дефект безопасности с высоким уровнем риска\. Один из основных источников этой проблемы – отсутствие проверок исходного кода на наличие уязвимостей во время его написания\. Также один из косвенных факторов – нежелание разработчиков уделять внимание безопасности, они чаще сосредотачиваются на функциональности приложения\.

Тем не менее, рост числа уязвимостей и риск их использования злоумышленниками форсирует развитие рынка безопасности приложений\. Это особенно заметно из результатов исследования, проведённого [Grand View Research](https://www.grandviewresearch.com/industry-analysis/application-security-market) \(ссылка недоступна для просмотра из России\):

![0972_types_of_ast_ru/image2.png](https://import.viva64.com/docx/blog/0972_types_of_ast_ru/image2.png)

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

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

* [она не универсальна](https://verveindustrial.com/resources/blog/cvss-scores-is-it-effective-for-ics-vulnerabilities-in-ot/) для различных сфер;
* часть экспертов в кибербезопасности [считают эту систему устаревшей](https://www.tenable.com/blog/why-you-need-to-stop-using-cvss-for-vulnerability-prioritization) \(ссылка недоступна для просмотра из России\) и, как следствие, опасной\.

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

Кроме поиска уязвимостей злоумышленники придумываются новые способы атак\. Немного отвлекусь от основной темы статьи и расскажу об интересном примере\. В ноябре 2021 года исследовательская группа Кембриджского университета [опубликовала итоги анализа](https://trojansource.codes/trojan-source.pdf) новой атаки Trojan Source, открывающей возможность заражения ПО на стадии написания исходного кода\. Методика этой атаки основана на применении в комментариях к коду специальных Unicode\-символов, которые меняют порядок отображения двунаправленного текста\. При использовании таких управляющих символов часть текста будет отображаться слева\-направо, а другая – справа\-налево\. То есть, если комбинировать строки с различным направлением текста в одной строке, отрывки текста, отображаемые справа\-налево, могут перекрыть уже имеющийся обычный текст, отображаемый слева\-направо\.

Этот метод позволяет добавить в код вредоносную конструкцию и сделать текст с этой конструкцией незаметным при просмотре кода\. Для этого в идущий следом комментарий или внутрь литерала добавляются символы, показываемые справа\-налево, что приводит к наложению на вредоносную вставку совершенно других символов\. Подобный код останется семантически корректным, но будет по\-разному интерпретироваться и отображаться\. Подробнее об этом можно прочитать в статье "[Атака Trojan Source для внедрения в код изменений, незаметных для разработчика](https://pvs-studio.ru/ru/blog/posts/cpp/0933/)"\.

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

Важно понимать, что любые проблемы с безопасностью влекут не только финансовые, но и репутационные потери для компании\. Если появляется соблазн не заморачиваться и пустить решение проблемы на самотёк, то крайне рекомендую держать перед глазами историю о [Chrysler Jeep Cherokee](https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/), который взломали прямо во время движения\.

Если вам интересны другие исследования в области информационной безопасности, то советую ознакомиться с отчётами [Gartner Magic Quadrant](https://www.gartner.com/en/documents/877913/magic-quadrant-for-static-application-security-testing)\.

## AST

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

Использование инструментов тестирования является важной частью концепции [DevSecOps](https://pvs-studio.ru/ru/blog/posts/0710/)\. А теперь немного подробнее\. В отчёте "[Application Security Testing Market — Global Industry Analysis, Size, Share, Growth, Trends, and Forecast 2017–2025](https://www.transparencymarketresearch.com/application-security-testing-market.html)" от 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 и другие\.

Я ни на что не намекаю, но вы можете попробовать в деле анализатор [PVS\-Studio](https://pvs-studio.ru/ru/pvs-studio/try-free/?promo=ast_types) и сравнить его с другими SAST\-инструментами\.

## DAST

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

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


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



![0972_types_of_ast_ru/image3.png](https://import.viva64.com/docx/blog/0972_types_of_ast_ru/image3.png)

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

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

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

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

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

## SAST против DAST

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

Согласно [данным Grand View Research](https://www.grandviewresearch.com/industry-analysis/application-security-market#:~:text=Global%20application%20security%20market%2C%20by%20testing%20type%202016%20(%25)) \(ссылка недоступна для просмотра из России\) о распределении типов анализаторов по долям продаж в масштабах мирового рынка доли SAST и DAST практически равны\.

![0972_types_of_ast_ru/image4.png](https://import.viva64.com/docx/blog/0972_types_of_ast_ru/image4.png)

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

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

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

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

![0972_types_of_ast_ru/image5.png](https://import.viva64.com/docx/blog/0972_types_of_ast_ru/image5.png)


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



## IAST

![0972_types_of_ast_ru/image6.png](https://import.viva64.com/docx/blog/0972_types_of_ast_ru/image6.png)

Итак, я рассказал о том, что такое 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](https://owasp.org/www-project-benchmark/):

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

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

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

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

## Заключение

![0972_types_of_ast_ru/image7.png](https://import.viva64.com/docx/blog/0972_types_of_ast_ru/image7.png)

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

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

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