Статичний аналіз коду англ static code analysis аналіз програмного забезпечення який здійснюють на відміну від динамічно

Статичний аналіз коду (англ. static code analysis) — аналіз програмного забезпечення, який здійснюють (на відміну від динамічного аналізу) без реального виконання програм, що досліджуються. Зазвичай аналізу піддають початковий код, хоча іноді аналізу піддається об'єктний код, наприклад, P-код або код CIL. Термін зазвичай застосовують до аналізу, який проводить спеціальне програмне забезпечення (ПЗ), тоді як ручний аналіз називають «program understanding», «program comprehension» (розумінням або осягненням програми).

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

Деякі люди вважають програмні метрики і зворотне проектування формами статичного аналізу. Отримання метрик (англ. software quality objectives) та статичний аналіз часто поєднуються, особливо при створенні вбудованих систем.

Статичний аналіз дедалі більше використовується у верифікації властивостей ПЗ, що використовується в комп'ютерних системах високої надійності, особливо критичних для життя (^[en]). Також застосовується для пошуку коду, що потенційно містить вразливості (іноді це застосування називається Static Application Security Testing, SAST).

Статичний аналіз ПЗ постійно застосовується в наступних областях:

Для медичних пристроїв.
Для ядерних станцій і ^[en].
Для авіації (в комбінації з динамічним аналізом)

За даними VDC на 2012 рік, приблизно 28 % розробників вбудованого ПЗ застосовували засоби статичного аналізу, а 39 % збирались почати їх використання протягом 2 років.

Принципи статичного аналізу

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

int x; int y = x+2; // Змінну x не ініціалізовано!

Це найпростіший статичний аналіз. У компілятора є багато інших важливих характеристик — в першу чергу швидкість роботи і якість машинного коду, тому компілятори перевіряють код лише на очевидні помилки. Статичні аналізатори призначені для детальнішого дослідження.

Типи помилок, що виявляються статичними аналізаторами

Невизначена поведінка — неініціалізовані змінні, звернення до NULL-вказівників. Про найпростіші випадки сигналізують також компілятори.
Порушення алгоритму користування бібліотекою. Наприклад, для кожного fopen потрібен fclose. І якщо файлова змінна втрачається раніше, ніж файл закривається, аналізатор може повідомити про помилку.
Типові сценарії, що призводять до недокументованої поведінки. Стандартна бібліотека мови Сі відома великою кількістю невдалих технічних рішень. Деякі функції, наприклад, gets, в принципі небезпечні. sprintf і strcpy безпечні лише при певних умовах.
Переповнення буфера — коли комп'ютерна програма записує дані за межами виділеного в пам'яті буферу.

void doSomething(const char* x) {  char s[40];  sprintf(s, "[%s]", x); // sprintf в локальний буфер, можливе переповнення  .... }

Типові сценарії, які заважають кросплатформності.

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!

Помилки форматних рядків — у функціях на зразок printf можуть бути помилки з невідповідністю форматного рядка реальним типам параметрів.

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

Незмінний параметр, що передається у функцію — ознака зміни вимог до програми. Коли-то параметр був задіяний, але зараз він вже не потрібен. В такому випадку програміст може взагалі позбутися цього параметра — і пов'язаної з ним логіки.

void doSomething(int n, bool flag) // flag завжди дорівнює true {  if (flag)  {  // якась логіка  } else  {  // код є, але не задіяний  } } doSomething(n, true); ... doSomething(10, true); ... doSomething(x.size(), true);

Інші помилки — багато функцій бібліотек не мають побічного ефекту, і виклик їх як процедур не має сенсу.

std::string s; ... s.empty(); // код нічого не робить; ймовірно, ви хотіли s.clear()?

Інструменти статичного аналізу

C/C++:

BLAST
Clang Static Analizer (вбудований в Clang)
Coverity
PC-Lint
lint і lock_lint, що входить до складу Sun Studio
Cppcheck (Cppcheck on sf [ 18 січня 2016 у Wayback Machine.])
^[en]
SourceAnalyzer (також Fortran і x86 asm)
^[en]
^[en]
^[en]
^[en]
^[en]

Java:

FindBugs (FindBugs on sf [Архівовано 23 червня 2015 у Archive.is])
^[en]
fbinfer

.NET:

.NET Compiler Platform (Roslyn) — фреймворк компілятора для C# і VB.NET, що надає інтерфейс для аналізатора.
FxCop
NDepend
^[en]
ReSharper
StyleCop

Python:

^[en]
Pyflakes [ 19 квітня 2016 у Wayback Machine.]

Інші:

T-SQL Analyzer [ 8 серпня 2016 у Wayback Machine.] — інструмент, який може переглядати програмні модулі в базах даних під управлінням Microsoft SQL Server 2005 або 2008 і виявляти потенційні проблеми, пов'язані з низькою якістю коду.
АК-ВС (виявлення небезпечних шаблонів за CWE)
SonarQube — платформа аналізу та управління якістю коду з підтримкою різних мов програмування через систему плагінів.

Примітки

Software Quality Objectives for Source Code.
Improving Software Security with Precise Static and Runtime Analysis, Benjamin Livshits, section 7.3 "Static Techniques for Security, " Stanford doctoral thesis, 2006. http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/thesis.pdf [ 5 червня 2011 у Wayback Machine.]
FDA (8 вересня 2010). . Food and Drug Administration. Архів оригіналу за 1 вересня 2010. Процитовано 9 вересня 2010.
Computer based safety systems — technical guidance for assessing software aspects of digital computer based protection systems, http://www.hse.gov.uk/nuclear/operational/tech_asst_guides/tast046.pdf [ 9 жовтня 2012 у Wayback Machine.]
(PDF). Архів оригіналу (PDF) за 6 жовтня 2013. Процитовано 21 червня 2016.
VDC Research (1 лютого 2012). . VDC Research. Архів оригіналу за 7 квітня 2012. Процитовано 10 квітня 2012.
Распознаётся PVS-Studio [1] [ 8 листопада 2011 у Wayback Machine.]
. clang-analyzer.llvm.org. Архів оригіналу за 8 жовтня 2011. Процитовано 14 травня 2016.
. Архів оригіналу за 17 березня 2018. Процитовано 17 березня 2018.
. Архів оригіналу за 27 травня 2016. Процитовано 21 червня 2016.

Див. також

[1] Software Quality Objectives for Source Code.

[2] Improving Software Security with Precise Static and Runtime Analysis, Benjamin Livshits, section 7.3 "Static Techniques for Security, " Stanford doctoral thesis, 2006. http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/thesis.pdf [ 5 червня 2011 у Wayback Machine.]

[3] FDA (8 вересня 2010). . Food and Drug Administration. Архів оригіналу за 1 вересня 2010. Процитовано 9 вересня 2010.

[4] Computer based safety systems — technical guidance for assessing software aspects of digital computer based protection systems, http://www.hse.gov.uk/nuclear/operational/tech_asst_guides/tast046.pdf [ 9 жовтня 2012 у Wayback Machine.]

[5] (PDF). Архів оригіналу (PDF) за 6 жовтня 2013. Процитовано 21 червня 2016.

[6] VDC Research (1 лютого 2012). . VDC Research. Архів оригіналу за 7 квітня 2012. Процитовано 10 квітня 2012.

[pvs-7] Распознаётся PVS-Studio [1] [ 8 листопада 2011 у Wayback Machine.]

[8] . clang-analyzer.llvm.org. Архів оригіналу за 8 жовтня 2011. Процитовано 14 травня 2016.

[9] . Архів оригіналу за 17 березня 2018. Процитовано 17 березня 2018.

[10] . Архів оригіналу за 27 травня 2016. Процитовано 21 червня 2016.