Статистический анализ исходного кода

Статистический анализ исходного кода

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

Обзор кода (code review) – один из самых старых и надежных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе чтения кода выявляются ошибки или участки кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Более подробно с методикой обзора кода можно познакомиться в замечательной книге Стива Макконнелла "Совершенный код" (Steve McConnell, "Code Complete") [1].

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

Получается, что с одной стороны хочется регулярно осуществлять обзор кода. С другой — это слишком дорого. Компромиссным решением являются инструменты статического анализа кода. Они без устали обрабатывают исходные тексты программ и выдают программисту рекомендации обратить повышенное внимание на определенные участки кода. Конечно, программа не заменит полноценного обзора кода, выполняемого коллективом программистов. Однако соотношение польза/цена делает использование статического анализа весьма полезной практикой, применяемой многими компаниями.

Задачи, решаемые программами статического анализа кода можно разделить на 3 категории:

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

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

Существует большое количество коммерческих и бесплатных статических анализаторов кода. Большой список статических анализаторов имеется на сайте Wikipedia: List of tools for static code analysis. Список языков, для которых существуют статические анализаторы кода, также достаточно велик (Си, Си++, C#, Java, Ada, Fortran, Perl, Ruby, . ).

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

Главное преимущество статического анализ состоит в возможности существенной снижении стоимости устранения дефектов в программе. Чем раньше ошибка выявлена, тем меньше стоимость ее исправления. Так согласно данным, приведенным в книге Макконнелла "Совершенный Код", исправление ошибки на этапе тестирования обойдется в десять раз дороже, чем на этапе конструирования (написания кода):

Рисунок 1. Средняя стоимость исправления дефектов в зависимости от времени их внесения и обнаружения (данные для таблицы взяты из книги С. Макконнелла "Совершенный Код").

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

Другие преимущества статического анализа кода:

  • Полное покрытие кода. Статические анализаторы проверяют даже те фрагменты кода, которые получают управление крайне редко. Такие участки кода, как правило, не удается протестировать другими методами. Это позволяет находить дефекты в обработчиках редких ситуаций, в обработчиках ошибок или в системе логирования.
  • Статический анализ не зависит от используемого компилятора и среды, в которой будет выполняться скомпилированная программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки неопределенного поведения. Такие ошибки могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода. Другой интересный пример скрытых ошибок приводится в статье "Перезаписывать память — зачем?".
  • Можно легко и быстро обнаруживать опечатки и последствия использования Copy-Paste. Как правило, нахождение этих ошибок другими способами является кране неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида "strcmp(A, A)". Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Недостатки статического анализа кода

  • Статический анализ, как правило, слаб в диагностике утечек памяти и параллельных ошибок. Чтобы выявлять подобные ошибки, фактически необходимо виртуально выполнить часть программы. Это крайне сложно реализовать. Также подобные алгоритмы требуют очень много памяти и процессорного времени. Как правило, статические анализаторы ограничиваются диагностикой простых случаев. Более эффективным способом выявления утечек памяти и параллельных ошибок является использование инструментов динамического анализа.
  • Программа статического анализа предупреждает о подозрительных местах. Это значит, что на самом деле код, может быть совершенно корректен. Это называется ложно-позитивными срабатываниями. Понять, указывает анализатор на ошибку или выдал ложное срабатывание, может только программист. Необходимость просматривать ложные срабатывания отнимает рабочее время и ослабляет внимание к тем участкам кода, где в действительности содержатся ошибки.

Ошибки, обнаруживаемые статическими анализаторами весьма разнообразны. Вот, например, список диагностик, которые реализованы в инструменте PVS-Studio. Некоторые анализаторы специализируются на определенной области или типах дефектов. Другие, поддерживают определенные стандарты кодирование, например MISRA-C:1998, MISRA-C:2004, Sutter-Alexandrescu Rules, Meyers-Klaus Rules и так далее.

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

Содержание статьи

У каждого из команды ][ — свои предпочтения по части софта и утилит для
пентеста. Посовещавшись, мы выяснили: выбор так разнится, что можно составить
настоящий джентльменский набор из проверенных программ. На том и решили. Чтобы
не делать сборную солянку, весь список разбит на темы. Сегодня мы разберем
статические анализаторы кода
для поиска уязвимостей в приложениях, когда на
руках – их исходники.

Наличие исходных кодов программы существенно упрощает поиск уязвимостей.
Вместо того чтобы вслепую манипулировать различными параметрами, которые
передаются приложению, куда проще посмотреть в сорцах, каким образом она их
обрабатывает. Скажем, если данные от пользователя передаются без проверок и
преобразований, доходят до SQL-запроса – имеем уязвимость типа SQL injection.
Если они добираются до вывода в HTML-код – получаем классический XSS. От
статического сканера требуется четко обнаруживать такие ситуации, но, к
сожалению, выполнить это не всегда так просто как кажется.

Читайте также:  Via hd audio панель управления

Современные компиляторы

Может показаться забавным, но одними из самых эффективных анализаторов
кода
являются сами компиляторы. Конечно, предназначены они совсем для
другого, но в качестве бонуса каждый из них предлагает неплохой верификатор
исходников, способный обнаружить большое количество ошибок. Почему же он не
спасает? Изначально настройки такой верификации кода выставлены достаточно
лояльно: в результате, чтобы не смущать программиста, компилятор начинает
ругаться только в случае самых серьезных косяков. А вот и зря — если поставить
уровень предупреждений повыше, вполне реально откопать немало сомнительных мест
в коде. Выглядит это примерно следующим образом. Скажем, в коде есть отсутствие
проверки на длину строки перед копированием ее в буфер. Сканер находит функцию,
копирующую строку (или ее фрагмент) в буфер фиксированного размера без
предварительной проверки ее длины. Он прослеживает траекторию передачи
аргументов: от входных данных до уязвимой функции и смотрит: возможно ли
подобрать такую длину строки, которая бы вызывала переполнение в уязвимой
функции и не отсекалась бы предшествующими ей проверками. В случае если такой
проверки нет, находим практически 100% переполнение буфера. Главная сложность в
использовании для проверки компилятора — заставить его "проглотить" чужой код.
Если ты хоть раз пытался скомпилировать приложение из исходников, то знаешь,
насколько сложно удовлетворить все зависимости, особенно в больших проектах. Но
результат стоит того! Тем более, помимо компилятора в мощные IDE встроены и
некоторые другие средства для анализа кода. К примеру, на следующий
участок кода в Visual Studio будет выдано предупреждение об использовании в
цикле функции _alloca, что может быстро переполнить стек:

char *b;
do <
b = (char*)_alloca(9)
> while(1)

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

RATS — Rough Auditing Tool for Security

Сайт: www.securesoftware.com
Лицензия: GNU GPL
Платформа: Unix, Windows
Языки: С++, PHP, Python, Ruby

Ошибка ошибке — рознь. Часть тех огрех, которые допускают программисты,
некритична и грозит только нестабильностью программы. Другие, напротив,
позволяют инжектировать шелл-код и выполнять произвольные команды на удаленном
сервере. Особый риск в коде представляют команды, позволяющие выполнить buffer
overflow и другие похожие типы атак. Таких команд очень много, в случае с C/C++
это функции для работы со строками (xstrcpy(), strcat(), gets(), sprintf(),
printf(), snprintf(), syslog()), системные команды (access(), chown(), chgrp(),
chmod(), tmpfile(), tmpnam(), tempnam(), mktemp()), а также команды системных
вызовов (exec(), system(), popen()). Вручную исследовать весь код (особенно,
если он состоит из нескольких тысяч строк) довольно утомительно. А значит, можно
без труда проглядеть передачу какой-нибудь функции непроверенных параметров.
Значительно облегчить задачу могут специальные средства для аудита, в том числе,
известная утилита RATS (Rough Auditing Tool for Security) от
известной компании Fortify. Она не только успешно справится с обработкой кода,
написанного на C/C++, но сможет обработать еще и скрипты на Perl, PHP и Python.
В базе утилиты находится внушающая подборка с детальным описанием проблемных
мест в коде. С помощью анализатора она обработает скормленный ей сорец и
попытается выявить баги, после чего выдаст информацию о найденных недочетах.
RATS
работает через командную строку, как под Windows, так и *nix-системами.

Yasca

Сайт: www.yasca.org
Лицензия: Open Source
Платформа: Unix, Windows
Языки: С++, Java, .NET, ASP, Perl, PHP, Python и другие.

Yasca так же, как и RATS не нуждается в установке, при этом имеет не
только консольный интерфейс, но и простенький GUI. Разработчики рекомендуют
запускать утилиту через консоль — мол, так возможностей больше. Забавно, что
движок Yasca написан на PHP 5.2.5, причем интерпретатор (в самом урезанном
варианте) лежит в одной из подпапок архива с программой. Вся программа логически
состоит из фронт-енда, набора сканирующих плагинов, генератора отчета и
собственно движка, который заставляет все шестеренки вращаться вместе. Плагины
свалены в директорию plugins — туда же нужно устанавливать и дополнительные
аддоны. Важный момент! Трое из стандартных плагинов, которые входят в состав
Yasca
, имеют неприятные зависимости. JLint, который сканирует Java’овские
.class-файлы, требует наличия jlint.exe в директории resource/utility. Второй
плагин — antiC, используемый для анализа сорцов Java и C/C++, требует antic.exe
в той же директории. А для работы PMD, который обрабатывает Java-код, необходима
установленная в системе Java JRE 1.4 или выше. Проверить правильность установки
можно, набрав команду "yasca ./resources/test/". Как выглядит сканирование?
Обработав скормленные программе сорцы, Yasca выдает результат в виде
специального отчета. Например, один из стандартных плагинов GREP позволяет с
помощью паттернов, описанных в .grep файлах, указать уязвимые конструкции и
легко выявлять целый ряд уязвимостей. Набор таких паттернов уже включен в
программу: для поиска слабого шифрования, авторизации по "пароль равен логину",
возможные SQL-инъекции и много чего еще. Когда же в отчете захочется увидеть
более детальную информации, не поленись установить дополнительные плагины. Чего
стоит одно то, что с их помощью можно дополнительно просканировать код на на
.NET (VB.NET, C#, ASP.NET), PHP, ColdFusion, COBOL, HTML, JavaScript, CSS,
Visual Basic, ASP, Python, Perl.

Cppcheck

Сайт:
cppcheck.wiki.sourceforge.net
Лицензия: Open Source
Платформа: Unix, Windows
Языки: С++

Разработчики Cppcheck решили не разбрасываться по мелочам, а потому
отлавливают только строго определенные категории багов и только в коде на С++.
Не жди, что программа продублирует предупреждения компилятора — он обойдется без
суфлера. Поэтому не поленись поставить для компилятора максимальный уровень
предупреждений, а с помощью Cppcheck проверь наличие утечек памяти, нарушений
операций allocation-deallocation, различных переполнений буфера, использования
устаревших функций и многого другого. Важная деталь: разработчики Cppcheck
постарались свести количество ложных срабатываний к минимуму. Поэтому, если
прога фиксирует ошибку, можно с большой вероятностью сказать: "Она действительно
есть!" Запустить анализ можно как из-под консоли, так и с помощью приятного
GUI-интерфейса, написанного на Qt и работающего под любой платформой.

graudit

Сайт:
www.justanotherhacker.com/projects/graudit.html
Лицензия: Open Source
Платформа: Unix, Windows
Языки: C++, PHP, Python, Perl

Этот простой скрипт, совмещенный с набором сигнатур, позволяет найти ряд
критических уязвимостей в коде, причем поиск осуществляется с помощью всем
известной утилиты grep. О GUI-интерфейсе тут неуместно даже упоминать: все
осуществляется через консоль. Для запуска есть несколько ключей, но в самом
простом случае достаточно указать в качестве параметра путь к исходникам:

Наградой за старание будет цветастый отчет о потенциально эксплуатируемых
местах в коде. Надо сказать, что, помимо самого скрипта (а это всего 100 строчек
кода на Bash), ценность представляют сигнатурные базы, в которых собраны
регекспы и названия потенциально уязвимых функций в разных языках. По умолчанию
включены базы для Python, Perl, PHP, C++ — можно взять файлы из папки signatures
и использовать в своих собственных разработках.

SWAAT

Сайт: www.owasp.org
Лицензия: Open Source
Платформа: Unix, Windows
Языки: Java, JSP, ASP .Net, PHP

Если в graudit для задания сигнатуры уязвимости используются текстовые файлы,
то в SWAAT – более прогрессивный подход с помощью XML-файлов. Вот так
выглядит типичная сигнатура:

Читайте также:  Площадь поперечного сечения в чем измеряется

vuln match — регулярное выражение для поиска;
type — указывает на тип уязвимости:
severity — обозначает уровень риска (high, medium или low)
alt — альтернативный вариант кода для решения проблемы

SWAAT считывает базу сигнатур и с ее помощью пытается найти проблемные
участки кода в исходниках на Java, JSP, ASP .Net, и PHP. База постоянно
пополняется и помимо списка "опасных" функций, сюда включены типичные ошибки в
использовании форматирования строк и составлении SQL-запросов. Примечательно,
что прога написана на C#, однако отлично работает и под никсами, благодаря
проекту Mono — открытой реализации платформы .Net.

PHP Bug Scanner

Если тебе нужно провести статический анализ PHP-приложения, рекомендую
попробовать PHP Bug Scanner, которую написал наш автор — raz0r. Работа
проги основана на сканировании различных функций и переменных в PHP-скриптах,
которые могут быть задействованы при проведении веб-атак. Описание таких
ситуаций оформляется в виде так называемых пресетов, причем в программу уже
включены 7 специальных прессетов, сгруппированных по категориям:

  • code execution;
  • command execution;
  • directory traversal;
  • globals overwrite;
  • include;
  • SQL-injection;
  • miscellaneous.

Забавно, что прога написана на
PHP/WinBinder и скомпилирована
bamcompile, поэтому выглядит так же, как и обычное Windows-приложение. Через
удобный интерфейс пентестер может включить или отключь анализ кода на наличие
тех или иных уязвимостей.

Сайт:
pixybox.seclab.tuwien.ac.at
Лицензия: Freeware
Платформа: Unix, Windows
Языки: PHP

В основе работы инструмента — сканирование исходного кода и построение графов
потоков данных. По такому графу прослеживается путь данных, которые поступают
извне программы — от пользователя, из базы данных, от какого-нибудь внешнего
плагина и т.п. Таким образом строится список уязвимых точек (или входов) в
приложениях. С помощью паттернов, описывающих уязвимость, Pixy проверяет такие
точки и позволяет определить XSS- и SQL-уязвимости. Причем сами графы, которые
строятся во время анализа, можно посмотреть в папке graphs (например,
xss_file.php_1_dep.dot) — это очень полезно для того чтобы понять, почему именно
тот или иной участок кода считается Pixy-уязвимым. Вообще, сама разработка
крайне познавательна и демонстрирует, как работают продвинутые утилиты для
статического анализа кода. На страничке

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

Ounce 6

Сайт: www.ouncelabs.com/products
Лицензия: Shareware
Платформа: Windows

Увы, существующие бесплатные решения пока на голову ниже, чем коммерческие
аналоги. Достаточно изучить качество и детальность отчета, который составляет
Ounce 6
– и понять, почему. В основе программы лежит специальный
анализирующий движок Ounce Core, который проверяет код на соответствие правилам
и политикам, составленными командой профессиональных пентестеров,
аккумулировавших опыт известных security-компаний, хакерского комьюнити, а также
стандартов безопасности. Программа определяет самые разные уязвимости в коде: от
переполнения буфера до SQL-инъекций. При желании Ounce несложно интегрируется с
популярными IDE, чтобы реализовать автоматическую проверку кода во время сборки
каждого нового билда разрабатываемого приложения. Кстати говоря,
компанию-разработчика — Ounce Labs — летом этого года приобрела сама IBM. Так
что продукт, скорее всего, продолжит развитие уже как часть одного из
коммерческих приложений IBM.

Klocwork Insight

Сайт: www.klocwork.com
Лицензия: Shareware
Платформа: Windows
Языки: C++, Java, C#

Долгое время этот, опять же, коммерческий продукт реализовал статическое
сканирование кода только для C, C+ и Java. Но, как только вышли Visual Studio
2008 и .NET Framework 3.5, разработчики заявили о поддержке C#. Я прогнал
программу на двух своих вспомогательных проектах, которые на скорую руку написал
на "шарпе" и программа выявила 7 критических уязвимостей. Хорошо, что они
написаны исключительно для внутреннего использования :). Klocwork Insight
изначально настроен, прежде всего, на работу в связке с интегрированными средами
разработки. Интеграция с теми же Visual Studio или Eclipse выполнена чрезвычайно
удачно – начинаешь всерьез задумываться, что такая функциональность должна быть
реализована в них по умолчанию :). Если не брать в расчет проблемы с логикой
работы приложения и проблемы с быстродействием, то Klocwork Insight
отлично справляется с поиском переполнения буфера, отсутствия фильтрации
пользовательского кода, возможности SQL/Path/Cross-site инъекций, слабого
шифрования и т.п. Еще одна интересная опция – построение дерева выполнения
приложения, позволяющего быстро вникнуть в общий принцип работы приложения и
отдельно проследить, например, за обработкой какого-либо пользовательского
ввода. А для быстрого конструирования правил для проверки кода предлагается даже
специальный инструмент — Klocwork Checker Studio.

Coverity Prevent Static Analysis

Сайт: www.coverity.com/products
Лицензия: Shareware
Платформа: Windows
Языки: C++, Java, C#

Один из самых известных статических анализаторов кода на C/C++, Java и C#.
Если верить его создателям, – решение используется более чем 100.000
разработчиков по всему миру. Продуманные механизмы позволяют автоматизировать
поиск утечек памяти, неотловленных исключений, проблем с быстродействием и,
конечно же, уязвимостей в безопасности. Продукт поддерживает разные платформы,
компиляторы (gcc, Microsoft Visual C++ и многие другие), а также интегрируется с
различными средами разработки, прежде всего Eclipse и Visual Studio. В основе
обхода кода используются не тупые алгоритмы обхода от начала до конца, а что-то
вроде отладчика, анализирующего, как программа поведет в себя в различных
ситуациях после встречи ветвления. Таким образом достигается 100% покрытия кода.
Столь сложный подход потребовался в том числе, чтобы всецело анализировать
многопоточные приложения, специально оптимизированные для работы на многоядерных
процессорах. Coverity Integrity Center позволяет находить такие ошибки
как состояние гонки (ошибка проектирования многозадачной системы, при которой
работа системы зависит от того, в каком порядке выполняются части кода), тупики
и многое другое. Зачем это нужно реверсерам? Спроси об этом разработчиков 0day
сплоитов для Firefox и IE :).

OWASP Code Crawler

Сайт: www.owasp.org
Лицензия: GNU GPL
Платформа: Windows
Языки: Java, C#, VB

Создатель этой тулзы Алессио Марциали — автор двух книжек по ASP.NET,
авторитетный кодер высоконагруженных приложений для финансового сектора, а также
пентестер. В 2007 году он опубликовал информацию о критических уязвимостях в 27
правительственных сайтах Италии. Его детище – OWASP Code Crawler
предназначенное для статического анализа кода .NET и J2EE/JAVA, открыто доступно
в инете, а в конце года автор обещается выпустить новую версию программы с
намного большей функциональностью. Но самое-то главное реализовано уже сейчас –
анализ исходников на C#, Visual Basic и Java. Файлы для проверки выбираются
через GUI-интерфейс, а сканирование запускается автоматически. Для каждого
проблемного участка кода выводится описание уязвимости в разделе Threat
Description. Правда, поле OWASP Guidelines, вероятно, указывающее пути
решения проблемы, увы, пока не доступно. Зато можно воспользоваться
экспериментальной особенностью сканирования кода на удаленной машине, доступной
во вкладке Remote Scan. Автор обещает серьезно прокачать эту возможность и, в
том числе, агрегировать исходники приложения для анализа прямо из системы
контроля версий.

WARNING

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

Читайте также:  Как добавить почту в мозиле

Краткий обзор статических анализаторов кода на C/C++

При написании кода на C и C++ люди допускают ошибки. Многие из этих ошибок находятся благодаря -Wall , ассертам, тестам, дотошному code review, предупреждениям со стороны IDE, сборкой проекта разными компиляторами под разные ОС, работающие на разном железе, и так далее. Но даже при использовании всех этих мер ошибки часто остаются незамеченными. Немного улучшить положение дел позволяет статический анализ кода. В этой заметке мы познакомимся с некоторыми инструментами для произведения этого самого статического анализа.

CppCheck

CppCheck является бесплатным кроссплатформенным статическим анализатором с открытым исходным кодом (GPLv3). Он доступен в пакетах многих *nix систем из коробки. Также CppCheck умеет интегрироваться со многими IDE. На момент написания этих строк CppCheck является живым, развивающимся проектом.

[some.c:57]: (error) Common realloc mistake: ‘numarr’ nulled but not
freed upon failure

[some.c:154]: (error) Dangerous usage of ‘n’ (strncpy doesn’t always
null-terminate it)

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

Clang Static Analyzer

Еще один бесплатный кроссплатформенный статический анализатор с открытыми исходным кодом. Является частью так называемого LLVM-стэка. В отличие от CppCheck работает существенно медленнее, но и ошибки находит куда более серьезные.

Пример построения отчета для PostgreSQL:

Пример построения отчета для ядра FreeBSD:

Идея, как несложно догадаться, заключается в том, чтобы сделать clean, а затем запустить сборку под scan-build.

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

В данном контексте не могу не отметить, что в мире Clang/LLVM есть еще и средства динамического анализа, так называемые «санитайзеры». Их много, они находят очень крутые ошибки и работают быстрее, чем Valgrind (правда, только под Linux). К сожалению, обсуждение санитайзеров выходит за рамки настоящей заметки, поэтому ознакомьтесь с ними самостоятельно.

PVS-Studio

Закрытый статический анализатор, распространяемый за деньги. PVS-Studio работает только под Windows и только с Visual Studio. Есть многочисленные сведения о существовании Linux-версии, но на официальном сайте она не доступна. Насколько я понял, цена лицензии обсуждается индивидуально с каждым клиентом. Доступен триал.

Я протестировал PVS-Studio 6.02 на Windows 7 SP1 работающей под KVM с установленной Visual Studio 2013 Express Edition. Во время установки PVS-Studio также дополнительно скачался .NET Framework 4.6. Выглядит это примерно так. Вы открываете проект (я тестировал на PostgreSQL) в Visual Studio, в PVS-Studio жмете «сейчас я начну собирать проект», затем в Visual Studio нажимаете Build, по окончании сборки в PVS-Studio жмете «я закончил» и смотрите отчет.

PVS-Studio действительно находит очень крутые ошибки, которые Clang Static Analyzer не видит (например). Также очень понравился интерфейс, позволяющий сортировать и фильтровать ошибки по их типу, серьезности, файлу, в котором они были найдены, и так далее.

С одной стороны, печалит, что чтобы использовать PVS-Studio, проект должен уметь собираться под Windows. С другой стороны, использовать в проекте CMake и собирать-тестировать его под разными ОС, включая Windows, при любом раскладе является очень неплохой затеей. Так что, пожалуй, это не такой уж и большой недостаток. Кроме того, по следующим ссылкам можно найти кое-какие подсказки касательно того, как людям удавалось прогонять PVS-Studio на проектах, которые не собираются под Windows: раз, два, три, четыре.

Дополнение: Попробовал бета-версию PVS-Studio для Linux. Пользоваться ею оказалось очень просто. Создаем pvs.conf примерно такого содержания:

40 Мб) файл strace_out
pvs-studio-analyzer analyze —cfg . / pvs.conf
plog-converter -t tasklist -o result.task pvs-output.log

Дополнение: PVS-Studio для Linux вышел из беты и теперь доступен всем желающим.

Coverity Scan

Coverity считается одним из самых навороченных (а следовательно и дорогих) статических анализаторов. К сожалению, на официальном сайте невозможно скачать даже его триал-версию. Можно заполнить форму, и если вы какой-нибудь IBM, с вами может быть свяжутся. При очень сильном желании Coverity какой-нибудь доисторической версии можно найти через неофициальные каналы. Он бывает для Windows и Linux, работает примерно по тому же принципу, что и PVS-Studio. Но без серийника или лекарства отчеты Coverity вам не покажет. А чтобы найти серийник или лекарство, нужно иметь не просто очень сильное желание, а очень-очень-очень сильное.

К счастью, у Coverity есть SaaS версия — Coverity Scan. Мало того, что Coverity Scan доступен для простых смертных, он еще и совершенно бесплатен. Привязки к конкретной платформе нет. Однако анализировать с помощью Coverity Scan разрешается только открытые проекты.

Вот как это работает. Вы регистрируете свой проект через веб-интерфейс (или присоединяетесь к уже существующему, но это менее интересный кейс). Чтобы посмотреть отчеты, нужно пройти модерацию, которая занимает 1-2 рабочих дня.

Отчеты строятся таким образом. Сначала вы локально собираете свой проект под специальной утилитой Coverity Build Tool. Утилита эта аналогична scan-build из Clang Static Analyzer и доступна под все мыслимые платформы, включая всякую экзотику типа FreeBSD или даже NetBSD.

Установка Coverity Build Tool:

Готовим тестовый проект (я использовал код из заметки Продолжаем изучение OpenGL: простой вывод текста):

Затем собираем проект под cov-build:

Важно! Не меняйте название директории cov-int.

Архивируем директорию cov-int:

Заливаем архив через форму Upload a Project Build. Также на сайте Coverity Scan есть инструкции по автоматизации этого шага при помощи curl. Ждем немного, и можно смотреть результаты анализа. Примите во внимание, что чтобы пройти модерацию, нужно отправить на анализ хотя бы один билд.

Ошибки Coverity Scan ищет очень хорошо. Уж точно лучше, чем Clang Static Analyzer. При этом ложно-положительные срабатывания есть, но их намного меньше. Что удобно, в веб-интерфейсе есть что-то вроде встроенного багтрекера, позволяющего присваивать ошибкам серьезность, ответственного за их исправление и подобные вещи. Видно, какие ошибки новые, а какие уже были в предыдущих билдах. Ложно-положительные срабатывания можно отметить как таковые и скрыть.

Заметьте, что чтобы проанализировать проект в Coverity Scan, не обязательно быть его владельцем. Мне лично вполне успешно удалось проанализировать код PostgreSQL без присоединения к уже существующему проекту. Думается также, что при сильном желании (например, используя сабмодули Git), можно подсунуть на проверку немного и не очень-то открытого кода.

Заключение

Вот еще несколько статических анализаторов, не попавших в обзор:

Каждый из рассмотренных анализаторов находят такие ошибки, которые не находят другие. Поэтому в идеале лучше использовать их сразу все. Делать это вот прямо постоянно, скорее всего, объективно не получится. Но делать хотя бы один прогон перед каждым релизом точно будет не лишним. При этом Clang Static Analyzer выглядит наиболее универсальным и при этом достаточно мощным. Если вас интересует один анализатор, который нужно обязательно использовать в любом проекте, используйте его. Но все же я бы рекомендовал дополнительно использовать как минимум PVS-Studio или Coverity Scan.

А какие статические анализаторы вы пробовали и/или регулярно использовали и каковы ваши впечатления от них?

Ссылка на основную публикацию
Сравнить технические характеристики rx330 и rx350
Линейка популярных люксовых SUV Lexus RX пополнилась новой модификацией – RX 350. Теперь покупателем RX быть еще приятнее – ведь...
Сколько рублей получают ютуберы
Видеохостинг YouTube — не только развлекательная площадка, но и хороший источник дохода. Тысячи пользователей выкладывают ролики, пытаясь привлечь внимание аудитории....
Сколько света мотает компьютер
Выбирая комплектующие для персонального компьютера (ПК) обычно обращают внимание на производительность и объем памяти, порой забывая о том, сколько же...
Сравнить процессоры кирин и снапдрагон
Snapdragon 636 vs. Kirin 960: кто лучше? Результаты тестов и сравнительных таблиц, описанных в этой статье, помогут определить, какой из...
Adblock detector