Static code analysis 3: обзор инструментов и заключение

Это третья часть цикла. Начало: http://itech-notes.blogspot.com/2014/09/sca-1.html и http://itech-notes.blogspot.com/2014/09/sca-2.html.

ОБЗОР ИНСТРУМЕНТОВ SCA

Некоторые SCA дают возможность выбирать предустановленные правила и шаблоны. Другие разрешают самостоятельно писать шаблоны на встроенных языках, xml или java.

Вот пара полезных статей со списком различных существующих инструментов анализа:

http://www.xakep.ru/post/51166/ – лучшие инструменты пентестера: статический анализ кода.

http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis – List of tools for static code analysis

OWASP Code Crawler

http://www.owasp.org/, GNU GPL

Предназначен для статического анализа кода, открыто доступен в интернете, позволяет анализировать исходные коды на с#, visual basic и java. Файлы для проверки выбираются через gui-интерфейс (по одному), а сканирование запускается автоматически. Отображается общее количество обнаруженных уязвимостей, их уровни обозначены цветом (зелёный, жёлтый, красный). Для каждого проблемного участка кода выводится описание уязвимости в разделе Threat Description. При необходимости можно исключить уязвимость из анализа (mark as false positive).
Пишут, что на этот инструмент были большие планы, но на сегодняшний момент (декабрь 2k14) последний релиз – 2.7 в апреле 2010 года (вот ссылка для скачивания http://codecrawler.codeplex.com/releases/view/43887).
Данные об уязвимостях хранит в виде xml: судя по текстам, может предупреждать о потенциальных уязвимостях xss, sql injection, command injection и пр. При желании можно легко написать собственное правило.
Есть и неудобства. При выборе файла диалоговое окно у меня всегда открывалось на папке «Документы», а для имени всегда была установлена маска *.cs; это приводит к ненужным тратам времени. В работе тоже не всё гладко. Вот пример кода:

// Create the selector that specifies the starting certificate
X509CertSelector selector = new X509CertSelector();
selector.setCertificate(subjCert);

Crawler его подсветил с подсказкой «Using SELECT * makes your code vulnerable to changes in underlying table(s) and as such should be avoided». Т. е. анализ фактически очень простой, по самому факту наличия ключевых слов.

Скриншот Crawler на примере одного тестового файла

JAVA checker

http://www.gradsoft.ua/products/javachecker_rus.html

Ещё один из опробованных инструментов SCA. Скачиваем инсталятор, устанавливаем программу.

JavaChecker.bat --help
JavaChecker.bat --prefs ../etc/pref1.xml E:\padss
JavaChecker.bat --prefs ../etc/pref1.xml E:\padss --output E:\padss\output.txt --debug 2> E:\padss\debug.txt

Документация JavaChecker2Guide есть. Настройка через проперти/xml-файлы. Графического интерфейса нет, результат анализа выводится в текстовый файл, с указанием выявленной проблемы, файла и номера строки кода. Удобно то, что на вход можно не один файл, а целиком пакет подать. Вот маленький пример работы программы:

C:\Program Files\JavaChecker\bin>set TermWareHome=C:\Program Files\JavaChecker

C:\Program Files\JavaChecker\bin>set JavaCheckerHome=C:\Program Files\JavaChecker

C:\Program Files\JavaChecker\bin>java -Dtermware.path="C:\Program Files\JavaChecker\systems" -cp "C:\Program Files\JavaChecker\jlib\TermWare.jar";"C:\Program Files\JavaChecker\jlib\JavaChecker.jar"  ua.kiev.gradsoft.JavaChecker.Main --prefs ../etc/prefs1.xml E:\padss --debug --output E:\padss\output.txt   
reading sources:
reading file E:\padss\Test.java
check package models.
exceptions:generic exception catch clause(file:E:\padss\Test.java,line:68)
exceptions: empty catch clause (file:E:\padss\Test.java,line:92)
exceptions: empty catch clause (file:E:\padss\Test.java,line:107)
style:non-final field name pattern violation(file:E:\padss\Test.java,line:178)
style:non-final field name pattern violation(file:E:\padss\Test.java,line:133)
style:final field name pattern violation(file:E:\padss\Test.java,line:77)
check for correspondance of overloading equals and hashCode

FindBugs

http://findbugs.sourceforge.net

FindBugs – статический анализатор кода. Говорят, когда-то давно он обнаружил ошибку в модели памяти java. Программа использует статический анализ, чтобы найти потенциальные ошибки сотни различных типов в java-коде. FindBugs работает с байткодом, а не с исходным кодом. Приложение распространяется и как отдельное десктопное приложение, и как плагин к Eclipse, Netbeans, IntelliJ IDEA и др. IDE.

У него множество проверок, разделённых на группы Bad practice, Correctness, Code vulnerability, Multithread…, Performance, Security, Dodgy code (изворотливый код) – подробности на http://findbugs.sourceforge.net/bugDescriptions.html.

Найденным проблемам можно ставить метки – типа not a bug, harmless, shud fix, must fix, needs further study.

Очень важное достоинство инструмента – он "жив"! Последняя версия 3.0.0 выпущена в июле 2014 года.

Распространяется в виде standalone-приложения. Можно... впрочем, может и умеет этот инструмент достаточно многое, и использовать его удобно и приятно.

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

Скриншот FindBugs на примере реального проекта

А БЫВАЮТ ЛИ НЕУДАЧИ?

SCA – это инструмент. Как любой инструмент, он может приносить пользу или... не приносить пользу. Попробуем разобраться, бывают ли неудачные попытки.

(основной материал в этом разделе скопирован из http://www.viva64.com/ru/a/0067/, уж больно там складно описано; так что рекомендую оригинал к прочтению)

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

Сценарий 1. Команда занимается тем, что выполняет перенос кода программного проекта для работы на 64-битных компьютерах. В процессе этого она сталкивается с некоторыми ранее неизвестными проблемами и ошибками, обусловленными именно сменой платформы. Команда узнаёт об анализаторе, который им поможет найти и исправить баги. Далее разработчики скачивают инструмент, смотрят на ознакомительную версию, если он их устраивает, то покупают лицензию, находят с помощью инструмента сколько-то ошибок в своем коде, исправляют их, и программа оказывается без ошибок. После чего разработчики считают задачу создания 64-битной версии программы законченной и далее отказываются от использования анализатора, так как считают, что он им не нужен больше.
Если команда применяет специализированный анализатор кода (как в описанном случае для поиска проблем 64-битного кода), то очень велик соблазн отказаться от инструмента после того, как проблемы вроде бы найдены и исправлены. И действительно, если выпущена 64-битная версия программного продукта, может показаться, что дальше использовать специальный инструмент смысла нет. Однако это не так. Если отказаться от использования такого анализатора, то со временем (через несколько месяцев) уже в новом коде будут возникать те ошибки, которые могли бы быть обнаружены с использованием анализатора кода. То есть, хотя 64-битная версия приложения существует и (когда-то) была отлажена, новый код может содержать ошибки, характерные для 64-битных приложений. Вывод по первому сценарию использования – отказ от специализированного анализатора кода после того, как основная работа с ним закончена, приводит к скорому появлению новых программных ошибок подобного типа.

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

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

Итак, основные проблемы, которые мешают использовать постоянно в работе инструменты статического анализа кода:

• Высокая цена инструментов анализа кода не позволяет применять эти инструменты в малых (прежде всего по бюджету) проектах. Надо просто понимать, что есть проекты, в которых статический анализ не подходит не из-за технологических, а из-за экономических причин.
• Инструмент для анализа кода дает много ложных срабатываний. Увы, любой анализатор кода дает ложные срабатывания, и зачастую дает их довольно много. Причина здесь кроется в философии подобных инструментов. Лучше выдать десять-сто ложных сообщений, чем пропустить одно настоящее. Надеяться на то, что какие-то анализаторы выдают мало ложных срабатываний, не стоит. Лучше выбрать инструмент, который каким-то образом поддерживает возможность работы с ложными срабатываниями.
• Плохая интеграция в среду разработки. Если инструмент для анализа кода не имеет гладкой "бесшовной" интеграции в среду разработки, то вряд ли им будут пользоваться регулярно.
• Отсутствие возможности автоматизированного запуска с помощью командной строки. Это не позволяет выполнять анализ кода всего проекта регулярно, например, во время ежедневных сборок.
• Отсутствие возможности интеграции с системой контроля версий. Хотя в рассмотренном ранее примере проверка нового кода при добавлении его в систему контроля версий послужила отказом от использования подобных инструментов, все-таки сама возможность такой интеграции является полезной.
• Слишком сложные, либо наоборот слишком простые настройки анализатора кода.

Решение проблем вообще существует?
Решением является отношения не вида "купить инструмент и использовать его", а вида "купить решение, внедрить его и только потом использовать". Нравится это или нет, но в большинстве случаев просто купить "программку-анализатор" и использовать ее с выгодой не удастся. Нужно "подтянуть" процесс разработки в компании и внедрить предлагаемый им инструмент в постоянный регулярный процесс командной разработки.

В КАЧЕСТВЕ ЗАКЛЮЧЕНИЯ

Сегодня на уроке мы узнали... :)

• Как бы ни были опытны разработчики, ошибки все равно появляются в коде.
• Static code analysis SCA – анализ исходного (чаще всего) кода программы (соответственно, без реального запуска).
• SCA позволяет сразу (т. е. до передачи на тестирование и тем паче в продакшн) выявить многие проблемы и ошибки кода, связанные как с невнимательностью, так и с более серьёзными просчётами. Это значительно удешевляет устранение ошибок (не только в денежном виде – требует меньше времени, усилий и пр.).
• SCA выполняется с помощью автоматических инструментов, разрабатываемых специально для этой цели и реализующих, в общем случае, общие принципы (лексический, синтаксический, статистический анализы).
• Средств SCA большое количество, как многоязычных, так и разработанных для конкретного языка.
• Что касается java, из попробованных мной средств наиболее интересными и инструментами оказались инспектор кода в intellij idea (вместе с дополнительными плагинами) и FindBugs (как отдельное средство и как плагин в idea).
• Обязательно нужно понимать, что SCA – не панацея от всех бед, а инструмент, который «может помочь» разработчикам, если они этого хотят.

И ЕЩЁ НЕМНОГО ССЫЛОК

http://habrahabr.ru/post/135234/ "Джон Кармак о статическом анализе кода"

https://ru.wikipedia.org/wiki/Статический_анализ_кода / http://en.wikipedia.org/wiki/Static_code_analysis  / https://ru.wikipedia.org/wiki/Динамический_анализ_кода куда же без wiki?!

http://www.viva64.com/ru сайт продукта PVS-Studio (статического анализатора С/С++), там масса полезной информации; а также их блог http://habrahabr.ru/company/pvs-studio/blog/

http://dou.ua/columns/statisticheskij-analiz-koda-v-java-chto-pod-kapotom/ "Статический анализ кода в java: что под капотом"

http://www.jetbrains.com/idea/documentation/static_code_analysis.html / http://www.jetbrains.com/idea/features/code_inspection.html немного от jetbrains

Впрочем, в сети намного больше всего интересного!

На этом - всё, заканчиваю.

Надеюсь, результаты моего труда будут кому-нибудь полезными :)