>
>
PVS-Studio для поиска дефектов безопасн…

Андрей Карпов
Статей: 671

Павел Еремеев
Статей: 38

PVS-Studio для поиска дефектов безопасности и защищённости приложений. Отчёт Forrester Research о SAST, Q3 2020

PVS-Studio, изначально разрабатываемый как универсальный инструмент поиска ошибок в программном коде, постепенно стал ориентироваться на обеспечение безопасности и защищённости приложений, на выявление потенциальных уязвимостей нулевого дня. Этому способствовала поддержка стандартов CERT и MISRA, классификация предупреждений анализатора в соответствии со стандартом CWE, развитие механизмов анализа потока данных для поиска недостоверных данных (taint checking) и так далее.

6 августа 2020 года компания Forrester Research выпустила исследование под названием "Now Tech: Static Application Security Testing, Q3 2020", в которое анализатор PVS-Studio попал как SAST-специализированное решение. Компания Forrester является одним из ведущих исследователей влияния новых и инновационных технологий на бизнес-процессы и рынок, поэтому попадание PVS-Studio в данное исследование является хорошим подтверждением (как для наших пользователей, так и для нас самих) актуальности данного направления развития продукта. Отчёт об исследовании доступен для покупки подписчикам и клиентам Forrester Research.

Подходы к обеспечению и безопасности кода

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

К таким методологиям относится:

  • Повышение культуры написания кода в целом. Речь идёт об использовании стандартов кодирования, внедрении обзоров кода в процесс разработки и так далее.
  • DAST (Dynamic application security testing). Инструменты динамического анализа позволяют выявлять уязвимости в коде, например, SQL-инъекции, переполнение буфера и подобные. Их недостаток: необходимость запуска приложений на большом количестве различных тестов и большие затраты времени. Преимущества: почти полное отсутствие ложных срабатываний и необязательно иметь доступ к коду приложений. Подход, в котором также требуется доступ к исходному коду, называется IAST (Interactive Application Security Testing).
  • SAST (Static application security testing). Разновидность статического анализа кода, ориентированная на поиск уязвимостей и потенциальных уязвимостей. Может выявить большое количество дефектов, в том числе даже тех, которые не успели проявить себя. Недостатки: анализаторы выдают ложные срабатывания и требуют наличие исходного кода программы. Преимущества: не требуется запуск тестируемых приложений, высокая скорость работы.
  • RASP (Runtime application self-protection). Самозащита приложений runtime - одно из средств защиты, которое используется при выполнении программы. RASP анализирует поведение приложения и таким образом проводится непрерывный анализ безопасности.
  • Другие методики или разновидности перечисленных.

Перечисленные методологии органически вливаются в процесс разработки и можно сказать, что их внедрение превращает DevOps в DevSecOps.

В рамках данной статьи мы подробнее остановимся на SAST, который в свою очередь разделяется на два больших направления.

Первое направление: поиск известных уязвимостей

Анализаторы первого типа работают по принципу антивируса. Им известно, как выглядят фрагменты кода, содержащие известные уязвимости (CVE). Эти фрагменты они и ищут в коде проверяемых проектов. На практике всё немного сложней, но общая идея именно такая.

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

Второе направление: поиск уязвимостей нулевого дня

Приложение может содержать ошибку, которая некоторое время будет оставаться незамеченной. Если хакер обнаружит такую ошибку и придумает, как её можно эксплуатировать, то она превратится в новую уязвимость. Такой только что выявленный опасный дефект носит название "уязвимость нулевого дня". Сам термин означает, что у разработчиков было 0 дней на исправление дефекта.

Анализаторы второго типа помогают обнаруживать ошибки, которые потенциально могут стать причиной уязвимости. Большое количество таких паттернов ошибок, собраны в CWE и многие разработчики анализаторов ориентируется на эту базу.

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

PVS-Studio является одним из инструментов, реализующих второе направление поиска дефектов безопасности, и сейчас мы рассмотрим его подробнее.

Развитие PVS-Studio как SAST решения

Изначально PVS-Studio разрабатывался как классический статический анализатор кода. Он позволяет находить широкий спектр ошибок в коде программ, написанных на языках C, C++, C# и Java. Вы можете познакомиться с различными статьями о проверке с его помощью открытых проектов, чтобы оценить его диагностические возможности.

Со временем появилось понимание, что многое из того, что умеет делать анализатор PVS-Studio, является ничем иным, как тестированием безопасности кода. Другими словами, анализатор хорошо умеет находить потенциальные уязвимости (см. примеры).

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

The National Institute of Standards and Technology (NIST) reports that 64% of software vulnerabilities stem from programming errors and not a lack of security features.

Ошибки безопасности — это всё те же привычные классические ошибки, такие как выход за границу массива, некорректные условия, опечатки и так далее. Вот только негативные последствия от таких ошибок в некоторых случаях куда заметнее и дороже.

Большое количество этих ошибок уже умел находить PVS-Studio, и его использование позволяет сделать код программ надёжнее и безопаснее. Однако это не значит, что наша команда просто приписала к PVS-Studio слово SAST и на этом всё закончилось :).

Ранее в статье мы упоминали Common Weakness Enumeration (CWE). Мы изучили этот ресурс и взяли примеры ошибок, которые ещё не умел обнаруживать PVS-Studio. Со временем, при разработке новых диагностических правил, мы стали наращивать количество правил, которые могут быть классифицированы как потенциальные уязвимости. Помимо этого, для удобства пользователей мы сопоставили выдаваемые анализатором сообщения согласно классификации CWE. Теперь в анализаторе можно включить отображение CWE идентификаторов (CWE-ID).

Чтобы усилить возможности PVS-Studio, наша команда также обратила внимание на SEI CERT Coding Standard. Это набор стандартов написания программного обеспечения (ПО) на языках C, C++, Java и Perl, разрабатываемых координационным центром CERT (CERT Coordination Center, CERT/CC) для повышения надёжности и безопасности ПО. См. также таблицу классификации предупреждений PVS-Studio согласно SEI CERT Coding Standard.

Ещё одним направлением работ стала поддержка стандартов MISRA C и MISRA C++. Эти стандарты не совсем связаны с уязвимостями. Если стандарты CWE и CERT можно назвать общим словом "security", то стандарты MISRA относятся уже к "safety" категории. Цель MISRA - улучшить безопасность, переносимость и надежность программ для встраиваемых систем. В любом случае, стандарт MISRA часто упоминается в контексте SAST или как смежная этому тема. Таблица соответствия.

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

Будущее SAST и safety направлений в PVS-Studio

Как уже говорилось в начале статьи, мы видим попадание PVS-Studio в отчёт Forester Research хорошим индикатором правильности выбранного направления развития. Конечно, развивая SAST возможности анализатора, мы не забывали и про "традиционные" диагностики общего назначения, поддержку новых компиляторов, языков, embedded систем, CI/CD инфраструктуры использования анализатора, и прочие направления, которые традиционно затрагивал PVS-Studio. Более того, данные направления хорошо дополняют друг друга.

Мы не будем останавливаться на достигнутом и продолжим развивать SAST и Safety направления в PVS-Studio. Будет расширяться поддержка MISRA C / MISRA C++ стандартов. Планируем рассмотреть возможность начать реализовывать в рамках Java и C# анализаторов правила из стандарта OWASP. Для C и C++ анализатора нам кажется перспективным движение в сторону поддержки стандарта AUTOSAR.

Дополнительные ссылки