SAST (Static Application Security Testing).

SAST разбирает код в промежуточные представления — абстрактное синтаксическое дерево (AST), граф потока управления (CFG) и граф потока данных (DFG) — а затем применяет правила по шаблонам или taint-анализ для обнаружения небезопасных конструкций, сопоставленных с идентификаторами CWE. Taint-анализ — это основной движок: он помечает недоверенные источники (HTTP-параметр, чтение файла), отслеживает, как эти данные распространяются через переменные и вызовы функций, и формирует находку, когда они достигают опасного стока (SQL-запрос, exec, HTML-ответ), не пройдя через распознанный санитайзер. Поскольку ничего не выполняется, SAST работает в IDE, pre-commit-хуках и CI и может анализировать код задолго до его выпуска.

Его слабые места хорошо задокументированы. SAST силён на детерминированных ошибках (SQL-инъекции, XSS-стоки, захардкоженные секреты, слабая криптография), но выдаёт ложные срабатывания на путях, недостижимых во время выполнения, и пропускает проблемы конфигурации, логики аутентификации и исключительно рантайм-уязвимости — поэтому зрелые программы дополняют его SCA и DAST. Настройка наборов правил и разбор шума — вот реальные операционные затраты. Такие стандарты, как OWASP ASVS и NIST SSDF, ссылаются на статический анализ как на контроль верификации. Среди распространённых движков — Semgrep, GitHub CodeQL (который запрашивает код как базу данных), SonarQube, Checkmarx, Fortify и Snyk Code.

flowchart LR
  SRC[Исходный код / байт-код] --> P[Разбор в AST + CFG + DFG]
  P --> T[Taint-анализ + правила]
  SO[Недоверенный источник] -. отслеживаемый поток .-> T
  T --> SK{Достигает стока<br/>без санитайзера?}
  SK -->|Да| F[Находка, сопоставленная с CWE]
  SK -->|Нет| OK[Нет оповещения]
  F --> TR[Разбор: исправить или пометить ложным срабатыванием]