Secure SDLC

2021 год. Log4Shell. Уязвимость которую можно было найти SAST инструментом в 2013. 8 лет в production. 3 миллиарда затронутых устройств. Цена: сотни миллионов долларов на патчинг по всей индустрии. Один SAST scan с правилом на JNDI lookup мог предотвратить одну из крупнейших уязвимостей в истории.

• **Google**: Application Security Reviews обязательны перед GA для любого продукта работающего с user data
• **Microsoft**: SDL (Security Development Lifecycle) - методология созданная после безопасного расчета Windows XP и внедренная начиная с Vista/Server 2003
• **GitHub Advanced Security**: CodeQL + secret scanning + Dependabot alerts встроены в workflow для всех GitHub repos

SAST: статический анализ безопасности

2021 год. Log4Shell - уязвимость в Apache Log4j. Затронуто более 3 миллиардов устройств. Уязвимость существовала в коде с 2013 года - 8 лет. SAST инструмент проверяющий паттерн ${} в JNDI lookup обнаружил бы ее при первом commit'е в 2013.

SAST (Static Application Security Testing) - анализ исходного кода без запуска. Ищет известные паттерны уязвимостей: SQL injection (конкатенация строк в SQL), XSS (неэкранированный вывод), hardcoded secrets (API ключи в коде), небезопасные crypto алгоритмы (MD5 для паролей), path traversal. Работает на любом этапе: в IDE (real-time), в pre-commit hook, в CI pipeline.

Semgrep - open-source SAST с синтаксисом правил близким к самому коду. Правило для обнаружения SQL injection в Python: `pattern: '$X.execute($QUERY + ...)`. Правила пишутся командой, не vendors - это позволяет добавлять кастомные паттерны под конкретный стек. GitHub Advanced Security использует CodeQL - query-based подход, где уязвимости описываются как запросы к графу кода.

DAST: динамическое тестирование безопасности

SAST видит код, но не видит runtime поведение. DAST видит runtime, но не видит код. Они дополняют друг друга. DAST (Dynamic Application Security Testing) - атака на работающее приложение через HTTP: отправка вредоносных payload в параметры, формы, заголовки. Находит то что нельзя найти статически: бизнес-логика уязвимости, rate limiting отсутствие, неправильные HTTP headers.

OWASP ZAP (Zed Attack Proxy) - стандарт для automated DAST. Два режима: passive scan (анализ трафика без атак - безопасно в prod) и active scan (отправка атакующих payload - только в staging). DAST интегрируется в CI через CLI: `zap-baseline.py -t https://staging.example.com`. Результаты - SARIF формат совместимый с GitHub Security.

Pentesting vs DAST: автоматизированный DAST находит известные уязвимости по паттернам - быстро, воспроизводимо, дешево. Ручной pentesting находит логические уязвимости, бизнес-контекстные проблемы, нестандартные комбинации - медленно, дорого, экспертно. Зрелая программа безопасности использует оба: DAST в каждом CI прогоне, pentesting 1-2 раза в год или перед major релизом.

DevSecOps: безопасность как часть pipeline

DevSecOps - не инструмент и не роль. Это принцип: security checks автоматизированы и встроены в workflow разработчика. Разработчик получает feedback о security issues так же быстро как о lint ошибках. Cost of fixing a vulnerability: USD 80 в design phase, USD 960 в coding, USD 7600 в testing, USD 14500 в maintenance. Смещение влево (shift left) окупается экономически.

Зрелый DevSecOps pipeline включает несколько слоев: pre-commit (secrets scan, basic lint), PR (SAST, dependency check), staging (DAST, IAST), pre-release (pentesting), production (RASP, monitoring). Ключевой принцип: каждый слой должен давать actionable feedback разработчику, не просто список CVE номеров без контекста.

SBOM (Software Bill of Materials) - список всех компонентов ПО с версиями. Аналог ingredient list на продуктах питания. С 2021 года исполнительный приказ Biden обязал US federal контракторов предоставлять SBOM. Форматы: SPDX (Linux Foundation), CycloneDX (OWASP). При появлении новой CVE (как Log4Shell) компания с SBOM за 10 минут знает какие продукты затронуты. Без SBOM - дни ручного поиска.

Threat Modeling: проектирование безопасности

Инструменты хорошо находят известные паттерны. Но бизнес-логику уязвимости - 'пользователь может купить товар за 0 рублей через race condition в оплате' - не найдет никакой SAST. Threat Modeling - структурированный процесс поиска таких уязвимостей на этапе проектирования.

STRIDE - Microsoft методология threat modeling: Spoofing (подделка идентификации), Tampering (изменение данных), Repudiation (отрицание действий), Information Disclosure (утечка данных), Denial of Service (отказ в обслуживании), Elevation of Privilege (повышение привилегий). Для каждого компонента системы (из DFD - Data Flow Diagram) перебираются угрозы STRIDE и определяются контрмеры.

Threat modeling нужен не только для new features. Security review перед релизом - стандартная практика в Google, Microsoft, Amazon. Google проводит Application Security Reviews (ASR) для любого проекта обрабатывающего user data. Процесс: команда заполняет security questionnaire, security team проводит review, выдает список must-fix до GA (General Availability) и should-fix после.

Связанные темы

Secure SDLC объединяет security practices на всех уровнях разработки:

• OWASP и Web Security — OWASP Top 10 - основной список угроз для SAST/DAST правил
• API Security — DAST тестирует API endpoints - часть OWASP API Security Top 10
• DDoS митигация — Rate limiting и DoS protection - часть threat modeling для публичных сервисов

Ключевые идеи

• **SAST**: статический анализ в IDE/CI; Semgrep для кастомных правил; baseline чтобы не блокировать legacy код
• **DAST**: атака работающего staging; OWASP ZAP в CI; только passive scan в production, active - только в изолированном staging
• **DevSecOps**: shift left снижает cost of fix в 180x; actionable alerts в PR важнее объема alerts
• **Threat Modeling**: STRIDE на этапе design находит business logic уязвимости которые SAST/DAST пропускают

Вопросы для размышления

• Log4Shell существовал 8 лет. Какие процессы из Secure SDLC могли обнаружить его раньше? Почему они не были внедрены?
• Как приоритизировать security работу в стартапе с командой 5 человек? Какие минимальные практики дают максимальный эффект?
• SBOM становится обязательным в regulated industries. Какие операционные изменения требует внедрение SBOM в существующий DevOps процесс?

Связанные уроки

• sec-15 — DDoS mitigation - пример архитектурной защиты, которую закладывает Secure SDLC
• sec-04 — OWASP Top 10 - список уязвимостей которые ищет SAST/DAST
• sec-11 — API security checks входят в DAST pipeline
• se-10 — CI/CD pipeline - инфраструктура в которую встраивается DevSecOps
• se-11 — Code review процесс расширяется security review в Secure SDLC
• os-11-security