Статический анализ кода — Википедия

Стати́ческий ана́лиз ко́да (англ. static code analysis) — анализ исходного кода программного обеспечения, производимый без реального выполнения исследуемых программ (в отличие от динамического анализа). В большинстве случаев анализ производится над исходным кодом, хотя, иногда анализу подвергается объектный код, например P-код или код на MSIL. Термин обычно применяют к анализу, производимому специальным программным обеспечением (ПО), тогда как ручной анализ называют «program understanding», «program comprehension» (пониманием или постижением программы).

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

В некоторых источниках программные метрики и обратное проектирование относятся к формам статического анализа. Получение метрик (англ. software quality objectives) и статический анализ часто совмещаются, особенно при создании встраиваемых систем.^[1]

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

Примером простейшего синтаксического анализа являются генерируемые большинством компиляторов (например, GNU C Compiler) «предупреждения» (англ. warnings) — диагностические сообщения о потенциальной ошибочности синтаксически правильного кода. Например, для следующего кода на C может быть получено сообщение о неинициализированной переменной:

int x; int y = x + 2;  // Переменная x не инициализирована! 

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

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

Object *p = getObject(); int pNum = reinterpret_cast<int>(p);    // на x86-32 верно, на x64 часть указателя будет потеряна; следует использовать intptr_t 

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

dest.x = src.x + dx; dest.y = src.y + dx;  // Опечатка: вместо dy указан dx 

• Ошибки форматных строк — в функциях форматированного ввода и вывода (например, printf) форматная строка может не соответствовать реальному количеству и типам параметров.

std::wstring s; printf("s is %s and d is %d", s); 

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

void doSomething(bool flag)   // flag всегда равен true {    if (flag)        // какая-то логика    else        // код есть, но не задействован } ... doSomething(true); ... 

• Утечки памяти и других ресурсов. В целом статические анализаторы проигрывают в сфере поиска утечек динамическим анализаторам кода^{[2][неавторитетный источник]}.

Traverser *t = new Traverser(Name); if (!t->Valid()) {   return FALSE; // return до освобождения памяти.   delete t; } 

• Вызов функций, не имеющих побочного эффекта как процедур (без сохранения возвращаемого значения):

std::string s; ... s.empty();     // код ничего не делает; возможно, опечатка и должно быть s.clear()? 

• Прочие ошибки.

В последнее время статический анализ всё больше используется в верификации свойств ПО, используемого в компьютерных системах высокой надёжности, особенно критичных для жизни (safety-critical^[англ.]). Также применяется для поиска кода, потенциально содержащего уязвимости (иногда это применение называется Static Application Security Testing, SAST).^[3]

Статический анализ постоянно применяется для критического ПО в следующих областях:

1. ПО для медицинских устройств.^[4]
2. ПО для атомных станций и систем защиты реактора (Reactor Protection Systems)^[5]
3. ПО для авиации (в комбинации с динамическим анализом)^[6]
4. ПО на автомобильном или железнодорожном транспорте^[7]

По данным VDC на 2012 год, примерно 28 % разработчиков встраиваемого ПО применяют средства статического анализа, а 39 % собираются начать их использование в течение 2 лет.^[8]

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

В разделе не хватает ссылок на источники (см. рекомендации по поиску). Информация должна быть проверяема, иначе она может быть удалена. Вы можете отредактировать статью, добавив ссылки на авторитетные источники в виде сносок. (24 августа 2018)

Инструменты по анализируемым языкам, некоторый из которых выделяет CISO CLUB^[9]:

C/C++:

• BLAST
• Clang Static Analyzer (встроен в Clang)^[10]
• Coverity
• PC-Lint
• lint и lock_lint, входящие в состав Sun Studio
• Cppcheck (Cppcheck on sf)
• Parasoft C/C++Test^[англ.]
• Solar appScreener
• SourceAnalyzer (также Fortran и x86 asm)
• PVS-Studio
• LDRA Testbed^[англ.]
• Polyspace^[англ.]
• QA-C^[англ.]
• Cantata++^[англ.]
• Visual Code Grepper

C#:

• CodeCrawler
• Visual Code Grepper
• Code Warrior
• PVS-Studio

Java:

• fbinfer
• FindBugs (FindBugs on sf)
• PVS-Studio
• Parasoft JTest^[англ.]
• RIPS^[англ.]
• Solar appScreener
• YASCA
• Code Warrior

JavaScript:

• JSLint
• Code Warrior

.NET:

• .NET Compiler Platform (Roslyn) — фреймворк компилятора для C# и VB.NET, предоставляющий интерфейс для анализатора.
• FxCop
• Microsoft FxCop
• NDepend
• PVS-Studio
• ReSharper
• StyleCop
• YASCA

PHP:

• Graudit
• RIPS^[англ.]
• Solar appScreener
• YASCA
• Visual Code Grepper
• Code Warrior

Python:^[11][12]

• Flake8
• Graudit
• Pychecker^[англ.]
• Pylint
• McCabe
• Pyflakes
• Pycodestyle
• Solar appScreener
• YASCA

Ruby:

• Brakeman
• Code Warrior

Другие:^{[источник не указан 2308 дней]}

• T-SQL Analyzer — инструмент, который может просматривать программные модули в базах данных под управлением Microsoft SQL Server 2005 или 2008 и обнаруживать потенциальные проблемы, связанные с низким качеством кода.
• SonarQube — платформа анализа и управления качеством кода с поддержкой различных языков программирования через систему плагинов.

• Формальная верификация
• Тестирование программного обеспечения
• Безопасное программирование
• Список средств статического анализа кода^[англ.]
• MISRA C

• О безошибочных программах // «Открытые системы», № 07, 2004
• Первые шаги к решению проблемы верификации программ // «Открытые системы», № 08, 2006
• Статический анализ безопасности кода // Программная инженерия и информационная безопасность. 2013 № 1, стр 50 (npo-echelon.ru)
• http://www.drdobbs.com/testing/deploying-static-analysis/240003801
• Коллекция ошибок, обнаруженных в Open Source проектах с помощью статического анализа кода // PVS-Studio (viva64.com)