Как не запутаться среди SAST, DAST и IAST. Или о видах Application Security Testing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я ни на что не намекаю, но вы можете попробовать в деле анализатор PVS-Studio и сравнить его с другими SAST-инструментами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал статьи написан мной и опубликован здесь.