Даниил Чернов: Новая версия Solar appScreener — самый ожидаемый релиз за всю историю продукта

Даниил Чернов, директор центра Solar appScreener компании «РТК-Солар», в беседе с Anti-Malware.ru рассказал об изменениях в сфере защиты приложений, невероятном скачке российского рынка, собственном патентованном ядре Fuzzy Logic Engine и корреляции данных анализа SAST и DAST, которые помогают существенно повысить точность детектирования уязвимостей в софте.

Даниил, привет! В начале ноября у нас был эфир AM Live, посвящённый анализу безопасности исходного кода в нынешней действительности. Какие, на ваш взгляд, сканеры и компоненты на данный момент необходимо использовать компаниям, занимающимся разработкой?

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

Пойдём дальше, второе — динамический анализ (Dynamic Application Security Testing, DAST), который, наверное, стал одним из первых инструментов, позволяющих ввести URL сайта и провести сканирование. Принцип действия прост: DAST засыпает пакетами этот веб-ресурс, получает отклик и делает выводы в отношении наличия или отсутствия уязвимостей. Именно эти инструменты — SAST и DAST — раньше других пришли в арсенал безопасников.

Третье направление — Software Composition Analysis (SCA). Это движок для проверки компонентов внутри проекта на известные уязвимости. Он определяет, какие библиотеки есть внутри софтового проекта, идёт в базу данных и берёт из неё информацию об известных брешах в этих библиотеках. Таким образом, он не сканирует весь код, а «смотрит» лишь библиотеки-компоненты.

Три перечисленных выше инструмента — самый явный джентльменский набор. После февральских событий особенно важно стало проверять сторонние библиотеки (речь идёт о намеренной порче опенсорсных компонентов и библиотек, случаи которых наблюдались, например, в марте — прим. Anti-Malware.ru), потому что многие проекты опираются на что-то готовое.

Хорошо, это стандартный джентльменский набор. А если ещё добавить что-то? Ведь есть множество различных аббревиатур: IAST (Interactive Application Security Testing), BAST (Business Application Security Testing или Behavioral Application Security Testing). Возможно, даже WAF (Web Application Firewall).

Д. Ч.: Если мы говорим о WAF, он не совсем ложится в нашу подборку, поскольку больше относится к средствам предотвращения. Как правило, анализаторы кода подпадают скорее под понятие детектирования. WAF — уже средство защиты уровня приложений.

Что касается IAST, это — гибрид DAST и SAST, но в его случае всё зависит от реализации: под определение IAST можно много чего подвести. Есть ещё одна диковинка — RASP (Runtime Application Self Protection), представляет собой экзотический и новаторский путь: вокруг приложения делается некая вставка кода (инъекция) и она помогает приложению выявить кибератаку. Идея, конечно, замечательная, но реализация в частных случаях может быть ограничена. Я бы не стал её пока рассматривать всерьёз.

Очень давно говорят о концепции «shift left», когда мы все проверки сдвигаем левее по конвейеру. Почему в этом контексте нельзя обойтись одним SAST?

Д. Ч.: Дело в том, что важно выполнять проверки на всех этапах разработки. Вот родился код, 80 % в нём — со стороны; уже на этой стадии можно подключить SCA-анализ, который сможет детектировать не только «статические», но и «динамические» уязвимости.

Дальше представим, что всё пошло по жизненному циклу вперёд (софт собрался и установился на предпродакшн), то есть теперь уже можно смотреть, как приложение себя чувствует в «дикой природе».

Вот тут стоит учитывать, что бывают интересные ситуации: в исходном коде изъянов нет, но внезапно компилятор что-то внёс (компилятор — тоже софт).

Бывает и такое, что на сервере может стоять WAF, а может и не стоять. Другими словами, мы говорим о совокупности факторов, которые будут влиять на подход к проверке кода.

Давайте вернёмся к джентльменскому набору, о котором вы ранее упоминали. Эти компоненты — SAST, DAST, SCA — должны между собой взаимодействовать и обогащать работу друг друга?

Д. Ч.: Здесь вы подняли болезненную тему. Как правило, редко у одного вендора есть всё, а если и есть, то оно обычно слабо интегрировано между собой. В такой ситуации, положим, SAST выдаст один отчёт в определённом формате, DAST — свой отчёт в другом формате, SCA — в третьем, вплоть до того, что уязвимости будут выходить в разных нотациях. В результате ответственный за это сотрудник сидит и пытается всё это сопоставить.

Гипотетически, заказчик в подобной ситуации получает три отчёта: вот SCA что-то нашёл в разных местах, вот SAST зафиксировал, и тому подобное. А если эти инструменты свести в единый движок, то мы получим одну рекомендацию, в которой описываются все проблемы. Такой подход сильно сэкономил бы ресурсы заказчика и, соответственно, его деньги.

Может ли возникнуть такая ситуация, когда устранение уязвимостей по отчёту, допустим, DAST создаст новые бреши по отчёту другого компонента, например SAST?

Д. Ч.: Это же код. С ним так всегда: исправляешь одну уязвимость — рождается новая. У нас даже есть метрика «сравнение отчётов», которая появилась как жизненная необходимость. Мы проводим повторное сканирование после устранения первоначально найденных проблем, при котором всегда видим не только найденные и устранённые бреши, но и новые, добавленные. Кстати, никогда не было такого, чтобы не нашлось новых изъянов при повторном сканировании.

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

Д. Ч.: Да, есть такая проблема. Разработчики даже зарплату свою ставят иногда на то, что найденное — не уязвимость. Что касается верификации, есть автоматизированный метод: пользоваться сформированными правилами и шаблонами, которые будут применяться к объекту исследования.

Другими словами, загрузился код, строится его модель, которая потом анализируется. К ней как раз применяются правила. Например, ту же уязвимость класса «SQL-инъекция» можно детектировать больше чем сотней разных правил. Одно правило может сказать, что тут есть брешь, другое — ровно наоборот, что её нет. В итоге имеем набор срабатываний, а системе нужно принять решение, есть ли всё-таки там SQL-инъекция. 

И вот здесь повышение точности очень сильно экономит время. Линейные подходы всё-таки чреваты последствиями: загружаешь фильтры — появляется очень много ложных срабатываний. А если делать фильтры более узкими, пропускаются настоящие уязвимости, что совсем опасно.

Мы разработали технологию снижения ложных срабатываний — патентованный движок Fuzzy Logic Engine. Он позволяет ощутимо повысить точность именно алгоритмически.

Дальше остаются данные, которые выдал анализатор. Здесь точность можно повысить ещё — скажем, если эту же уязвимость (SQL-инъекцию) нашёл какой-то другой движок вроде DAST. А на текущем этапе развития автоматизированной аналитики нам никуда не уйти от ручной работы: пользователю всё равно нужно пройтись по выявленным уязвимостям, особенно после первого сканирования, и посмотреть самому: брешь, не брешь. Система, получив эту информацию, обучается, а точность её работы повышается.

Вы упомянули ядро Fuzzy Logic Engine. Как оно работает и в чём его особенность?

Д. Ч.: Можно начать с того, как срабатывают правила для поиска уязвимостей: сотни правил применяются на модели сканируемого кода и каждое из них выносит вердикт. Обычно происходит так: либо есть (единица), либо нет (нуль). Это называется «бинарная логика». 

При этом в реальной практике часто не бывает только чёрного и только белого. Может сложиться ситуация, в которой мы на 80% уверены в наличии уязвимости и на 20 % — в её отсутствии. Вот здесь уже есть нечёткая логика.

Кроме того, существует экспертная функция, которая помогает выработать у системы уровень уверенности принятия решений. Она существенно повышает точность алгоритмов. Таким образом, каждое правило отрабатывает уже не по градации «0-1», а по уровням уверенности.

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

Д. Ч.: Будет в несколько раз меньше мусора для пользователя (ложных срабатываний) при сохранении высокой точности обнаружения уязвимостей. Это — как раз к разговору о том, как повысить точность анализа. Мы уходим от компромисса, когда либо ловим всё подряд вместе со множеством мусора, либо пропускаем реальные бреши.

Я правильно понял, что тюнинг правил работы сканера основан на том, что мы обучаем ядро Fuzzy Logic Engine?

Д. Ч.: Нет, Fuzzy Logic Engine уже настроен. Пользователю важно лишь раз пройтись вручную по обнаруженным подозрительным местам, а сканер в дальнейшем будет учитывать его шаблоны.

Получается, что все настройки сканера, как мы его обучили, применимы только к конкретному проекту. Так ведь?

Д. Ч.: Всё верно. Именно к проекту. Например, представим, что выявлена действительно критическая уязвимость. SAST проанализировал код и выдал вердикт, человек сел, посмотрел и пришёл к выводу, что конкретно этот кусок кода не используется или не виден снаружи. Положим, его применяет только пользователь.

Для глобального веб-приложения это было бы ужасно, а так — есть и есть. Тратить время на исправление здесь не стоит, говорим сканеру, что опасности нет.

Получается, если мы обучили сканер для одного проекта, то для другого эта схема может не сработать? Тогда надо учитывать, что по каждому проекту будут разные настройки или даже разные сущности сканеров.

Д. Ч.: В реальности будет несколько иначе: у пользователя есть разные приложения, он запускает их как разные проекты. В первый раз он должен сам пройтись и решить с точки зрения эксперта, где присутствует реальная брешь, а где её нет. Если он пользуется хорошим сканером, тот запомнит и будет в следующий раз понимать, что конкретно в том месте на уязвимость не надо «ругаться».

Предлагаю поговорить о продукте. Solar appScreener, которым вы занимаетесь, задумывался ведь изначально как SAST? Сейчас что-нибудь изменилось, расширилась ли функциональность?

Д. Ч.: Безусловно, расширилась. Продукт начинал свой путь в качестве инструмента статического анализа, который может просканировать приложение в том числе без исходного кода, с автоматическим реверсом.

Когда состоялся первый релиз, мы делали ставку на поддержку максимального количества языков, чтобы пользователь не думал о том, что он выгрузил из репозитория или архива, а Solar appScreener сам за него детектировал. Дошли до 36 языков — самое большое число в мире для статического анализатора.

Параллельно мы добавляли интеграцию, опять же для того, чтобы как можно больше разгрузить пользователя. Далее нужно было делать качественный рывок, и его сделали в направлении платформы Application Security.

Сейчас мы двинулись дальше. В этом месяце представили новую версию, которая содержит также движок динамического анализа. Мы добавили его, пройдя долгий путь шлифовки нашего интерфейса, движков фильтрации, выгрузки отчётности и многого другого. Мы добавили DAST и модуль корреляции; теперь в едином интерфейсе пользователь сможет взять исходный код, просканировать его, а затем выбрать вкладку «динамический анализ», ввести URL приложения и запустить атаку. Если приложение закрыто — например, нужны логин и пароль, — Solar appScreener может попробовать подобрать эти учётные данные. Также можно сделать корреляцию динамического и статистического анализов. 

А эта корреляция должна каким-то образом автоматизироваться? Положим, оба компонента нашли одну и ту же уязвимость. В этом случае пользователю не придётся делать двойную работу?

Д. Ч.: У DAST и SAST есть общие типы уязвимостей, и можно провести верификацию и корреляцию для части изъянов, которые пересекаются. При этом есть бреши, которые SAST не может обнаружить, а есть те, которые не может выявить DAST. Например, тайм-бомба, которая по определённому триггеру делает с системой что-то нехорошее.

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

А какие ресурсы можно сэкономить при наличии такой корреляции?

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

Почему? Во-первых, Fuzzy Logic уже даёт высокую точность, а если ещё подключить DAST, то вообще всё будет верифицировано: вот уязвимость в конкретном участке кода, она уже подтверждена. Ещё есть такой нюанс, который не всегда очевиден: когда ответственные за безопасность приложений начинают давать разработчикам задания на устранение брешей, очень часто начинается демагогия. Здесь тоже можно сэкономить время.

Хотел ещё поговорить об изменениях на рынке в 2022 году. На ваш взгляд, как все современные тенденции отразились на области анализа исходного кода?

Д. Ч.: Новые условия очень сильно повлияли на нашу сферу. Ещё года два назад я бы сказал, что мы существенно отстаём от «авангардного» рынка, которым считается рынок США. На Западе любят процесс, методологию — там это «заходит», а у нас в России очень много талантливых людей, но мы не любим процессность. Зато, когда это действительно нужно, мы можем реализовать на практике то, что обычным способом идёт долго.

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

Я присутствовал на конференциях в ОАЭ и Сингапуре, также у нас была своя секция на «SOC-Форуме» этого года. Могу честно сказать, что в России всё очень выросло в плане Application Security.

А поменялось ли что-нибудь с точки зрения технических требований к работе сканеров со стороны заказчиков?

Д. Ч.: Если говорить про аппаратные требования — они не поменялись. К языкам особых требований тоже не возникло, потому что они в целом независимы от санкций, да и поменять язык зачастую крайне тяжело. Что касается сред разработки, сейчас активно стараются адаптировать их или сделать свои. Мы, кстати, тоже будем адаптировать наш продукт под то, что в России станет стандартом де-факто.

Но всё равно надо учитывать, что экзотические пожелания никуда не денутся. Для таких заказчиков у нас всегда есть очень гибкий API, который, в сущности, становится интерфейсом для общения с движком.

Расскажите о планах на ближайшие полгода или год. Что хотите добавить в сканер? Может, SCA или RASP?

Д. Ч.: Мы сейчас ведём масштабные исследования по движку корреляции, как раз по добавлению SCA. В перспективе хотим, чтобы эти подходы к сканированию кода и сами по себе хорошо работали, и друг с другом сочетались. Задача — гарантировать пользователю экономию его времени, оказать ему максимальную помощь и выдать по-настоящему качественные рекомендации.

Возможно ли сейчас воспользоваться вашим продуктом из облака?

Д. Ч.: Да, у заказчика есть возможность получить продукт из облака. Он располагается в дата-центре «Ростелекома». Если у вас нет задачи разворачивать и поддерживать всё это в своей инфраструктуре, вы можете воспользоваться нашим облаком.

Проводились ли какие-либо доработки в системе отчётности?

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

Именно поэтому мы постоянно что-то совершенствуем. Например, отчёт у нас сейчас доступен в нескольких форматах: можно выгрузить в DOCX (удобно, если надо переслать кусок отчёта внутри компании), PDF, CSV. Много внимания также уделяем интеграции всех компонентов разработки.

Кроме того, постоянно добавляем новые правила. Фактически, очень живой движок выходит.

Большое спасибо! Успехов в развитии продукта!