AppSec в DevSecOps: полное руководство по встраиванию безопасности в CI/CD pipeline

По данным Puppet State of DevOps Report, организации с зрелыми DevSecOps-практиками в 2,6 раза чаще устраняют критические уязвимости в течение суток. Остальные узнают о проблемах после того, как pipeline уже выкатил уязвимый код в production. Я видел команды, которые купили SAST-сканер за несколько миллионов рублей, воткнули его в pipeline и через месяц получили 14 000 findings. Разработчики перестали читать отчёты на третий день. Сканер работал, pipeline «зеленел», а уязвимости уходили в production ровно так же, как и до его появления.

AppSec в DevSecOps - не покупка инструмента. Это инженерная дисциплина: какой сканер на какой стадии запускается, какие findings блокируют merge request, как отличить реальную SQL-инъекцию от шума, кто владеет уязвимостью и за какой SLA её закрывает. Здесь - полная карта: от threat modeling до метрик MTTR, от первого SAST-правила до policy-as-code gate, который не пропустит критический дефект в релизную ветку.

Карта темы: навигатор по AppSec в CI/CD​

AppSec и DevSecOps: где заканчивается одно и начинается другое​

Путаница между терминами AppSec и DevSecOps стоит командам месяцев потерянного времени. Компания покупает SAST-лицензию, объявляет «у нас DevSecOps» и удивляется, почему уязвимости продолжают попадать в production.

Application Security - это набор практик безопасности приложений: моделирование угроз, secure code review, тестирование (SAST, DAST, IAST, SCA), управление уязвимостями, обучение разработчиков. AppSec существует десятилетиями - Microsoft представила SDL ещё в 2004 году. Эти практики можно внедрить даже в водопадную модель без какой-либо автоматизации.

DevSecOps - способ доставки AppSec-практик через автоматизацию в CI/CD pipeline. Ключевое отличие: DevSecOps добавляет автоматические триггеры (сканирование при каждом pull request), quality gates (блокировка сборки при critical findings), policy-as-code (правила в виде YAML/Rego, а не PDF-документов) и непрерывный feedback loop.

Если у вас есть SAST-сканер, но его запускает вручную security-инженер раз в квартал - это AppSec. Если тот же SAST запускается автоматически на каждый merge request, результаты фильтруются кастомными правилами, critical findings блокируют MR, а medium попадают в Jira с SLA - это DevSecOps.

Разделение условно. OWASP SAMM описывает зрелость AppSec-программы по категориям Governance, Design, Implementation, Verification, Operations. OWASP DSOMM добавляет конкретные уровни зрелости DevSecOps: Build, Patch, Test, Information Gathering, Culture. Зрелая организация сочетает оба подхода: AppSec определяет «что проверять», DevSecOps - «как и когда автоматизировать проверку».

Вывод простой: начинайте с AppSec-практик (threat modeling, security requirements), потом автоматизируйте их через DevSecOps. Покупка сканера до формулирования требований безопасности - гарантированный путь к alert fatigue.

Архитектура безопасного pipeline: 8 стадий, на которых ловятся уязвимости​

Типичный CI/CD pipeline без security gates выглядит просто: commit - build - test - deploy. Безопасный pipeline добавляет проверки на каждом этапе, но не все проверки одинаково полезны на каждой стадии.

Стадия 1: Pre-commit. IDE-плагины и pre-commit hooks ловят секреты и очевидные паттерны ещё до push. Gitleaks в режиме pre-commit hook - минимальная точка входа, не требующая изменений pipeline.

Стадия 2: Commit / Pull Request. SAST-сканирование запускается автоматически. Semgrep или CodeQL анализируют diff, а не весь репозиторий - время проверки падает с минут до секунд. Секрет-сканер (TruffleHog, Gitleaks) проверяет изменения на наличие ключей API, паролей и токенов.

Стадия 3: Build. SCA-инструмент (Dependency-Track, Snyk) генерирует SBOM в формате CycloneDX или SPDX и проверяет зависимости по базам уязвимостей (NVD, OSV). На этой же стадии сканируется IaC - Terraform-файлы, Helm-чарты, Kustomize-манифесты.

Стадия 4: Container image build. Trivy или Grype сканируют собранный Docker-образ на уязвимые пакеты в base image. Проверяются Dockerfile best practices: запуск от non-root, фиксированные теги образов, отсутствие COPY . . с секретами.

Стадия 5: Test / Staging. DAST-сканер (OWASP ZAP в headless-режиме, Nuclei) работает по развёрнутому приложению. IAST-агент инструментирует runtime и коррелирует динамические находки с конкретными строками кода.

Стадия 6: Security gate. Policy-as-code движок (OPA/Rego или встроенные gate-политики CI-системы) принимает решение: pass/fail. Critical и High с подтверждённой эксплуатабельностью - fail build. Medium - задача с SLA. Low - информационно.

Стадия 7: Release / Deploy. Подпись артефактов (cosign для container images, Sigstore для SBOM). Admission controller в Kubernetes (Kyverno, OPA Gatekeeper) проверяет, что деплоится только подписанный и просканированный образ.

Стадия 8: Production monitoring. WAF, runtime container security, мониторинг новых CVE для задеплоенных зависимостей - замыкание цикла обратной связи.

Пример стадии security gate в GitLab CI, который мы использовали для проверки результатов SAST:
Gate считает количество Critical-findings в отчёте SAST и блокирует pipeline, если их больше нуля. На практике мы ужесточали порог постепенно: первый месяц - только Critical, через квартал - Critical + confirmed High.

SAST в CI/CD: 3 инструмента и стратегия снижения шума на 60%​

Статический анализ - первый инструмент, который обычно прикручивают к pipeline. И первый, который начинают игнорировать из-за false positives. По опыту, неконфигурированный SonarQube на Java-проекте средних размеров генерирует тысячи findings, из которых реально эксплуатируемых - единицы процентов.

Semgrep работает по принципу pattern-matching: вы пишете правила на языке, близком к коду, и сканер ищет точные совпадения. Сильная сторона - скорость (секунды на среднем проекте) и низкий порог входа для кастомных правил. Слабая - отсутствие межпроцедурного анализа в community-версии. Для быстрого старта - за глаза.

CodeQL от GitHub использует семантический анализ: код компилируется в базу данных, по которой выполняются запросы на языке QL. Мощнее Semgrep для taint-анализа (отслеживание потока данных от source к sink), но требует компиляции проекта и работает заметно медленнее.

SonarQube сочетает SAST с анализом качества кода. Удобен для команд, которым нужен единый дашборд по code quality и security. Минус - коммерческая версия стоит ощутимо, а community-версия ограничена по языкам и правилам безопасности. (Если бюджет нулевой - Semgrep + CodeQL закроют 80% потребностей.)

Стратегия снижения шума, которая у нас сработала:

1. Начните с minimal ruleset. Не включайте все правила сразу. Для Semgrep - стартуйте с p/owasp-top-ten, для SonarQube - только Blocker и Critical. Наращивайте покрытие после того, как команда привыкнет к процессу.
2. Baseline: игнорируйте legacy. При первом запуске зафиксируйте существующие findings как baseline. Новые MR проверяйте только на delta - новые findings.
3. Кастомные правила вместо generic. Напишите 5-10 правил под ваш стек. Semgrep-правило для вашего внутреннего ORM, которое ловит конкретный паттерн небезопасного запроса, ценнее тысячи generic rules.

Подробный разбор настройки каждого из трёх инструментов с конкретными конфигами и стратегиями подавления false positives - в гайде SAST инструменты для CI/CD: Semgrep, CodeQL и SonarQube - настройка правил без alert fatigue.

DAST и IAST: почему статического анализа недостаточно​

SAST анализирует исходный код, но не видит того, что происходит в runtime. Misconfigurations, ошибки аутентификации, проблемы CORS, broken access control (A01:2021 по OWASP Top 10) - всё это обнаруживается только при работе с запущенным приложением.

DAST (Dynamic Application Security Testing) - чёрный ящик. Сканер отправляет запросы к работающему приложению, фаззит параметры, ищет XSS, injection (A03:2021), misconfigurations (A05:2021). OWASP ZAP в headless-режиме - стандартный выбор для pipeline-интеграции: бесплатный, с Docker-образом, с API для автоматизации. Burp Suite Enterprise - коммерческая альтернатива с лучшим сканером, но требует лицензии на каждый concurrent scan.

Главный trade-off DAST в pipeline - время сканирования. Полный crawl + active scan средних размеров веб-приложения занимает от 20 минут до нескольких часов. Решение - разделение на «быстрый» и «глубокий» DAST:

• Быстрый DAST (5-10 минут): baseline scan + targeted checks на каждый merge в основную ветку. Проверяет только новые endpoints из OpenAPI-спецификации.
• Глубокий DAST (2-4 часа): полный crawl + active scan. Запускается по расписанию (ночью) или перед релизом.

IAST (Interactive Application Security Testing) объединяет подходы SAST и DAST. Агент инструментирует runtime приложения и наблюдает за потоком данных изнутри во время выполнения функциональных тестов. IAST видит конкретную строку кода, вызвавшую уязвимость, и подтверждает эксплуатабельность. Инструментация требует совместимого runtime (Java/.NET - хорошая поддержка, Go/Rust - ограниченная).

На практике IAST разворачивается как Java-агент (например, -javaagent:contrast-agent.jar), подключённый к приложению во время прогона integration-тестов. Каждый HTTP-запрос из тестового набора одновременно проверяется на уязвимости.

Если ваши функциональные тесты покрывают 70%+ endpoints - IAST даст отличные результаты. Если тестов мало - DAST окажется эффективнее, потому что сам генерирует запросы. Тут без вариантов.

SCA и SBOM: контроль цепочки поставок зависимостей​

Современное приложение на 70-90% состоит из стороннего кода: open source библиотеки, фреймворки, транзитивные зависимости. Атака на цепочку поставок (MITRE ATT&CK T1195, включая T1195.001 - Compromise Software Dependencies and Development Tools) - один из самых эффективных векторов initial access.

Software Composition Analysis (SCA) решает задачу: какие зависимости используются, какие из них содержат известные CVE и какие лицензии несовместимы с вашим проектом.

Dependency-Track от OWASP - бесплатное решение с хорошей интеграцией через Jenkins-плагин и REST API. Принимает SBOM в формате CycloneDX, проверяет компоненты по NVD и другим базам. Как показывает опыт ЛАНИТ (описанный на Habr), при внедрении Dependency-Track критически важно разобраться с false positives: база NVD содержит записи разной точности, и не каждый CVE в зависимости означает эксплуатабельную уязвимость в вашем контексте.

Snyk - коммерческая альтернатива с более качественной базой уязвимостей (собственная research-команда), автоматическими pull request с обновлением уязвимых зависимостей и интеграцией с IDE. Free-тир покрывает до 200 тестов в месяц - для небольшой команды хватит.

SBOM (Software Bill of Materials) - формализованный список всех компонентов. Генерируется автоматически при сборке (CycloneDX Maven plugin для Java, @cyclonedx/cyclonedx-npm для Node.js). SBOM - не просто отчёт: это артефакт, который подписывается, хранится рядом с release и используется для ретроспективного анализа при публикации нового CVE.

Пример генерации SBOM для frontend-проекта и публикации в Dependency-Track:
Детальный разбор инструментов SCA, стратегий работы с SBOM и настройки Dependency-Track - в гайде Анализ зависимостей: SCA-инструменты, Dependency-Track, Snyk и SBOM на практике.

Секреты в коде: почему API-ключ в репозитории опаснее SQL-инъекции​

Захардкоженные credentials в исходном коде - техника MITRE ATT&CK T1552.001 (Credentials In Files). Атакующий, получивший доступ к репозиторию (T1213.003 - Code Repositories), мгновенно получает ключи к production-инфраструктуре. Не нужно эксплуатировать уязвимость в рантайме - достаточно grep по истории коммитов.

Secret scanning решает три задачи:

1. Pre-commit prevention. Git-хук не позволяет закоммитить файл с паттерном, похожим на AWS-ключ или токен GitHub. Gitleaks в режиме pre-commit - первая линия обороны.
2. Pipeline detection. TruffleHog или Gitleaks проверяет каждый MR. Найденный секрет блокирует merge.
3. Historical scan. Полное сканирование всей истории репозитория выявляет секреты, которые «удалены» из HEAD, но остаются в git log. А они там остаются - git ничего не забывает.

Критическая ошибка - полагаться только на regex-паттерны. Современные сканеры (TruffleHog v3) умеют верифицировать найденные секреты: проверять, действителен ли AWS-ключ, активен ли GitHub-токен. Это радикально снижает false positive rate.

После обнаружения секрета правильный процесс: ротация credentials (не просто удаление из кода!), добавление в .gitignore, перевод на Vault/AWS Secrets Manager/Azure Key Vault для динамической выдачи credentials.

Подробно об инструментах, конфигурации и интеграции с Vault - в гайде Secrets Management в CI/CD: Trufflehog, Gitleaks и Vault.

Container security scanning: от Dockerfile до runtime​

Контейнеризированные приложения добавляют новый слой для атаки: уязвимости в base image, insecure defaults (запуск от root, escalated privileges), устаревшие пакеты в слоях образа. По NIST SP 800-190, контейнерные образы из публичных реестров часто содержат небезопасные конфигурации по умолчанию. Kubernetes STIG от DISA определяет конкретные контроли для безопасной эксплуатации.

В pipeline container security встраивается на двух этапах:

Image scanning при сборке. Trivy, Grype или встроенные сканеры реестров (Harbor, GitLab Container Registry) проверяют слои образа. Результат - список CVE с severity и рекомендацией по обновлению пакета. Security gate блокирует push в реестр, если обнаружены Critical CVE в base image.

Admission control при деплое. Kyverno или OPA Gatekeeper в Kubernetes проверяют манифесты: запрещают privileged: true, требуют readOnlyRootFilesystem, ограничивают использование latest-тегов, проверяют подпись образа через cosign. Если deployment не соответствует policy - admission webhook отклоняет запрос к API-серверу.

Runtime protection. Мониторинг поведения контейнеров в production: обнаружение запуска неожиданных процессов, сетевых соединений, файловых операций. Техника MITRE ATT&CK T1610 (Deploy Container) описывает использование контейнеров атакующими для выполнения вредоносного кода.

Минимальный чеклист container security для pipeline:

• Base image из доверенного реестра (не latest с Docker Hub)
• Non-root user в Dockerfile (USER 1001)
• Фиксированные digest вместо тегов (image@sha256:...)
• Trivy/Grype scan с порогом --severity HIGH,CRITICAL
• Подпись образа через cosign перед push в production registry
• Kyverno policy в кластере, проверяющая подпись

Security gates и policy-as-code: когда pipeline обязан упасть​

Security gate - точка принятия решения в pipeline: пропустить артефакт дальше или заблокировать. Без gate все сканеры превращаются в генераторы отчётов, которые никто не читает.

Главный вопрос - порог блокировки. Слишком строгий (блокировать при любом finding) - парализует разработку. Слишком мягкий (никогда не блокировать) - обесценивает весь pipeline. Нужен баланс, и он достигается поэтапно.

Рабочая стратегия, которую мы внедряли:

Месяц 1-2: shadow mode. Gate включён, но работает в режиме allow_failure: true. Собирает статистику: сколько MR были бы заблокированы, какие findings преобладают. Команда привыкает видеть результаты. Никакой боли, чистое наблюдение.

Месяц 3: блокировка Critical. Gate блокирует MR только при наличии Critical findings. Это обычно: SQL injection, hardcoded secrets, RCE-паттерны. Таких findings немного, и каждый из них требует немедленного внимания.

Месяц 4-6: расширение до High. Добавляем блокировку по High-severity findings с подтверждённой эксплуатабельностью. Для SAST это findings с taint flow (source → sink подтверждён), для SCA - CVE с известным exploit в public.

Месяц 6+: дифференцированные SLA. Medium findings не блокируют pipeline, но автоматически создают задачу в трекере с SLA (например, 30 дней). Low - информационно, без SLA. Исключения (accepted risk) оформляются явно, с указанием ответственного и срока пересмотра.

Policy-as-code делает эти правила версионируемыми и аудируемыми. Вместо устной договорённости «мы не деплоим с critical» - YAML-файл в репозитории, который проверяется pipeline. OPA с Rego-политиками, встроенные quality gates SonarQube или кастомный скрипт на jq (как в примере выше) - выбор инструмента зависит от сложности правил.

Shift left security: threat modeling как фундамент pipeline​

Shift left security - принцип смещения проверок безопасности на ранние этапы SDLC. Самая ранняя точка - проектирование, ещё до написания кода. Threat modeling определяет, что именно защищать и от каких угроз.

Без threat model pipeline сканирует «всё подряд». С threat model - pipeline знает, что для payment-сервиса приоритет A01:2021 (Broken Access Control) и A02:2021 (Cryptographic Failures), а для внутреннего dashboard - A05:2021 (Security Misconfiguration). Разница - как между стрельбой по площадям и прицельным огнём.

Связь threat model с pipeline:

• Результаты STRIDE-анализа определяют, какие SAST-правила включить для конкретного сервиса. Threat model указывает на риск Spoofing - включаем правила проверки аутентификации. Tampering - правила валидации входных данных.
• Критичность сервиса из threat model определяет строгость security gate. Payment API - блокировка при High, internal tool - блокировка только при Critical.
• Trust boundaries из модели угроз определяют scope DAST-сканирования: внешние API - полный active scan, внутренние - baseline.

OWASP ASVS (Application Security Verification Standard) помогает структурировать security requirements по трём уровням: Level 1 (минимальный, все приложения), Level 2 (большинство приложений), Level 3 (критичные приложения). Уровень ASVS привязывается к результатам threat modeling.

Подробный разбор методологий STRIDE, PASTA и деревьев атак с примерами - в гайде Threat Modeling для разработчиков: STRIDE, PASTA и деревья атак на практике.

IaC scanning: безопасность инфраструктуры как кода​

Terraform-файлы, Helm-чарты и CloudFormation-шаблоны - такой же код, как и приложение, и содержат такие же уязвимости: открытые порты, отсутствие шифрования, excessive permissions. По исследованиям Palo Alto Unit 42, значительная доля IaC-шаблонов содержит misconfigurations, не соответствующие ни best practices, ни корпоративным security policies.

IaC-сканирование запускается на стадии build, параллельно с SAST и SCA. Инструменты:

• tfsec / Trivy (config mode) - сканирование Terraform. Проверяет: шифрование at rest, security groups, IAM policies, публичный доступ к storage.
• kube-score - оценка Kubernetes-манифестов по best practices. Не security-сканер в чистом виде, но ловит security-related misconfigurations.
• checkov от Bridgecrew - мультиплатформенный IaC-сканер с поддержкой Terraform, CloudFormation, Kubernetes, Dockerfile.

Security gate для IaC работает по тому же принципу: Critical misconfigurations (публичный S3 bucket, security group 0.0.0.0/0 на порт 22) блокируют pipeline. Medium (отсутствие тегов, нестандартное именование) - предупреждение.

Метрики AppSec в DevSecOps: 5 показателей, которые не врут​

Без метрик невозможно понять, работает ли ваш AppSec-pipeline или просто создаёт иллюзию безопасности. «Количество найденных уязвимостей» - плохая метрика: рост числа findings может означать как ухудшение кода, так и улучшение правил сканера. Цифра без контекста врёт.

Пять метрик, которые дают реальную картину:

1. MTTR уязвимостей (Mean Time to Remediate). Среднее время от обнаружения до исправления. Разбивается по severity: MTTR для Critical должен быть дни, для Medium - недели, для Low - допустим квартал.
2. Escape rate. Процент уязвимостей, обнаруженных после деплоя (через bug bounty, пентест, инцидент). Цель - снижение: если pipeline работает, escape rate падает.
3. False positive rate. Процент findings, закрытых как «не уязвимость». Выше 30% - правила сканера нуждаются в тюнинге. Выше 50% - команда перестанет доверять сканеру. Проверено.
4. Security gate pass rate. Процент MR, прошедших gate с первой попытки. 99% - gate слишком мягкий. 50% - правила слишком строгие или код систематически плохой.
5. DORA metrics в security-контексте. Deployment frequency и Lead time for changes не должны деградировать после внедрения security gates. Если деградируют - pipeline слишком медленный или gate блокирует слишком часто.

Подробнее о системе метрик, дашбордах и типичных ошибках в измерении - в гайде Метрики DevSecOps: от DORA до MTTR уязвимостей.

AI-генерация кода и новые вызовы для AppSec pipeline​

Vibe coding - генерация кода через AI-ассистенты (Copilot, Cursor, ChatGPT) - радикально ускоряет разработку и одновременно создаёт новый класс security-рисков. AI-модели обучены на public-репозиториях, включая код с уязвимостями, устаревшими паттернами и захардкоженными секретами.

Для AppSec pipeline это означает повышенную нагрузку: объём кода растёт, процент небезопасных паттернов в AI-генерированном коде выше, чем в написанном опытным разработчиком. SAST-правила, заточенные под типичные ошибки человека, не всегда ловят характерные для AI-генерации паттерны: избыточные зависимости, использование deprecated API, копирование уязвимых примеров из training data.

Адаптация pipeline под AI-генерированный код:

• Ужесточение SAST-правил для файлов с высокой долей AI-генерации (можно маркировать через git-метаданные)
• Обязательный SCA-скан при любом добавлении зависимости - AI-ассистенты часто предлагают пакеты с известными уязвимостями
• Дополнительные кастомные Semgrep-правила для типичных AI-паттернов: eval(), небезопасная десериализация, отсутствие input validation

Подробный разбор проблемы и конкретных CVE, связанных с AI-генерированным кодом - в материале Безопасность vibe coding: 74 CVE за три месяца.

Карьера в AppSec: путь от разработчика к security-инженеру​

AppSec-инженер - одна из самых востребованных ролей на стыке разработки и безопасности. Переход из разработки логичен: вы уже знаете код, стек, pipeline. Остаётся добавить security-экспертизу: OWASP Top 10, threat modeling, инструменты анализа, навык ручного code review на предмет уязвимостей.

Типичный путь: разработчик → security champion в команде → AppSec-инженер → DevSecOps-инженер / Application Security Lead.

Security champion - разработчик, который берёт на себя роль связующего звена между dev-командой и AppSec. Разбирает findings сканера, проводит security code review, участвует в threat modeling. Это не отдельная должность, а дополнительная ответственность внутри dev-команды. На практике - именно чемпионы становятся теми людьми, которые не дают security gates превратиться в «галочку для руководства».

Подробный план перехода с рекомендациями по обучению и сертификациям - в гайде Как перейти в AppSec из разработки: план на 2025.

Как не превратить DevSecOps в тормоз релизов​

Главный страх команд разработки - «безопасность замедлит delivery». Страх обоснованный: неграмотно внедрённый pipeline увеличивает время MR с минут до часов. Решение - инженерное, не организационное.

Параллельные стадии. SAST, SCA и secret scan не зависят друг от друга - запускайте параллельно. На GitLab CI это needs: [] для каждого job. На GitHub Actions - отдельные jobs в одном workflow.

Инкрементальное сканирование. Semgrep с флагом --baseline-commit проверяет только diff. SCA сравнивает текущий lockfile с предыдущим. DAST сканирует только изменённые endpoints через OpenAPI diff.

Кэширование. Базы уязвимостей NVD, правила Semgrep, Docker-слои - всё кэшируется между запусками. Trivy с --cache-dir сокращает время сканирования образа с минут до секунд.

Асинхронный DAST. Полный DAST-скан запускается после merge в main, не блокируя MR. Результаты приходят в Slack/Jira. Блокирующий DAST - только перед production-деплоем.

Целевые показатели: security-стадии pipeline добавляют не более 5 минут к общему времени сборки. Если больше - оптимизируйте. DORA-метрики (deployment frequency, lead time) не должны деградировать после внедрения security gates.

Синтез: куда движется AppSec в DevSecOps​

Три тренда определят ситуацию с AppSec в ближайший год.

Первый - AI-assisted triage. Сканеры начинают использовать LLM для автоматической классификации findings: определения эксплуатабельности, генерации рекомендаций по исправлению, приоритизации на основе контекста приложения. Это не заменяет инженера, но сокращает время triage в разы.

Второй - supply chain security как обязательное требование. SBOM становится стандартным артефактом релиза (аналог changelog). Регуляторы (ФСТЭК, ЦБ) двигаются к требованиям по контролю цепочки поставок, аналогичным US Executive Order 14028. ГОСТ 56939 и профили защиты ЦБ уже включают элементы контроля компонентов.

Третий - platform engineering для security. Вместо того чтобы каждая команда самостоятельно настраивала Semgrep + Trivy + Gitleaks, появляются internal developer platforms с «security as a service»: готовый pipeline-шаблон с предконфигурированными сканерами, gate-политиками и дашбордами. Задача AppSec-команды смещается от «настроить сканер» к «разработать платформу, которую dev-команды используют по умолчанию».

Что делать прямо сейчас: если у вас нет ни одного security gate в pipeline - начните с Gitleaks в pre-commit и Semgrep с OWASP ruleset в MR. Два инструмента, zero cost, 30 минут на настройку. Добавляйте SCA через неделю. DAST - через месяц. Не пытайтесь внедрить всё сразу: поэтапное наращивание с измерением метрик - единственный способ, который не вызывает отторжения у команд разработки.



Большинство команд, которые заявляют «у нас DevSecOps», на самом деле имеют SAST-сканер, результаты которого никто не читает. Инструмент куплен, стадия в pipeline добавлена, отчёт для руководства сформирован. А разработчик по-прежнему коммитит AWS-ключ в открытый репозиторий, потому что pre-commit hook «мешает работать» и его отключили в первую неделю.

Корень проблемы не технический - он организационный. AppSec в DevSecOps работает только когда security gate имеет реальные полномочия: блокирует merge request, останавливает pipeline, создаёт задачу с конкретным владельцем и сроком. Всё остальное - генерация PDF-отчётов для аудитора.

В реальных проектах я наблюдал одну и ту же динамику: команда внедряет 5 сканеров за месяц, тонет в 10 000 findings, разработчики объявляют бойкот, менеджмент «временно» переводит все gates в информационный режим, и через полгода про AppSec помнит только security-инженер, который грустно смотрит на дашборд в одиночестве.

Единственная стратегия, которая выживает при контакте с реальностью - начинать с одного инструмента и одного жёсткого правила. Не «давайте внедрим SAST + DAST + SCA + IAST + container scanning». А «с завтрашнего дня MR с hardcoded secret не мержится, без исключений». Одно правило, понятное всем, enforcement через pipeline. Когда команда привыкнет - добавьте второе. Через полгода у вас будет 10 работающих правил вместо 10 000 findings, на которые все забили. В AppSec побеждает не тот, у кого больше сканеров, а тот, у кого каждый finding приводит к конкретному действию.

Если хотите прогнать эту цепочку руками - на WAPT настройку security gates в GitLab CI и GitHub Actions разбирают в лабораторных с обратной связью от практикующих AppSec-инженеров.