Какие плюсы есть у SAST? Чем он отличается от DAST? Что такое IAST? Что значат все эти слова?! Об этом (и не только) расскажем в статье-разборе основных видов Application Security Testing (далее AST).
Информационная безопасность
Прежде чем приступить к подробной расшифровке этих терминов, давайте разберёмся, зачем вообще заморачиваться с тестированием безопасности? В современных реалиях ПО встраивается в процессы автоматизации практически во всех сферах, количество строк кода приложений увеличивается. Как следствие, растёт число возможных уязвимостей и ошибок, что формирует потребность в эффективной проверке и тестировании исходного кода.
По данным исследования 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 и другие.
Я ни на что не намекаю, но вы можете попробовать в деле анализатор PVS-Studio и сравнить его с другими SAST-инструментами.
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 должны применяться к любому стороннему коду, используемому в разработке. Нет гарантий, что компонент от третьей стороны является безопасным, независимо от того, коммерческий он или с открытым исходным кодом.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Alexey Sarkisov. Application Security Testing. How not to get confused between SAST, DAST, and IAST.
