5. Тест: DevSecOps и автоматизация

Какие правила gosec обнаруживают SQL-инъекции в Go-коде?

G101 и G102 G201 и G202 G301 и G302 G401 и G402

Разработчик вынес построение SQL-запроса в отдельную функцию `buildQuery(input string) string`, которая использует `fmt.Sprintf`. Хендлер вызывает `db.Query(buildQuery(r.URL.Query().Get("q")))`. Обнаружит ли gosec эту уязвимость?

Да, gosec отследит taint через вызов функции Нет, gosec не выполняет межпроцедурный анализ потока данных Да, но только если включить флаг -deep Зависит от версии gosec

В CI/CD pipeline вы настроили SAST (gosec + Semgrep) и SCA (govulncheck). Оба проходят успешно. Может ли приложение всё ещё содержать SQL-инъекцию?

Нет, SAST + SCA покрывают все возможные уязвимости Нет, если добавить ещё golangci-lint Да — SAST не находит Blind SQLi, Second-Order и логические ошибки; нужен DAST Да, но только если используется ORM

На какой стадии CI/CD pipeline должен запускаться DAST-сканер (sqlmap / OWASP ZAP)?

На этапе сборки (build), до запуска приложения Параллельно с SAST, на каждый push После деплоя на staging — DAST требует работающее приложение Только вручную, раз в квартал

Зачем нужен WAF (ModSecurity) в production, если в CI/CD уже есть SAST и DAST?

WAF не нужен — SAST + DAST достаточно WAF заменяет prepared statements WAF защищает от zero-day уязвимостей и логических ошибок, которые автоматика не поймала WAF нужен только для соответствия PCI DSS

Какой инструмент лучше всего подходит для обнаружения Time-based Blind SQL-инъекций?

gosec — он анализирует AST и видит все паттерны Semgrep Community — у него есть taint analysis govulncheck — он проверяет известные CVE sqlmap — он отправляет реальные запросы и измеряет задержки ответа