SAST¶

SAST (Static Application Security Testing, статическое тестирование безопасности приложений) — это методология анализа исходного кода, байт-кода или исполняемых файлов программного обеспечения с целью выявления уязвимостей и дефектов безопасности без фактического выполнения программы. SAST относится к категории «белого ящика» (white-box testing), поскольку аналитик или инструмент имеет полный доступ к внутренней структуре приложения. Основное отличие SAST от динамического анализа (DAST) заключается в том, что проверка проводится на этапе разработки, до компиляции и запуска, что позволяет обнаруживать проблемы на ранних стадиях жизненного цикла программного обеспечения.

¶История

Первые упоминания о статическом анализе кода относятся к 1970-м годам, когда исследователи из Bell Labs и других организаций начали разрабатывать инструменты для автоматизированной проверки программ на наличие ошибок. Однако специализированные решения для безопасности появились значительно позже. В 1990-х годах с ростом числа кибератак и ужесточением требований к безопасности программного обеспечения (например, стандарта ISO 15408) начали формироваться коммерческие SAST-продукты. Первыми заметными инструментами стали Fortify (основан в 2003 году) и Checkmarx (основан в 2006 году). В 2010-х годах SAST стал неотъемлемой частью практик DevSecOps, где безопасность интегрируется непосредственно в процессы непрерывной интеграции и доставки (CI/CD). В России развитие SAST-инструментов активизировалось после 2014 года в связи с политикой импортозамещения и требованиями регуляторов (ФСТЭК России, Минцифры) к сертификации программного обеспечения.

¶Принцип работы

SAST-инструменты анализируют код без его выполнения. Процесс включает несколько этапов:

Парсинг исходного кода: инструмент разбирает код на синтаксические единицы (токены), строя абстрактное синтаксическое дерево (AST) или граф потока управления (CFG).
Построение модели данных: создаётся граф потока данных (DFG), который отслеживает, как данные перемещаются между переменными, функциями и модулями.
Применение правил и сигнатур: инструмент сравнивает код с базой известных уязвимостей (например, из списка OWASP Top 10) и шаблонов небезопасного кодирования.
Генерация отчёта: выявленные уязвимости классифицируются по типу (например, SQL-инъекция, XSS, переполнение буфера), критичности и местоположению в коде.

¶Классификация

SAST-инструменты можно классифицировать по нескольким признакам:

¶По типу анализируемого кода

Инструменты для исходного кода: работают с языками высокого уровня (Java, C#, Python, JavaScript, C/C++). Примеры: SonarQube (с модулем безопасности), PVS-Studio.
Инструменты для байт-кода: анализируют скомпилированный промежуточный код (например, Java-байт-код или .NET IL). Пример: FindBugs (ныне SpotBugs).
Инструменты для бинарных файлов: проверяют исполняемые файлы без доступа к исходникам. Используются редко из-за сложности декомпиляции. Пример: BinSkim.

¶По методу анализа

Паттерн-матчинг (pattern-based): поиск по заранее заданным шаблонам небезопасного кода. Прост, но даёт много ложных срабатываний.
Анализ потока данных (data-flow analysis): отслеживание путей передачи данных от источников (например, пользовательский ввод) к опасным функциям (например, exec()). Более точен, но требует больше вычислительных ресурсов.
Символьное выполнение (symbolic execution): моделирование всех возможных путей выполнения программы с использованием символьных переменных. Позволяет находить сложные уязвимости, но крайне ресурсоёмко.

¶По интеграции в процесс разработки

Автономные (standalone): запускаются вручную или по расписанию. Пример: Cppcheck.
Интегрированные в IDE: работают в среде разработки (например, плагины для Visual Studio или IntelliJ IDEA).
Встроенные в CI/CD: запускаются автоматически при каждом коммите или сборке. Пример: GitLab SAST.

¶Применение

SAST используется в различных отраслях и сценариях:

Разработка коммерческого ПО: для соблюдения стандартов безопасности (например, PCI DSS, HIPAA, ГОСТ Р 56939-2016 в России).
Разработка критической инфраструктуры: в банковском секторе, энергетике, оборонной промышленности, где уязвимости могут привести к серьёзным последствиям.
Open-source проекты: многие крупные проекты (например, ядро Linux, Apache, Mozilla) используют SAST для проверки вкладов сообщества.
Аудит кода: сторонние организации проводят статический анализ для оценки безопасности приложений перед выпуском.

¶Примеры инструментов

¶Коммерческие

Checkmarx (Израиль): поддерживает более 25 языков, интегрируется с CI/CD.
Fortify (Micro Focus, США): один из старейших инструментов, включает обширную базу правил.
Veracode (США): предоставляет облачный сервис SAST.
Solar appScreener (Россия, разработчик — «Ростелеком-Солар»): сертифицирован ФСТЭК России, используется для проверки отечественного ПО.
AppChecker (Россия, разработчик — «Астра»): встроен в экосистему Astra Linux.

¶Открытые (open-source)

SonarQube (с модулем SonarSecurity): популярный инструмент для анализа качества и безопасности кода.
SpotBugs (преемник FindBugs): для Java-байт-кода.
Cppcheck: для C/C++.
Bandit: для Python.
Brakeman: для Ruby on Rails.

¶Преимущества и недостатки

¶Преимущества

Раннее обнаружение: уязвимости находятся на этапе написания кода, что снижает стоимость их исправления (по данным исследований, исправление на этапе эксплуатации стоит в 10–30 раз дороже, чем на этапе разработки).
Полнота покрытия: анализируется весь код, включая недостижимые или редко выполняемые ветви.
Автоматизация: не требует ручного тестирования, может быть встроена в конвейер сборки.
Соответствие стандартам: помогает выполнить требования регуляторов.

¶Недостатки

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

¶Критика и ограничения

Основная критика SAST связана с высоким уровнем ложных срабатываний, особенно в сложных проектах с большим количеством библиотек. По данным отчётов OWASP, точность SAST-инструментов варьируется от 30% до 80% в зависимости от типа уязвимости и языка программирования. Кроме того, SAST не способен выявить уязвимости, возникающие только во время выполнения (например, race conditions или проблемы с памятью, зависящие от входных данных). Для повышения эффективности рекомендуется комбинировать SAST с DAST (динамическим анализом) и IAST (интерактивным анализом).

¶Интересные факты

В 2023 году компания GitLab сообщила, что SAST-сканирование в её платформе выявляет в среднем 2,5 уязвимости на 1000 строк кода в проектах на Java и 1,2 — на Python.
В России с 2021 года действует приказ Минцифры № 486, который обязывает разработчиков государственных информационных систем использовать сертифицированные средства статического анализа, включая SAST.
Некоторые SAST-инструменты, например, CodeQL (разработка GitHub, принадлежит Microsoft), используют базу знаний уязвимостей, пополняемую сообществом.

¶Источники

OWASP Foundation. «Static Application Security Testing (SAST)». OWASP Testing Guide.
NIST. «Static Analysis Tools for Security». National Institute of Standards and Technology.
ФСТЭК России. «Методика оценки безопасности программного обеспечения». 2022.
Checkmarx. «The State of Software Security Report». 2024.
SonarSource. «SonarQube Documentation: Security Analysis».

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →