Анализатор исходного кода, имеющий в своем арсенале механизм статического анализа (static application security testing, SAST), помогает сделать приложение безопасным. Его задача — просканировать исходный код на наличие ошибок и уязвимостей и по результатам анализа выдать отчет. Далее за дело берутся специалисты, выполняющие верификацию найденных уязвимостей: они отбирают актуальные уязвимости и исключают из списка все ложные срабатывания. И только после этого разработчики приступают к исправлению кода.
Выбрать эффективный анализатор кода — непростая задача. Как правило, компании ориентируются на скорость сканирования или просто проверяют число поддерживаемых языков программирования, на которых написано ПО. Это действительно важные параметры, но не основные. В статье мы расскажем, на какие еще критерии нужно обязательно обращать внимание при выборе анализатора кода.
Критерии выбора
Как показывает практика, компании, которые выбирали анализатор кода по скорости сканирования, сталкиваются с тем, что в результате специалисты получают бесполезный отчет. Так бывает, например, при использовании только движка поиска по шаблонам (pattern matching). В этом случае сканирование пройдет быстро, но получится длинный отчет на много страниц, который будет содержать большое число ложных срабатываний. Специалистам по безопасности и разработчикам работать с таким отчетом будет сложно — и код в итоге не станет более безопасным.
При выборе анализатора кода важно учитывать не скорость, а качество сканирования — его широту, полноту и количество ложных срабатываний. Хороший анализатор должен искать не только заведомо известные ошибки, но и уязвимости нулевого дня, шаблоны которых (сигнатуры) отсутствуют в базе данных. Количество ложных срабатываний должно быть минимальным, так как они увеличивают трудозатраты специалистов на верификацию.
Для того чтобы снизить количество ложных срабатываний и находить уязвимости нулевого дня, качественный анализатор кода должен решать следующие задачи:
- Вычислять условия эксплуатации уязвимостей. Например, в коде обнаружилась SQL-инъекция, а далее идет условие, что данный фрагмент кода должен выполняться только 31 февраля. Очевидно, что такую уязвимость нельзя проэксплуатировать, и эксперту, проверяющему результаты анализа, не стоит тратить на нее время.
- Формировать тестовые эксплойты, которые позволяют в режиме реального времени (лучше всего — прямо в интерфейсе анализатора при разборе результатов) проэксплуатировать уязвимость и увидеть, как реагирует приложение.
- Подтверждать найденные уязвимости с помощью других механизмов (функция автопроверки). К примеру, мы с помощью движка статического анализа (SAST) обнаружили уязвимость. Затем эта же уязвимость проверяется движком динамического анализа (DAST). Подтверждение уязвимости двумя независимыми механизмами говорит о том, что никакого ложного срабатывания нет, уязвимость реальна.
- Рассчитывать все возможные векторы атак злоумышленника — и последствия, к которым они могут привести. Поиск по шаблонам (сигнатурный или синтаксический анализ) с такой задачей не справляется. В последнее время распространение получил механизм построения диаграммы потоков данных (data flow diagram, DFD), которая отображает последовательность преобразований данных, контролируемых пользователем, от точки их возникновения в программе до точки выхода потенциально опасной операции.
Отдельно следует сказать про DFD. Этот механизм показывает, как данные перемещаются по коду, но не позволяет увидеть значения, которые эти данные могут принимать. Если не вычислять и не знать эти значения, то потенциально можно столкнуться с ложными срабатываниями. Вычислить эти значения могут механизмы, которые относятся к категории символического анализа как варианта реализации абстрактной интерпретации.
Как проверить качество сканирования
Если говорить о покрытии языков программирования, то здесь все просто: информация о списке поддерживаемых языков либо опубликована, либо есть в интерфейсе самого анализатора. Проверить качество сканирования сложнее. Можно протестировать несколько анализаторов, «прогоняя» через них одно и то же приложение, но по времени это может быть довольно затратной задачей.
Другой вариант — обратиться к исследованиям независимых организаций, занимающихся профильными вопросами. Примером может служить сообщество OWASP — открытый проект, посвященный обеспечению безопасности веб-приложений, в него входят корпорации, образовательные учреждения и частные лица со всего мира. OWASP работает над созданием статей, учебных пособий, документации, инструментов и технологий, находящихся в свободном доступе.
В части проверки качества сканирования OWASP сформировал ряд эталонных тестов, которые представляют собой код с известным числом уязвимостей. Запуская анализ этого кода на испытуемых анализаторах, можно понять, как они справляются с поиском уязвимостей. Результаты испытаний можно представить в виде графика (см. рисунок). Если анализатор не нашел ни одной уязвимости, но показал ложные срабатывания, то он отражается в правом нижнем углу графика. Если анализатор нашел все уязвимости и не показал ни одного ложного срабатывания, то он отображается в верхнем левом углу графика. По диагонали располагаются те анализаторы, которые, нашли не все уязвимости и показали ложные срабатывания. Подробнее на странице проекта OWASP Benchmark.
Резюме
Приложение становится безопасным только при качественном сканировании, при котором важны не количество поддерживаемых языков, а широта и полнота сканирования и малое количество ложных срабатываний. Выбирая анализатор по критерию качества сканирования, можно протестировать один и тот же код анализаторами разных производителей и сравнить результаты — или обратиться к исследованиям независимых организаций.
Важно помнить, что главное — не отчет по результатам сканирования, а исправленное по найденным уязвимостям приложение.