СРАВНИТЕЛЬНЫЙ АНАЛИЗ МЕТОДОВ SAST И DAST ПРИ ВЫЯВЛЕНИИ УЯЗВИМОСТЕЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Введение

Сложность современного программного обеспечения диктует необходимость использования средств его тестирования на различные ошибки и уязвимости. ГОСТ Р 56939—2024 предусматривает статический и динамический анализ, композиционный анализ и фаззинг-тестирование [1], а ГОСТ Р 71207—2024 устанавливает требования к статическому анализу [2]. Применимость этих мер определяется требованиями конкретного проекта.

Цель исследования — сопоставить SAST и DAST на единой метрической основе и установить границы выводов об их совместном применении. В рамках исследования была уточнена терминология, пересчитаны показатели по официальным матрицам ошибок OWASP Benchmark for Java v1.2 и построена сценарная модель объединения.

1. Общее описание методов анализа ПО

SAST анализирует программный код без фактического выполнения. Исследуется структура программы, связи между функциями и переменными, а также пути распространения данных, выявляя инъекции, ошибки работы с памятью и другие дефекты на этапе разработки [3].

DAST проверяет работающее приложение, направляя запросы и анализируя ответы. Исходный код обычно не требуется, но охват зависит от доступных функций, пользовательских ролей и состояний приложения, а точное место ошибки в коде не всегда обнаружимо. Сравнение методов приведено в таблице 1.

Таблица 1.

Сопоставление SAST и DAST

2. Исходные данные и методика расчёта

OWASP Benchmark for Java v1.2 содержит 2740 исполняемых сервлетов Java из 11 категорий CWE: 1415 положительных и 1325 отрицательных случаев. Версия 1.2 выпущена в 2016 г. и существенно не менялась [4]. Использованы отчёты PMD, FindBugs, SonarQube Java Plugin, FindBugs с модулем FindSecBugs и OWASP ZAP [5–9].

Пусть анализатор проверяет размеченный набор тестовых случаев, каждый из которых содержит либо не содержит уязвимость определённого типа. Если для каждого случая установлено, обнаружена ли эта уязвимость, результаты можно представить, как бинарную классификацию и описать матрицей ошибок (таблица 2), включающей истинно положительные (TP), ложноположительные (FP), ложноотрицательные (FN) и истинно отрицательные (TN) результаты.

Таблица 2.

Матрица ошибок задачи обнаружения уязвимостей

На основе матрицы ошибок вычисляются точность Precision, полнота Recall (она же доля верных обнаружений TPR) и доля ложных срабатываний FPR:

                                                                                                  (1)

                                                                                           (2)

                                                                                                   (3)

Далее, вычисляется F-мера, учитывающая одновременно долю найденных уязвимостей и правильность выданных предупреждений:

                                                                                           (4)

В методике OWASP Benchmark интегральной оценкой выступает индекс Юдена — нормированное расстояние от точки инструмента до линии случайного угадывания в пространстве (FPR, TPR):

                                                                              (5)

где Se и Sp — чувствительность и специфичность. Метрика Accuracy не используется как основной показатель, поскольку она зависит от соотношения положительных и отрицательных случаев и может вводить в заблуждение при несбалансированных данных.

3. Результаты тестирования

Таблица 3.

Матрицы ошибок и микроусреднённые показатели, рассчитанные по данным OWASP Benchmark for Java v1.2

P — доля подтверждённых случаев, R­­­ — полнота, FPR — доля ошибочно помеченных отрицательных примеров. Расчёт по суммарным TP, FP, FN и TN является микроусреднением. Официальные итоговые показатели OWASP усреднены по 11 категориям.

Для PMD P не определена, поскольку положительных результатов нет; R и J равны нулю. У FindBugs J составил 0,71 %.

FindSecBugs показал полноту 96,82 % при FPR 53,06 %, SonarQube — 42,90 % при 10,64 %. У единственного DAST-инструмента ZAP P равна 99,03 %, FPR — 0,23 %, R — 21,63 %. Это различный баланс ошибок конкретных запусков, а не доказательство превосходства класса методов.

4. Совместное применение методов

Таблица 3 не содержит пересечения найденных уязвимостей, поэтому полноту SAST и DAST нельзя просто просуммировать. Для методов A и B полнота объединения ограничена соотношением:

max(R(A), R(B)) ≤ R(A ∪ B) ≤ min(1, R(A) + R(B))                                                                      (6)

Для SonarQube и ZAP интервал равен 42,90–64,52 %. При сценарном допущении независимости R(A ∪ B) = 1 − (1 − R(A))(1 − R(B)) = 55,25 %, а по неравенству объединения FPR не превышает 10,87 %.

SAST целесообразно запускать после изменений кода в непрерывной интеграции, DAST — после развёртывания сборки в изолированной тестовой среде, связывая результаты по версии, типу и месту проявления. Доступность исходного кода, открытого ПО упрощает независимый SAST, но не подтверждает защищённость; DAST проверяет конкретную сборку и конфигурацию.

Также, стоит отметить и ограничения данного исследования. OWASP Benchmark v1.2 — исторический синтетический набор более простых, чем реальный код тестов на языке Java из 11 категорий CWE. Менее 3000 тестов оставлено для облегчения динамического сканирования [4].

В исследовании шести анализаторов C на 27 открытых проектах объёмом 1,15 млн строк и 192 известных уязвимостях пропущено 47–80 % уязвимостей [10]. Выборка не сопоставима с OWASP по языку и метрикам, но показывает, что полнота на синтетических тестах не гарантирует результат в реальных проектах.

Заключение

1. SAST исследует программу без её выполнения ПО, DAST — поведение работающей сборки, однако оба метода допускают ошибки.
2. В OWASP Benchmark v1.2 полнота FindSecBugs равна 96,82 % при FPR 53,06 %, а P для ZAP — 99,03 % при полноте 21,63 %.
3. Результаты PMD и FindBugs относятся к историческим версиям и не оценивают современные анализаторы или весь класс SAST.
4. Без пересечения результатов эффект объединения задаётся лишь интервалом или сценарием; на практике SAST включают в жизненный цикл разработки ПО, а DAST проводят на развёрнутой тестовой сборке.