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

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

![0759_PVS-Studio_SAST_Forrester_ru/image1.png](https://import.viva64.com/docx/blog/0759_PVS-Studio_SAST_Forrester_ru/image1.png)

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

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

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

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

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

Перечисленные методологии органически вливаются в процесс разработки и можно сказать, что их внедрение превращает [DevOps в DevSecOps](https://pvs-studio.ru/ru/blog/posts/0710/)\.

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

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

Анализаторы первого типа работают по принципу антивируса\. Им известно, как выглядят фрагменты кода, содержащие известные уязвимости \([CVE](https://ru.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)\)\. Эти фрагменты они и ищут в коде проверяемых проектов\. На практике всё немного сложней, но общая идея именно такая\.

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

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

Приложение может содержать ошибку, которая некоторое время будет оставаться незамеченной\. Если хакер обнаружит такую ошибку и придумает, как её можно эксплуатировать, то она превратится в новую уязвимость\. Такой только что выявленный опасный дефект носит название "[уязвимость нулевого дня](https://ru.wikipedia.org/wiki/%D0%A3%D1%8F%D0%B7%D0%B2%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C_%D0%BD%D1%83%D0%BB%D0%B5%D0%B2%D0%BE%D0%B3%D0%BE_%D0%B4%D0%BD%D1%8F)"\. Сам термин означает, что у разработчиков было 0 дней на исправление дефекта\.

Анализаторы второго типа помогают обнаруживать ошибки, которые потенциально могут стать причиной уязвимости\. Большое количество таких паттернов ошибок, собраны в [CWE](https://en.wikipedia.org/wiki/Common_Weakness_Enumeration) и многие разработчики анализаторов ориентируется на эту базу\.

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

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

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

Изначально [PVS\-Studio](https://pvs-studio.ru/ru/pvs-studio/) разрабатывался как классический статический анализатор кода\. Он позволяет находить широкий спектр ошибок в коде программ, написанных на языках C, C\+\+, C\# и Java\. Вы можете познакомиться с различными [статьями](https://pvs-studio.ru/ru/blog/inspections/) о проверке с его помощью открытых проектов, чтобы оценить его диагностические возможности\.

Со временем появилось понимание, что многое из того, что умеет делать анализатор PVS\-Studio, является ничем иным, как тестированием безопасности кода\. Другими словами, анализатор хорошо умеет находить потенциальные уязвимости \(см\. [примеры](https://pvs-studio.ru/ru/blog/posts/cpp/0514/)\)\.

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


> 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](https://cwe.mitre.org/)\)\. Мы изучили этот ресурс и взяли примеры ошибок, которые ещё не умел обнаруживать PVS\-Studio\. Со временем, при разработке новых диагностических правил, мы стали наращивать количество правил, которые могут быть классифицированы как потенциальные уязвимости\. Помимо этого, для удобства пользователей мы [сопоставили](https://pvs-studio.ru/ru/pvs-studio/sast/cwe/) выдаваемые анализатором сообщения согласно классификации CWE\. Теперь в анализаторе можно включить отображение CWE идентификаторов \(CWE\-ID\)\.

Чтобы усилить возможности PVS\-Studio, наша команда также обратила внимание на [SEI CERT Coding Standard](https://wiki.sei.cmu.edu/confluence/)\. Это набор стандартов написания программного обеспечения \(ПО\) на языках C, C\+\+, Java и Perl, разрабатываемых координационным центром CERT \(CERT Coordination Center, CERT/CC\) для повышения надёжности и безопасности ПО\. См\. также [таблицу](https://pvs-studio.ru/ru/pvs-studio/sast/cert/) классификации предупреждений PVS\-Studio согласно SEI CERT Coding Standard\.

Ещё одним направлением работ стала поддержка стандартов MISRA C и MISRA C\+\+\. Эти стандарты не совсем связаны с уязвимостями\. Если стандарты CWE и CERT можно назвать общим словом "security", то стандарты MISRA относятся уже к "safety" категории\. Цель MISRA \- улучшить безопасность, переносимость и надежность программ для встраиваемых систем\. В любом случае, стандарт MISRA часто упоминается в контексте SAST или как смежная этому тема\. [Таблица соответствия](https://pvs-studio.ru/ru/pvs-studio/sast/misra/)\.

**Проделав всю эту работу, мы можем сейчас добросовестно говорить, что инструмент 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\.

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

1. [Статический анализатор кода PVS\-Studio как защита от уязвимостей нулевого дня](https://pvs-studio.ru/ru/blog/posts/0689/)\.
1. [Технологии, используемые в анализаторе кода PVS\-Studio для поиска ошибок и потенциальных уязвимостей](https://pvs-studio.ru/ru/blog/posts/cpp/0592/)\.
1. [Причины внедрить в процесс разработки статический анализатор кода PVS\-Studio](https://pvs-studio.ru/ru/blog/posts/0687/)\.
1. [Now Tech: Static Application Security Testing, Q3 2020](https://www.forrester.com/report/Now+Tech+Static+Application+Security+Testing+Q3+2020/-/E-RES161475)\.