DevOps
DevSecOps
В 2022 году хакеры украли $130M у Wintermute (crypto trading firm) использовав уязвимость в библиотеке которую можно было найти через Snyk за 30 секунд. В 2023 CircleCI был взломан через компрометированный laptop разработчика - утекли секреты тысяч CI/CD pipeline. DevSecOps не параноя - это страховка от потерь в миллионы долларов.
- **GitHub** сканирует каждый коммит на секреты через Secret Scanning - в 2023 обнаружено и заблокировано 1.7 миллиона токенов и ключей до их публикации
- **Netflix** требует SAST и dependency scanning как gate для каждого PR - Semgrep заблокировал 200+ критических уязвимостей до попадания в production в 2023 году
- **Shopify** использует OIDC для всех GitHub Actions вместо static AWS credentials - полностью исключён риск компрометации через утечку CI/CD ключей
Shift-Left Security
Shift-left - перенос проверок безопасности как можно раньше в цикл разработки. Стоимость устранения уязвимости: $80 на этапе разработки → $960 при тестировании → $7600 в production (IBM Research). Shift-left интегрирует security проверки в IDE, pre-commit hooks, CI/CD pipeline - вместо финального security audit перед релизом.
Инструменты shift-left: IDE плагины (SonarLint для Java/JS, Snyk для зависимостей), pre-commit hooks (detect-secrets, gitleaks для секретов, bandit для Python), GitHub Advanced Security (secret scanning, dependency review в PR). Цель: developer сам видит и исправляет проблему - не узнаёт о ней через 3 недели от security команды.
Почему устранение уязвимости в production в 100x дороже чем на этапе разработки?
SAST (Static Analysis)
SAST (Static Application Security Testing) - анализ исходного кода без выполнения. Находит: SQL инъекции, XSS, небезопасная десериализация, hardcoded credentials, уязвимые зависимости. Инструменты: Semgrep (быстрый, кастомные правила), SonarQube (enterprise, code quality + security), Snyk Code, GitHub CodeQL.
Snyk для dependencies - отдельная категория (SCA - Software Composition Analysis): сканирует package.json/requirements.txt, сравнивает с базой CVE, предлагает upgrade path. npm audit встроен в npm но Snyk даёт больше контекста и fix PRs автоматически. Trivy сканирует Docker образы на CVE в OS пакетах и libraries.
Чем Snyk отличается от `npm audit`?
DAST (Dynamic Analysis)
DAST (Dynamic Application Security Testing) - тестирование работающего приложения: отправка специально сформированных запросов и анализ ответов. Находит уязвимости которые SAST пропускает: authentication bypasses, runtime injection, CORS misconfigurations, открытые endpoints. Инструменты: OWASP ZAP (open source), Burp Suite (enterprise), Nuclei.
DAST в CI/CD: запускают против staging окружения после деплоя. OWASP ZAP Baseline Scan - быстрый пассивный скан за 2-5 минут, не ломает функциональность. Full Active Scan - агрессивный, 30+ минут, может нарушить данные (запускать на изолированном окружении). Nuclei - template-based scanner с 8000+ готовых проверок CVE и misconfiguration.
Почему DAST запускается против staging, а не production?
Secret Management в CI/CD
Секреты в CI/CD: API ключи, database passwords, TLS сертификаты, SSH ключи. Никогда не хранить в git (даже в private репозитории). Правило: ротировать компрометированный секрет немедленно, не надеяться на то что 'никто не увидел'. GitHub Actions Secrets, GitLab CI Variables, HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager - основные опции.
Принцип наименьших привилегий для CI/CD: GitHub Actions OIDC - pipeline получает временный JWT токен от GitHub, обменивает его на AWS/GCP credentials без хранения долгосрочных ключей. Токен живёт только во время pipeline выполнения. Это лучшая практика 2024 года - никаких AWS_ACCESS_KEY_ID в GitHub Secrets.
Если репозиторий private, секреты в коде не опасны - их никто не увидит
Секреты в git попадают в историю коммитов навсегда. При компрометации аккаунта, при добавлении нового collaborator, при смене visibility на public - секрет будет виден. git history не позволяет по-настоящему удалить commit
git filter-branch / BFG очищают локальную копию, но fork, CI/CD кэши и backup копии у GitHub могут сохранить старый коммит. Единственный надёжный ответ - ротация компрометированного секрета
Почему GitHub Actions OIDC лучше чем хранить AWS_ACCESS_KEY_ID в GitHub Secrets?
Ключевые идеи
- **Shift-left** - находить уязвимости в IDE и pre-commit hooks: исправление стоит в 100x меньше чем в production
- **SAST + DAST** - статический анализ кода (Semgrep, Snyk) + динамическое тестирование работающего приложения (OWASP ZAP, Nuclei) в CI/CD
- **Secret Management через OIDC** - никаких static credentials в GitHub Secrets; временные токены через OIDC + секреты из AWS Secrets Manager/Vault
Связанные темы
DevSecOps тесно связан с управлением секретами и compliance:
- Vault и управление секретами — HashiCorp Vault - более продвинутое решение: dynamic secrets, PKI, audit log для enterprise compliance
- Platform Engineering — Security scanning встраивается в golden path templates - каждый новый сервис получает SAST/DAST автоматически
Вопросы для размышления
- Если Snyk нашёл критическую CVE в production зависимости - какой процесс исправления правильный и как быстро это нужно сделать?
- Как организовать DAST чтобы он не ломал staging данные при каждом запуске?
- Почему GitHub OIDC лучше чем хранить AWS credentials в HashiCorp Vault для CI/CD?