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

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

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

Принципы статического анализа

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

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

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

Типы ошибок, обнаруживаемых статическими анализаторами

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

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", s);

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

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

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

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

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

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

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

Применение

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

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

1. ПО для медицинских устройств.
2. ПО для атомных станций и систем защиты реактора ( )
3. ПО для авиации (в комбинации с динамическим анализом)
4. ПО на автомобильном или железнодорожном транспорте

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

Формальные методы

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

Инструменты статического анализа

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

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

C/C++:

• BLAST
• (встроен в Clang )
• Coverity
• lint и lock_lint, входящие в состав Sun Studio
• Cppcheck ( )
• (англ.) (
• Solar appScreener
• (также Fortran и x86 asm)
• PVS-Studio
• (англ.) (
• (англ.) (
• (англ.) (
• (англ.) (

C#:

• Code Warrior
• PVS-Studio

Java:

• FindBugs ( )
• PVS-Studio
• (англ.) (
• (англ.) (
• Solar appScreener
• Code Warrior

JavaScript:

• JsHint
• Code Warrior

.NET:

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

PHP:

• (англ.) (
• Solar appScreener
• Code Warrior

Python:

• (англ.) (
• Pylint
• Solar appScreener

Ruby:

• Brakeman
• Code Warrior

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

• T-SQL Analyzer — инструмент, который может просматривать программные модули в базах данных под управлением Microsoft SQL Server 2005 или 2008 и обнаруживать потенциальные проблемы, связанные с низким качеством кода.
• от ЗАО "НПО "Эшелон" (Поиск НДВ, выявление опасных шаблонов по (англ.) ( ^{[ неавторитетный источник ]} )
• SonarQube — платформа анализа и управления качеством кода с поддержкой различных языков программирования через систему плагинов.
• — коммерческий статический анализатор кода от "НПО "ЭШЕЛОН", предназначенный для автоматизированного поиска дефектов в исходном коде приложений, разработанных на С#, C/C++, Java, PHP.
• — инструмент статического анализа, разработанный в ИСП РАН . Поддерживает языки программирования C/C++, Java, C#. ^{[ неавторитетный источник ]}

См. также

• Формальная верификация
• Тестирование программного обеспечения
• (англ.) (
• MISRA C

Примечания

Ссылки

• // «Открытые системы», № 07, 2004
• // «Открытые системы», № 08, 2006
• // Программная инженерия и информационная безопасность. 2013 № 1, стр 50 (npo-echelon.ru)
• // PVS-Studio (viva64.com)