Мы создаем множество сложных программных продуктов и требования безопасности кода становятся все актуальнее. Автоматизация везде, в том числе и в сфере безопасности: алгоритмы говорят нам, как писать код. Очень хочется иметь волшебный инструмент, который бы говорил, безопасен наш код или нет. Попробуем проверить, есть ли волшебная кнопка в мире DevSecOps. Для этого мы взяли несколько статических анализаторов кода (SAST), залили в них уязвимый код и посмотрели, что получилось на выходе. Как пелось в песне группы Технология, “Нажми на кнопку – получишь результат, и твоя мечта осуществится”.

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

Зачем это все?

Практики DevSecOps стремительно развиваются, много разговоров о Shift left (смещение вопросов, связанных с безопасностью, как можно ближе к началу разработки), культуре безопасной разработки и инструментах: многие уже прошли этап внедрения  практики управления уязвимостями в периметре безопасности и патч-менеджмент, но этого уже недостаточно. Поскольку наряду со стандартным софтом используются написанные специально под определённые задачи или кастомизированные приложения (вендорные решения или собственные разработки), такие программы стали часто использоваться злоумышленниками как точка входа, что делает необходимым поиск и устранение уязвимостей в собственном коде. Эту задачу решают инструменты анализа исходного кода на уязвимости.

Класс инструментов статического анализа активно развивается, в том числе и под давлением регуляторов. Многие компании уже внедрили средства анализа качества кода, которые контролируют избыточную цикломатическую сложность, дублирование кода, покрытия всех строк тестами, соблюдение стандартов кодирования и пр.. Некоторые из этих систем, например SonarQube, позволяют находить уязвимости, категоризировать их, предлагают варианты решения. Мы рассмотрим для примера SonarQube далее наравне с коммерческими решениями.

Дефицит внутренних ресурсов и высокая стоимость технологий анализа, часто приводят к значительному увеличению срока выхода релизов, что  накладывает свои ограничения по применению этих инструментов «в бою». Поэтому, в идеале хотелось бы иметь «умный» инструмент, который обеспечит  дополнительные точки проверки качества кода без драматического влияния на процесс выхода частых релизов в «прод».  В этой статье мы сравним отчеты нескольких SASTов и оценим их базовые возможности.

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

Общая информация о продуктах

Рынок инструментов безопасной разработки активно растет и развивается. В России сегмент SAST хорошо развит, на рынке присутствуют как отечественные вендоры, так и зарубежные. Среди российских участников рынка можно выделить: Positive Technologies; PVS-Studio; «Газинформсервис»; «Ростелеком-Солар»; ГК «Эшелон». Согласно отчету «Critical Capabilities for Application Security Testing» Gartner выделяет на мировом рынке следующих основных игроков: CAST; Checkmarx; Contrast Security; GitLab; HCL Software; Micro Focus; Onapsis; Rapid7; Synopsys; Veracode; WhiteHat Security.

Из отчета Gartner “Critical Capabilities for Application Security Testing”
Из отчета Gartner “Critical Capabilities for Application Security Testing”

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

Fortify

Fortify неоднократно менял владельца, в данный момент поддерживается компанией Micro Focus. Представляет довольно мощный инструмент анализа кода. Fortify Static Code Analyzer входит в составе более крупного решения Fortify. Способен определять причины уязвимостей, приоритезировать и давать рекомендации по исправлению кода.

Основные особенности:

  • Снижение ложных срабатываний за счет использования алгоритмов машинного обучения

  • Поддержка большого числа языков (более 27 основных языков), в том числе ABAP / BSP, ASP.NET, Python, Ruby

  • Охват категорий уязвимостей, внесённых в OWASP Top 10 и SANS Top 25, соответствие стандартам DISA STIG, PCI DSS и другим.

  • Возможность подключения к системам управления непрерывной интеграцией

PT Application Inspector

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

  • генерирует эксплойты — безопасные, но эффективные тестовые запросы, которые помогают подтвердить или опровергнуть наличие уязвимости

  • Отечественный, локализованный продукт

  • Широкий набор поддерживаемых государственных стандартов

  • Наличие сертификата ФСТЭК России

  • Использование базы уязвимостей веб-приложений WASC и классификатора CWE

  • Возможность визуализации программного кода

Solar AppScreener

Solar appScreener (до версии 3.0 — Solar inCode) работает полностью автоматически, анализируя исходного кода программы и её исполняемых файлов. При отсутствии исходного кода можно загрузить рабочие файлы мобильного или веб-приложения. Для мобильных приложений можно скопировать в сканер ссылку на страницу в Google Play или App Store.

  • Декомпиляция приложений

  • Большое число поддерживаемых языков программирования (36 языков)

  • Легко интегрируется с Git и Subversion, VSC-хостингами GitLab GitHub и Bitbucket и другими

  • Исходный код может передаваться на анализ как простой загрузкой файлов в сканер, так и напрямую из репозитория.

Checkmarx

Checkmarx CxSAST – чугунный эталон мира безопасности, позволяет в автоматическом режиме обнаруживать и идентифицировать уязвимости наиболее распространённых языков программирования. Кроме всего прочего позволяет визуализировать код в виде блок-схем маршрутов выполнения. По результатам сканирования выдаются рекомендации по исправлению проблем с привязкой к графической схеме, что очень удобно.

  • Поддерживает большое число языков программирования (более 20)

  • Интегрируется с различными средами разработки, серверами сборки, системами контроля версий и отслеживания ошибок

  • Небольшой процент ложных срабатываний

  • Визуализация кода

Методика тестирования

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

Для проверки качества анализа «из коробки» мы выбрали два приложения на языке Java.

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

Описание уязвимостей, присутствующих в выбранных приложениях

XSS

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

Наличие известных уязвимых компонентов

Тут все просто, в приложении используется версия библиотеки с известными уязвимостями

OGNL Expression Injection

Инъекция кода OGNL. OGNL – язык, который позволяет манипулировать свойствам https://en.wikipedia.org/wiki/OGNL

SQL Injection

Всем знакомая SQL инъекция, подробнее https://ru.wikipedia.org/wiki/Внедрение_SQL-кода

Password in Configuration File

Небезопасное задание пароля в конфигурационном файле

Privacy Violation

Нарушение конфиденциальности, в данном случае запись в журнал логина и пароля

Log Forging

Подделка записи журнала

Command Injection

Инъекция в текст командной строки, подробнее тут.

Open redirect

Возможность перенаправить пользователя на новый сайт без проверки целевого сайта. Подробнее тут

Misconfiguraton

Ошибки в конфигурации приложения

XXE

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

Brocken Access control

Нарушенный контроль доступа, это дает злоумышленникам возможность получить доступ к конфиденциальным данным.

Мы загрузили исходный код этих приложений в анализаторы с дефолтными настройками и сравнили результаты. Рассматривали только уязвимости, отмеченные анализаторами хотя бы в одном из инструментов. Если уязвимость не была найдена ни одним анализатором, то мы ее исключали из результатов сравнения (ибо не дошла еще техника до такого).

Итоговый рейтинг считали по следующей формуле:

Сравнение результатов прогонов

SonarQube не нашел ни одной уязвимости ни в одном проекте, что было ожидаемо. На сим закончим с ним и перейдем к коммерческим решениям.

Статистика анализа приложения dvja в SonarQube
Статистика анализа приложения dvja в SonarQube
Статистика анализа приложения vulnado в SonarQube
Статистика анализа приложения vulnado в SonarQube

Анализ приложения DVJA

На данном приложении хорошо проявил себя Fortify, так как он единственный нашел опасную уязвимость OGNL Expression Injection.

Описание уязвимости OGNL injection, найденной Fortify
Описание уязвимости OGNL injection, найденной Fortify

По результатам анализа Fortify был найден 81 недостаток приложения dvja. В категории Critical и High не было ложноположительных срабатываний.

Статистика недостатков, найденных Fortify в приложении dvja
Статистика недостатков, найденных Fortify в приложении dvja

Все 11 критических недостатков несли серьезную угрозу безопасности:

Список критических уязвимостей найденных Fortify в приложении dvja
Список критических уязвимостей найденных Fortify в приложении dvja

Command Injection он занес в категорию High:

Список серьезных уязвимостей найденных Fortify в приложении dvja
Список серьезных уязвимостей найденных Fortify в приложении dvja

AppScreener в итоге нашел 88 недостатков, но среди них не было найденных Fortify серьезной уязвимости OGNL Expression Injection, а также Command Injection, XSS в списке отсутствовали как класс. Также смутил алгоритм оценки критичности. Например, тот же Checkmarx позволяет выбирать способы выставления Severity на основе нескольких заложенных шаблонов: OWASP, PCI, FISMA, NIST. В данном случае  такой возможности мы не нашли.

Статистика недостатков, найденных AppScreener в приложении dvja
Статистика недостатков, найденных AppScreener в приложении dvja

Пароль в конфигурационном файле был главной проблемой приложения, по итогам анализа.

Список критических уязвимостей найденных AppScreener в приложении dvja
Список критических уязвимостей найденных AppScreener в приложении dvja
Список серьезных уязвимостей найденных AppScreener в приложении dvja
Список серьезных уязвимостей найденных AppScreener в приложении dvja
Список серьезных уязвимостей найденных AppScreener в приложении dvja
Список серьезных уязвимостей найденных AppScreener в приложении dvja

В отчете были и ложноположительные срабатывания. Анализатор ругался на Timing attack при сравнении пароля с его подтверждением:

PT Application Inspector выдал 56 недостатков. Он не нашел OGNL Expression Injection, но command injection успешно записал в критические. Он единственный обнаружил использование уязвимой версии JQuery, также нашел ненайденные другими анализаторами XSS. Ложноположительных срабатываний не было.

Статистика уязвимостей, найденных PT AI в приложении dvja
Статистика уязвимостей, найденных PT AI в приложении dvja

С Checkmarx оказалось не все так просто. В статистике мы увидели следующие цифры.

Статистика уязвимостей, найденных Checkmarx в приложении dvja
Статистика уязвимостей, найденных Checkmarx в приложении dvja

Дело в том, что он считает вектора атак и если у вас в коде есть одна SQL инъекция, но данная инъекция может быть использована из 8 разных мест, то он в итоги запишет 8. Вся эта информация представляется в виде графа, на котором отмечено. где вставить проверку будет наиболее эффективно. Это очень удобно и информативно.

Представление векторов атак Checkmarx
Представление векторов атак Checkmarx

Кроме того, есть возможность изменять ранжирование критичности уязвимостей на основе различных шаблонов, коих из коробки дают немало. Он также не нашел OGLN Injection.

Расстроило одно ложноположительное срабатывание. В SQL Injection он записал этот код:

Ложноположительное срабатывание Checkmarx в приложении dvja
Ложноположительное срабатывание Checkmarx в приложении dvja

После анализа отчетов всех анализаторов получилась следующая картина:

Fortify

PT AI

AppScreener

Checkmarx

Обнаружено уязвимостей

73%

60%

41%

70%

Ложноположительные срабатывания

0

0

5

1

Итог (R)

0,73

0,6

0,23

0,67

Анализ приложения Vulando

Снова Fortify показал себя с лучшей стороны.

Статистика анализа Fortify  приложения vulnado
Статистика анализа Fortify приложения vulnado

Он нашел SQL Injection и Command Injection и записал их в критические

Список критических уязвимостей, найденных Fortify в приложении vulnado
Список критических уязвимостей, найденных Fortify в приложении vulnado

Остальные недочеты сводились к Unreleased Resource и Poor Error Handling:

Список серьезных уязвимостей, найденных Fortify в приложении vulnado
Список серьезных уязвимостей, найденных Fortify в приложении vulnado

AppScreener опять немного смутил расстановкой критичности, но две основные уязвимости он обнаружил, только записал Command Injection в Medium level. Не обошлось без ложных срабатываний, XSS в отчете не было.

Статистика уязвимостей, найденных AppScreener в приложении vulnado
Статистика уязвимостей, найденных AppScreener в приложении vulnado
Список уязвимостей, найденных AppScreener в приложении vulnado
Список уязвимостей, найденных AppScreener в приложении vulnado
Список уязвимостей, найденных AppScreener в приложении vulnado
Список уязвимостей, найденных AppScreener в приложении vulnado

PT Application Inspector также обнаружил две основные уязвимости (правда в отчете почему-то они были отображены как 4 разных), в остальном все свелось к Log Forging при выводе отладочной информации, XSS он не нашел.

Статистика уязвимостей, найденных PT AI  в приложении vulnado
Статистика уязвимостей, найденных PT AI в приложении vulnado

Checkmarx показал себя с лучшей стороны. Основные уязвимости были найдены, XSS была проставлена высокая критичность, нареканий к его работе не было. Он единственный нашел отсутствие соли в хешах, а также неверное формирование времени жизни JWT. На данном приложении Checkmarx выглядел убедительнее всех остальных.

Статистика уязвимостей, найденных Checkmarx в приложении vulnado
Статистика уязвимостей, найденных Checkmarx в приложении vulnado

В итоге получили следующие результаты:

Fortify

PT AI

AppScreener

Checkmarx

Обнаружено уязвимостей

47%

33%

47%

47%

Ложноположительные срабатывания

0

0

3

0

Итог (R)

0,47

0,33

0,26

0,47

Заключение

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

Мы рассмотрели только один из параметров сравнения, но постоянная ежедневная работа с инструментом требует намного большего, чем чисто синтетический разовый прогон на простых приложениях. Мы прокатились пару кругов по Нюрбургрингу на четырех суперкарах мира статического анализа, в жизни может оказаться, что ездить каждый день на них по проселочной дороге не представляется возможным. Эффективность внедрения во многом зависит от культуры разработки на проекте и готовности DevOps. Без правильно выстроенного конвейера и процессов разработки любое внедренное средство будет стоять для галочки. Кто-то должен анализировать отчеты на постоянной основе, необходимо выделение роли security champion на проекте для разбора отчетов и постановки задач на исправления командам. Все рассмотренные средства позволяют проводить глубокую кастомизацию под свои нужды, а это также требует наличие специалистов. В любом случае, перед внедрением необходимо прежде всего набрать или обучить людей, которые будут работать над безопасностью кода. Можно обкатать процессы на open source решениях и только после того, как будет понимание потребностей и ограничений, смотреть в сторону коммерческих решений.

Если данная тема будет интересна читателям, мы проведем более детальный обзор каждого из инструментов, тем более что один из производителей изъявил готовность дать более глубокий анализ работы своего продукта. В следующей статье предлагается рассмотреть процесс онбординга (onboarding) для инструментов статического анализа, т.е. первичную настройку сканирования с указанием функций, принимающих данные от пользователя, и функций, производящих обработку этих данных. Показать взаимодействие специалиста ИБ с Security Champions из команды разработки при анализе отчетов. По задаче динамического анализа рассмотрим настройки процесса, покажем ввод данных по учеткам для тестирования сайта с использованием разных ролей. Опишем процесс настройки сканеров для проверки по веб-формам из сценария.

Комментарии (13)


  1. Mikluho
    09.10.2021 10:53

    Ох, как же я за#@#^%мучался с эти чекмарксом...

    У нас в компании он живёт уже более года и сканирует каждый дистрибутив (точнее версию исходников, из которых дистрибутив собирается). Я за это время отметил как ложно-положительные несколько тысяч срабатываний. И нашёл только пару потенциальных уязвимостей. Это та самая реальная жизнь за пределами красивых демонстраций. Да, у нас большой solution с кучей проектов, из которого собирается дистрибутив в пачкой приложений. В итоге инструмент видит несуществующие пути кода, откровенно плохо понимает asp.net и т.д. и т.п...


    1. langoner Автор
      09.10.2021 10:59

      А у вас какой стек, .net? Очень интересно мнение живых пользователей. Долго сканируется ваше приложение?


      1. Mikluho
        09.10.2021 11:15

        да, .net + oracle + angular в моём solution. Сканируется где-то час, но это он ещё не все исходники берёт. Весь объём исходников он не осилил, так что пришлось часть исключить из сканирования.

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


        1. langoner Автор
          09.10.2021 11:35

          А вы используете его из коробки или настраивали? Проводили анализ какие правила фонят? Может их можно скорректировать под ваш проект?


          1. Mikluho
            09.10.2021 11:42

            "Всё сложно" :) Он же у нас общий, обслуживает его отдельная команда. Базовый набор правил - owasp. Периодически накатывают новую версию - приходится вычёсывать очередную пачку срабатываний. Хорошо хоть он их запоминает (хотя иногда и забывает). А настраивать.... Ему логику править надо. Он плохо понимает структуру сложных систем (много приложений с общей кодовой базой). Теоретически можно тестировать каждое приложение по отдельности, но это слишком сложно организовать и будет занимать слишком много времени.


    1. OneHalf
      15.10.2021 16:17

      У меня на прошлой работе (в 2020-м) тоже продвигали этот инструмент. Стек - Java, Kotlin, SpringBoot, JdbcTemplate/MyBatis.

      В итоге у меня жутко отрицательное мнение о CxSAST. Валидных срабатываний там от силы доля процента. И то, угадывание в основном на ошибках в духе "у вас поле static, но при этом не final".

      Kotlin вообще не воспринимался анализатором (может версия какая-то урезанная у нас была..).

      Поиск SQL-иньекций - вообще смех. Инструмент и видит, что какой-то параметр из MVC контроллера доходит до jdbcTemplate, а в SQL есть конкатенация - сразу жалуется на иньекцию. Хотя параметр прокидывается валидно, а конкатенация из двух строк констант (тупо SQL в одну строку не влазит в редакторе)

      XML пытался парсить и анализировать как Java. И даже что-то там якобы находил с уровнем high опасности! (Там SQL у нас лежали, в которых при определенной фантазии можно было увидеть вызовы методов - а-ля ".. SUM(field_name) ..")

      Groovy вроде поддерживался, но работал плохо. Влезал к нам в грейдл скрипты, и говорил, что "==" использовать нельзя, нужен ".equals(..)" что, в общем-то, бессмысленно для groovy.

      В общем, совсем меня CxSAST не порадовал. Просто шумный инструмент, наугад тыкающий в каждую двадцатую строку. Где-то да угадает.


  1. secm
    12.10.2021 09:43
    +2

    Расскажите подробнее про SonarQube. Почему было ожидаемо, что он не нашел ни одной уязвимости ни в одном проекте?


    1. dyakimov
      12.10.2021 15:05
      +1

      SonarQube не делает taint-анализ, поэтому полноценным SAST по сути не является....


      1. langoner Автор
        12.10.2021 17:17

        Да, так, но taint-анализ есть в коммерческой версии сонара


    1. langoner Автор
      12.10.2021 17:15

      Отличный вопрос! Как правильно написали выше, дело в taint-анализе. Вот можно почитать:

      Мы использовали бесплатную версию, в которой его нет


  1. dyakimov
    12.10.2021 15:08

    Вообще ожидаемо увидеть качественные результаты на затертом до дыр dvja
    Все знают этот проект и все тестируют любые инструменты на нем
    Поэтому доверие за счет возможности что-то докрутить со стороны вендора под кейс сильно снижается
    В реальности на закрытом проекте любой из перечисленных SAST ведет себя достаточно плохо и упускает жуткие тривиальные уязвимости....


    1. langoner Автор
      12.10.2021 17:21

      Я бы не сказал, что отработали анализаторы плохо. Полезную информацию они дали, уязвимости нашли. С точки зрения "докрутить" - все не так просто. Было бы очень полезно/интересно увидеть примеры тривиальных пропущенных. Если возможно, можете дать пример?


  1. BlackDiver
    26.10.2021 04:01

    Увы, но на нашей кодовой базе реального проекта (PHP) все вышеперечисленные сканеры показали нулевой результат по критическим уязвимостям. Условия испытаний были простые. Реальная кодовая база. Общее количество известных недостатков около 60 штук (каждый из недостатков был найден и валидирован ранее ручным ревью кода перед релизами). Из них 4 критических (3 SQL injection, 1 SSRF) Зато мы наслушались перлов некоторых вендоров, лучшими из них были: «покажите уязвимость, а мы покажем как ее искать», «у вас программисты пишут без использования лучших практик и наш SAST нужно тюнинговать именно под вас».