Какие плюсы есть у 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 (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 необходимо использовать для проверки исходного кода на уязвимости, безопасности входов, соединений и интеграции между внутренними системами.  В заключении статьи хочу выделить несколько важных аспектов: Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Alexey Sarkisov. Application Security Testing. How not to get confused between SAST, DAST, and IAST. Маркетолог