Ответ
В DevOps-практике статический анализ кода (SAST) — обязательный этап пайплайна для обеспечения качества и безопасности. Я настраиваю его как часть CI, чтобы проблемы обнаруживались до мержа кода.
Основные инструменты, которые интегрирую в CI/CD:
- SonarQube / SonarCloud — основной инструмент для комплексного анализа. Настраиваю Quality Gates, которые блокируют мерж, если не пройдены проверки на покрытие тестами, дублирование кода, уязвимости безопасности (OWASP Top 10) и запахи кода (code smells). Поддерживает более 20 языков.
- Semgrep — использую для поиска шаблонов уязвимостей и соблюдения внутренних стандартов кодирования. Легко интегрируется в любой CI.
- Trivy или Grype — сканеры уязвимостей в зависимостях (SBOM). Запускаю их на этапе сборки Docker-образов.
- Checkov или Terrascan — для статического анализа инфраструктурного кода (Terraform, CloudFormation, Kubernetes). Проверяют на безопасные конфигурации и compliance.
- Hadolint — линтер для Dockerfile, проверяет на best practices.
Пример конфигурации этапа в GitLab CI:
stages:
- test
- security
sonarqube-check:
stage: test
image: sonarsource/sonar-scanner-cli
script:
- sonar-scanner -Dsonar.projectKey=my_project -Dsonar.sources=.
sast:
stage: security
script:
- semgrep --config=p/security-audit .
- trivy fs --severity HIGH,CRITICAL .
allow_failure: false # Блокируем пайплайн при критических уязвимостях
infra-scan:
stage: security
script:
- checkov -d terraform/Практика: Все эти проверки выполняются автоматически при каждом пулл-реквесте. Результаты комментируются в MR, а критичные проблемы блокируют pipeline. Это позволяет "сдвинуть безопасность влево" и экономить время на ревью.