Статический анализ безопасности приложений

Зачем нужен статический анализ

За последние 30 лет программное обеспечение прошло путь от десятков тысяч строк кода до миллионов и десятков миллионов. Вместе с размером кодовых баз изменилась и природа ошибок в них.

Кодовые базы растут — плотность ошибок тоже

Промышленные исследования показывают: чем больше проект, тем выше типичная плотность дефектов на тысячу строк кода. Это нелинейная зависимость — после некоторого порога ошибки начинают «множиться» быстрее, чем растёт сам код.

Объём контролировать вручную становится физически невозможно. К тому же появляются разные классы ошибок — те, что ловят тесты, и те, что не ловят; критичные для безопасности и косметические; явные и скрытые.

Стоимость исправления уязвимости растёт экспоненциально

По данным NIST (National Institute of Standards and Technology), стоимость исправления одной и той же ошибки на разных стадиях жизненного цикла программного обеспечения отличается в десятки и сотни раз.

Способы поиска ошибок

Статический анализ — лишь один из методов поиска ошибок. Он дополняет, а не заменяет другие практики обеспечения качества.

Что такое статический анализ

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

Определение по ГОСТ Р 71207-2024

Ключевые свойства

Найди ошибку: шесть реальных кейсов

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

public void SetCredentials(string userName, string password, string domain)
{
    if (string.IsNullOrEmpty(userName))
    {
        throw new ArgumentException("Empty user name.", "userName");
    }

    if (string.IsNullOrEmpty("password"))
    {
        throw new ArgumentException("Empty password.", "password");
    }

    CredentialsUserName     = userName;
    CredentialsUserPassword = password;
    CredentialsDomain       = domain;
}

public bool Equals(BlobSasBuilder other) =>
    BlobName          == other.BlobName &&
    CacheControl      == other.CacheControl &&
    BlobContainerName == other.BlobContainerName &&
    ContentDisposition== other.ContentDisposition &&
    ContentEncoding   == other.ContentEncoding &&
    ContentLanguage   == other.ContentEncoding &&
    ContentType       == other.ContentType &&
    ExpiryTime        == other.ExpiryTime &&
    Identifier        == other.Identifier &&
    IPRange           == other.IPRange &&
    Permissions       == other.Permissions &&
    Protocol          == other.Protocol &&
    StartTime         == other.StartTime &&
    Version           == other.Version;

if (request.PaymentTolerance < 0 && request.PaymentTolerance > 100)
{
    ModelState.AddModelError(
        nameof(request.PaymentTolerance),
        "PaymentTolerance can only be between 0 and 100 percent"
    );
}

protected static bool IsFinite(float f)
{
    if (   f == Mathf.Infinity
        || f == Mathf.NegativeInfinity
        || f == float.NaN)
    {
        return false;
    }
    return true;
}

var firstUrl  = new Uri(urlHook, UriKind.Absolute);
var secondUrl = new Uri(url,     UriKind.Absolute);

return firstUrl.Scheme == secondUrl.Scheme
    && firstUrl.Port   == secondUrl.Port
    && firstUrl.Host   == firstUrl.Host;

ParagraphFormat paragraphFormat;

public ParagraphFormat ParagraphFormat
{
    get { return paragraphFormat; }
    set { ParagraphFormat = value; }
}

Safety и Security: две разные «безопасности»

В русском языке оба слова переводятся как «безопасность», но в инженерном контексте это разные дисциплины — с разной целью и разными стандартами.

Что такое SAST

SAST — Static Application Security Testing. Это статический анализ, специально нацеленный на поиск потенциальных уязвимостей.

Уязвимость как особый класс ошибок

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

Свойства SAST

SAST наследует все полезные свойства статического анализа:

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

CWE и CVE: каталоги уязвимостей

Чтобы говорить об уязвимостях на одном языке, индустрия выработала два стандартных каталога: один для типов слабостей, другой — для конкретных найденных уязвимостей.

Уязвимостей становится больше

Число регистрируемых CVE растёт каждый год — и темп ускоряется. По данным cvedetails.com и CVE.org, за последнее десятилетие количество ежегодных публикаций уязвимостей увеличилось более чем в семь раз: с ~6,5 тысяч в 2015 году до ~48 тысяч в 2025-м.

Пример SAST-предупреждения: SQL-инъекция

Рассмотрим, как SAST находит классическую уязвимость — SQL-инъекцию. Ключевая идея SAST — отслеживание помеченных данных (taint analysis): данные от пользователя помечаются как «опасные» и анализатор следит за их распространением по программе.

Уязвимый код

using (SqlConnection connection = new SqlConnection(....))
{
    ....
    String userName = Request.Form["userName"];   // SOURCE — данные от пользователя

    using (var command = new SqlCommand()
    {
        Connection  = connection,
        CommandText = "SELECT * FROM Users WHERE UserName = '"
                    + userName                                        // TAINT — конкатенация в SQL
                    + "'",
        CommandType = System.Data.CommandType.Text
    })
    {
        var reader = command.ExecuteReader();                         // SINK — выполнение запроса
    }
}

Что происходит

1. Источник (source) — Request.Form["userName"]: данные пришли от пользователя, доверять им нельзя.
2. Распространение (taint flow) — переменная userName подставляется напрямую в строку SQL-запроса через конкатенацию +.
3. Сток (sink) — итоговая строка передаётся в SqlCommand.CommandText и исполняется как SQL.

Атакующий может ввести в форму строку вида ' OR '1'='1' -- и превратить её в произвольный SQL-запрос, обходя авторизацию или вытаскивая данные из других таблиц.

Этот же подход (taint-анализ) лежит в основе поиска большинства injection-уязвимостей: Command injection, Path traversal, XSS, LDAP injection и т. д. Везде SAST ищет связку source → flow → sink с проверкой санитизации на пути.

Регуляторный контекст

В России разработка безопасного ПО (РБПО) и применение статического анализа регулируются национальными стандартами серии ГОСТ Р. Их соблюдение — обязательное условие для поставщиков средств защиты информации и значительной части государственных и корпоративных заказчиков.

Эволюция стандартов РБПО

За девять лет — от первой редакции базового стандарта до обновлённой версии 2024 года, дополненной специализированным стандартом по статическому анализу.

Кто разработал

ГОСТ Р 71207-2024 разработан совместно:

• ФСТЭК России — Федеральная служба по техническому и экспортному контролю.
• ИСП РАН — Институт системного программирования им. В. П. Иванникова Российской академии наук.

Стандарт внесён ТК 362 «Защита информации», утверждён приказом Росстандарта от 18 января 2024 года № 25-ст и введён в действие с 1 апреля 2024 года.

Кому адресован стандарт

• Разработчикам статических анализаторов — задаёт обязательный набор реализуемых методов анализа и качественные показатели.
• Разработчикам средств защиты информации и средств обеспечения безопасности ИТ — задаёт требования к процессу применения статанализа.
• Разработчикам ПО общего назначения, поставляющим продукты под требования РБПО.

Внедрение статического анализа по ГОСТ Р 71207

Стандарт предписывает чёткую схему внедрения: три последовательных этапа и набор контрольных сроков для регулярной работы.

Три этапа внедрения

Контрольные сроки регулярного анализа

Стандарт устанавливает чёткие временные рамки, которые превращают анализ из эпизодического запуска в встроенную часть процесса разработки:

Критические ошибки по ГОСТ Р 71207

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

Требования к инструментам и специалистам

Стандарт предъявляет конкретные численные и функциональные требования — как к самому статическому анализатору, так и к людям, которые с ним работают.

Чек-лист для инструмента (п. 8)

• Качество анализа: доля ложноположительных срабатываний (FP) ≤ 50%, доля ложноотрицательных (FN, пропусков) ≤ 50% — на квалификационном наборе тестов.
• Скорость: полный анализ ПО с заимствованными компонентами на средствах разработчика — не более 2 суток.
• Поддержка заимствованных компонентов: анализ должен охватывать ПО целиком, включая сторонние библиотеки.
• Состав предупреждения: описание ошибки, тип, точное место в исходном коде, рекомендация по исправлению.
• Связь с CWE: для каждого типа ошибки в документации указано соответствие одному или нескольким идентификаторам MITRE CWE.
• Открытый формат вывода: результаты анализа доступны в машиночитаемом формате — например, SARIF (Static Analysis Results Interchange Format).
• Автоматизация: доступен консольный или программный интерфейс для CI/CD-интеграции.
• Хранение и сравнение результатов: сохранение запусков с уникальными идентификаторами предупреждений и сравнение между запусками.
• Поддержка разметки: возможность пометить предупреждение как «истинное», «ложное», «не требует исправления» с автоматизацией повторных решений.
• Документация: описание всех типов ошибок с причинами, примерами кода и способами исправления.

Две роли специалистов (п. 9)

Интеграция в процесс разработки

Современный SAST-инструмент перестаёт быть «отдельной программой, в которую раз в месяц приходят». Он встраивается во все ключевые точки разработки — от IDE до облачного CI.

Ниже — карта экосистемы интеграций на примере PVS-Studio. Аналогичный список характерен для большинства зрелых SAST-решений.