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

Статическое тестирование безопасности приложений (SAST) — это категория автоматизированных инструментов безопасности, которые сканируют исходный код приложения на предмет известных паттернов уязвимостей без выполнения программы — ищут такие вещи, как риски SQL-инъекций (конкатенация пользовательского ввода напрямую в строку запроса), захардкоженные секреты и API-ключи, случайно закоммиченные в репозиторий, небезопасное использование криптографических функций и версии зависимостей с известными уязвимостями. Инструменты включают Semgrep, Snyk Code, SonarQube, а также встроенные в GitHub CodeQL и сканирование секретов. Почему это важно для разработчиков AI/SaaS: уязвимости безопасности значительно дешевле поймать до того, как код попадёт в production, а инструменты SAST — одна из немногих проверок безопасности, которая может выполняться автоматически и дёшево на каждом отдельном pull request, обеспечивая непрерывное, масштабируемое покрытие, недостижимое для ручного анализа безопасности при темпе выпуска команд. Это особенно важно для команд, активно опирающихся на код, сгенерированный ИИ, поскольку LLM может сгенерировать код, который выглядит правильным, но воспроизводит небезопасный паттерн, усвоенный из обучающих данных (классический пример: SQL, собранный конкатенацией строк, или проверка авторизации, присутствующая на счастливом пути, но отсутствующая в граничном случае) — сканер SAST ловит это механически, как объективную страховку, не зависящую от того, заметит ли это человек-рецензент. Как это работает: инструмент SAST разбирает исходный код в абстрактное синтаксическое дерево (аналогично линтеру) и сопоставляет паттерны с базой данных правил известных небезопасных паттернов кода, помечая расположения файл/строка с рейтингом серьёзности и часто с предлагаемым исправлением. В отличие от динамического тестирования безопасности (которое требует запущенного приложения и тестирует реальное поведение), SAST работает исключительно с исходным кодом, что означает, что он может запускаться чрезвычайно рано — в редакторе, в pre-commit хуке и определённо в CI — и может ловить некоторые категории багов (например, захардкоженные секреты), которые динамическое тестирование никогда бы не выявило. Практический пример: разработчик пишет `db.query("SELECT * FROM users WHERE email = '" + userInput + "'")` для поиска пользователя по email. Сканер SAST, запущенный в CI, немедленно помечает это как критическую уязвимость SQL-инъекции — вредоносное значение `userInput` вроде `' OR '1'='1` вернуло бы каждую строку в таблице — и блокирует слияние pull request до исправления. Разработчик переписывает это с использованием параметризованного запроса, `db.query("SELECT * FROM users WHERE email = $1", [userInput])`, сканер повторно запускается и проходит проверку, и уязвимость никогда не достигает развёрнутого окружения, где её можно было бы реально эксплуатировать.