Обучение DevSecOps: программа, инструменты и практика на реальном пайплайне

За последние два года я настроил DevSecOps-пайплайны для четырёх продуктовых команд. Картина каждый раз одна: первый SAST-прогон по существующей кодовой базе выдаёт от 200 до 1500 findings, и 10–30 из них — критические уязвимости, жившие в продакшене месяцами. Одна команда обнаружила захардкоженный API-ключ к платёжному шлюзу в публичном репозитории. Он там лежал восемь месяцев. Просто лежал.

Всё это — следствие отсутствия автоматических проверок безопасности в процессе разработки. Курсы DevSecOps существуют, чтобы эту ситуацию исправить, но не все программы одинаково полезны. Разберём, что должно входить в серьёзную программу обучения DevSecOps, какие инструменты осваивать и как выглядит реальная практика на CI/CD.

Что такое DevSecOps и зачем ему учиться

DevSecOps — подход, при котором безопасность встраивается в каждый этап разработки и доставки ПО, а не проверяется в самом конце, перед релизом. Если проще: в классической схеме разработчики пишут код, DevOps-инженеры настраивают CI/CD-пайплайн (автоматическую цепочку сборки, тестирования и деплоя), а команда безопасности проверяет результат уже на финише — когда исправления стоят дороже всего. В DevSecOps проверки безопасности автоматизируются и распределяются по всему пайплайну.

Ключевая идея — shift-left security (сдвиг безопасности «влево» по временной шкале разработки). Баг, пойманный на этапе pull request, — пять минут работы разработчика. Тот же баг в продакшене — инцидент, расследование и, возможно, утечка данных. В марте 2026 года колумбийская финтех-компания Addi допустила утечку 34,5 млн записей, включая кредитные рейтинги и государственные ID. Автоматизация безопасности в DevOps не даёт стопроцентной гарантии, но радикально снижает вероятность такого сценария.

Зачем учиться DevSecOps:

• Компании, перешедшие на частые релизы (CI/CD), физически не могут проверять безопасность вручную перед каждым деплоем. Вакансий инженера по безопасности разработки становится больше каждый год — рынок тянет.
• Разработчики этот gap не закрывают. Типичный backend-разработчик знает, что SQL-инъекции — плохо, но не умеет настроить Semgrep в пайплайне или написать политику OPA для Kubernetes.
• Без автоматизации команды безопасности раз за разом фиксируют те же классы уязвимостей: захардкоженные секреты, устаревшие зависимости, контейнеры с root-правами. Пентестеры устают писать одно и то же в отчётах.

Какие угрозы закрывает DevSecOps

Чтобы понять, зачем нужны конкретные инструменты в пайплайне, полезно посмотреть на угрозы через призму MITRE ATT&CK — открытой базы тактик и техник атак. Каждая техника там имеет свой идентификатор (T-код), и именно эти коды вы будете встречать в отчётах сканеров и в документации.

Каждая строка — реальный вектор атаки, который DevSecOps-инженер обязан закрыть автоматизированной проверкой. Программа курса DevSecOps, в которой нет привязки к конкретным техникам атак, учит нажимать кнопки, а не инженерии.

Программа курса DevSecOps: что входит в серьёзное обучение

Русскоязычные курсы DevSecOps (OTUS, Слёрм, IQData) покрывают схожий набор тем разной глубины. Но если разобрать их программы, видны модули, без которых обучение безопасной разработке неполноценно.

SAST и DAST — два подхода к поиску уязвимостей

SAST (Static Application Security Testing) — анализ исходного кода без его запуска. Инструмент читает код, строит абстрактное синтаксическое дерево и ищет паттерны уязвимостей: SQL-инъекции, XSS, path traversal. Примеры SAST DAST инструментов для статического анализа: Semgrep, SonarQube, Checkmarx.

DAST (Dynamic Application Security Testing) — анализ работающего приложения. Инструмент отправляет запросы к развёрнутому приложению и наблюдает за ответами, ища уязвимости в рантайме. Главный пример: OWASP ZAP.

Путаница между SAST и DAST — одна из первых точек ступора для тех, кто начинает разбираться в DevSecOps для начинающих. Правило простое: SAST смотрит на код (белый ящик) и работает до деплоя. DAST смотрит на приложение (чёрный ящик) и работает после деплоя в staging-окружении.

В серьёзном курсе DevSecOps с практикой оба подхода разбираются не абстрактно, а на реальном пайплайне: как подключить Semgrep к GitLab CI, как настроить ZAP для автоматического скана в staging. По данным Claranet (NotSoSecure DevSecOps Training), студенты не просто запускают сканеры, а пишут собственные правила для Semgrep и создают ZAP context files. Вот это отличает оператора от инженера.

Ещё две разновидности, которые часто встречаются в программах: IAST (Interactive AST — гибрид, работает внутри приложения через агент) и SCA (Software Composition Analysis — анализ зависимостей, о нём ниже). Если курс останавливается только на SAST/DAST — это обзор, а не полноценная программа.

SCA и контроль зависимостей

SCA (Software Composition Analysis) — проверка сторонних библиотек на известные уязвимости. По классификации OWASP Top 10 (2021), категория A06 — Vulnerable and Outdated Components (использование компонентов с известными уязвимостями) — входит в десятку критических рисков веб-приложений.

На практике: проект может быть идеально написан, но одна устаревшая библиотека с CVE ломает всю безопасность. SCA-инструменты (Dependency-Check, Trivy, Snyk) автоматически сканируют package.json, requirements.txt, pom.xml и сообщают об уязвимых версиях.

По MITRE ATT&CK это техника T1195.001 — компрометация через зависимости и инструменты разработки. Атаки на цепочку поставок через npm-пакеты, когда вредоносный код внедряется в популярную библиотеку, — реальность, а не теория. Категория A08:2021 из OWASP Top 10 — Software and Data Integrity Failures — описывает ситуации, когда обновления ПО устанавливаются без проверки подписей, а CI/CD-пайплайн сам становится вектором атаки.

Безопасность контейнеров и Kubernetes

Контейнеры (Docker) и оркестрация (Kubernetes, далее K8s) — стандарт современной разработки. Контейнер, собранный из непроверенного базового образа или запущенный с root-привилегиями, — открытая дверь для атакующего.

Техники T1610 (Deploy Container — развёртывание контейнера для выполнения вредоносного кода), T1611 (Escape to Host — побег на хост-систему) и T1613 (Container and Resource Discovery — разведка ресурсов кластера) показывают: K8s — полноценная поверхность атаки, а не просто инфраструктурная платформа.

Курсы по внедрению DevSecOps обязаны включать:

• Сканирование Docker-образов на уязвимости (Trivy, Grype)
• Проверку Dockerfile на небезопасные паттерны: запуск от root, отсутствие USER, отсутствие мультистейдж-сборки
• Политики допуска в Kubernetes через OPA/Gatekeeper или Kyverno — механизмы, которые запрещают деплой контейнеров, не соответствующих политикам безопасности
• Hardening кластера по Kubernetes STIG (Security Technical Implementation Guide — стандарт DoD для безопасной конфигурации)

OTUS в своей программе выделяет отдельный модуль на Docker и K8s с домашними заданиями по безопасности контейнеров. IQData идёт дальше и включает фаззинг-тестирование — метод поиска уязвимостей через подачу случайных данных на вход программы.

DevSecOps практика: собираем минимальный пайплайн

Теория без практики не работает — и это главная претензия к большинству курсов DevSecOps онлайн. Ниже — минимальный пайплайн, который покрывает четыре класса проверок. Цель: после этих шагов у вас будет рабочая цепочка, блокирующая небезопасный код от попадания в репозиторий и в продакшен.

Требования к окружению:

• ОС: Ubuntu 22.04+ / macOS 13+ / Windows с WSL2
• RAM: минимум 8 ГБ, рекомендуется 16 ГБ (Docker + сканеры потребляют память)
• Установленные инструменты: Docker 24+, Git 2.40+, Python 3.10+
• Доступ в интернет (Trivy загружает базу CVE при первом запуске)
• Для шага 4 нужен аккаунт в GitLab или локальный GitLab Runner

Шаг 1. Pre-commit hook — ловим секреты до коммита. Задача — не допустить попадания паролей, API-ключей и токенов в репозиторий. Talisman проверяет каждый коммит перед отправкой. Установка глобально: curl --silent https://raw.githubusercontent.com/thoughtworks/talisman/main/global_install_scripts/install.bash | bash. Примечание: пайпинг curl в bash — небезопасная практика (см. A08:2021). В продакшен-окружении лучше сначала скачать скрипт, проверить содержимое и контрольную сумму, либо поставить через пакетный менеджер (brew install talisman). Проверка: создайте файл config.py с содержимым password = "SuperSecret123" и выполните git add . && git commit -m "test". Talisman должен заблокировать коммит с сообщением Potential secret detected. Если коммит прошёл — проверьте, что hook установлен (ls .git/hooks/pre-commit).

Шаг 2. SAST — статический анализ кода. Запустите Semgrep, чтобы найти уязвимые паттерны в исходном коде. Команда semgrep --config=auto . подберёт набор правил под языки в проекте. Учтите: --config=auto может потребовать авторизации (semgrep login); как альтернативу, не зависящую от облачного аккаунта, используйте --config=p/ci. Ожидаемый вывод — список findings с указанием файла, номера строки и CWE-идентификатора (CWE — классификатор типов уязвимостей; например, CWE-89 для SQL-инъекций). Если findings нет — попробуйте на заведомо уязвимом проекте, например OWASP WebGoat или DVWA.

Шаг 3. SCA — проверяем зависимости. Trivy сканирует не только контейнеры, но и lock-файлы. Команда trivy fs --scanners vuln . проверит зависимости в текущей директории. В выводе будут CVE-идентификаторы, severity (CRITICAL/HIGH/MEDIUM/LOW) и рекомендация по обновлению. Если вывод пуст — либо зависимостей нет, либо отсутствует lock-файл (package-lock.json, poetry.lock).

Шаг 4. Container scan — проверяем Docker-образ перед деплоем. Команда trivy image your-app:latest покажет уязвимости в ОС-пакетах и библиотеках внутри образа. Критерий прохождения: 0 CRITICAL, 0 HIGH.

Все четыре шага объединяются в CI/CD-конфигурацию. Минимальный пример для GitLab CI:

stages:
  - security

sast:
  stage: security
  image: returntocorp/semgrep
  script:
    - semgrep --config=auto --error .

container_scan:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Флаг --error у Semgrep и --exit-code 1 у Trivy означают: при обнаружении проблем пайплайн падает, merge request не проходит. Это и есть security gate — точка, которая блокирует небезопасный код автоматически. Без этого флага сканеры превращаются в декорацию: отчёт есть, а толку нет.

Курсы DevSecOps: как выбрать формат обучения

На рынке три основных формата обучения DevSecOps, и каждый подходит для разной ситуации.

Конкретные цены зависят от провайдера и формата (живые вебинары дороже записей). OTUS предлагает 5-месячный курс с проектной защитой. Слёрм проводит интенсив-бутакемп с виртуальными стендами. Среди EN-провайдеров Claranet (NotSoSecure) выдаёт каждому студенту персональное облачное окружение и после курса отдаёт VM со всеми инструментами и скриптами — забираешь и работаешь. AppSecEngineer делает акцент на «Threat Models as Code» — автоматизацию моделирования угроз. Перед оплатой уточняйте актуальную цену на сайте провайдера — рынок меняется быстро.

Что отличает слабый курс от сильного

Слабый курс покажет слайд с названиями инструментов. Сильный — заставит написать собственное правило Semgrep, настроить пайплайн, сломать его и починить.

На что смотреть при выборе курса DevSecOps онлайн:

• Лабораторные стенды. Есть ли реальное CI/CD-окружение для практики, или всё на скриншотах? Claranet, OTUS и AppSecEngineer дают облачные лабы — это маркер серьёзной программы.
• Проектная работа. Итоговый проект с внедрением DevSecOps в реальный или учебный проект. OTUS, например, требует защиту проекта перед преподавателем.
• Стек SAST DAST инструментов. Минимальный набор: один SAST (Semgrep или SonarQube), один DAST (OWASP ZAP), один SCA (Trivy или Dependency-Check), контейнерная безопасность (Trivy/Grype) и секреты (HashiCorp Vault или Talisman). Если в программе меньше — это обзорная лекция, а не курс.
• Дата обновления материалов. Курс, записанный два года назад, может использовать устаревшие версии инструментов и API. Спрашивайте у провайдера, когда обновлялась практическая часть. Если не могут ответить — это ответ.
• Привязка к OWASP DSOMM. DSOMM (DevSecOps Maturity Model) — модель зрелости DevSecOps от OWASP с категориями Build, Patch, Test, Information Gathering и Culture. Если курс не упоминает зрелость процессов — он учит кнопкам, а не выстраиванию системы.

Сертификация DevSecOps

На международном рынке есть специализированные сертификации: Practical DevSecOps (CDP — Certified DevSecOps Professional), Linux Foundation (LFS262 — Implementing DevSecOps). TryHackMe предлагает учебный трек DevSecOps, сфокусированный на защите пайплайнов и безопасности IaC (Infrastructure as Code — инфраструктура, описанная кодом: Terraform, Ansible).

В России отдельной сертификации «DevSecOps-инженер» пока нет, но программы обучения с итоговым проектом и свидетельством о повышении квалификации (как у OTUS) формально закрывают запрос работодателя на подтверждение компетенций. Для корпоративного рынка значение имеет не логотип сертификата, а портфолио решённых задач: настроенный пайплайн, написанные политики, метрики снижения findings. Покажите работодателю дашборд, где findings упали с 300 до 15 за квартал — это убедительнее любого диплома.

Обучение DevSecOps с нуля: карьера и рынок

DevSecOps-инженер — роль на стыке разработки, инфраструктуры и безопасности. Типичные задачи в вакансиях 2025–2026 годов:

• Настройка и поддержка SAST/DAST/SCA в CI/CD-пайплайне
• Автоматизация безопасности в DevOps: проверки контейнеров, IaC (Terraform, Ansible), секреты
• Внедрение политик безопасности через OPA/Kyverno в Kubernetes
• Разработка security gates — точек, блокирующих небезопасный код
• Обучение разработчиков: программа Security Champions (выделенные сотрудники в продуктовых командах, которые отвечают за безопасность на уровне своей кодовой базы)

Входные требования

Для входа в DevSecOps нужна база, без которой обучение DevSecOps с нуля превращается в попытку строить дом без фундамента:

• Linux: работа в терминале, права доступа (chmod/chown), базовые сетевые утилиты (curl, netstat)
• Git: ветвление, merge request, hooks — без этого pre-commit проверки непонятны
• CI/CD: хотя бы один инструмент на практике (GitLab CI, Jenkins, GitHub Actions)
• Docker: сборка образов, docker-compose, volumes, сети
• Базовое понимание уязвимостей: OWASP Top 10 (что такое инъекция, XSS, CSRF) — хотя бы на уровне «могу объяснить за три минуты»

Если этих знаний пока нет — начинать с DevSecOps рано. Сначала стоит закрыть базу по информационной безопасности и основам DevOps, иначе инструменты будут работать «на вас», а не «для вас».

Корпоративная оплата обучения

Многие компании компенсируют обучение сотрудников — полностью или частично. Как это работает:

1. Внутренний бюджет на развитие. В крупных компаниях (банки, телеком, IT-продукт) есть годовой бюджет на обучение: обычно от 50 до 200 тыс. руб. на сотрудника. Уточните у HR или руководителя.
2. Обоснование. Аргумент «хочу учиться» работает хуже, чем «после курса я закрою задачу X из бэклога: внедрение SAST в пайплайн, аудит контейнерной безопасности, снижение критических findings на 70%». Привяжите обучение к бизнес-задаче — так шансы на одобрение вырастают кратно.
3. Формат оплаты. Компании предпочитают договор с юрлицом, акт и счёт-фактуру. Перед записью уточните у провайдера курса, есть ли такая опция.
4. Налоговый вычет. Для физлиц расходы на обучение можно учесть в социальном вычете — до 120 000 руб. в год.

Зрелость DevSecOps: как оценить прогресс

OWASP DSOMM определяет пять категорий зрелости: Build, Patch, Test, Information Gathering и Culture. Внедрение DevSecOps — не разовое действие, а процесс. Серьёзный курс по внедрению DevSecOps учит не только подключать инструменты, но и оценивать текущий уровень зрелости и строить дорожную карту.

На практике уровни зрелости выглядят так:

• Уровень 1: SAST/DAST запускаются вручную, результаты просматриваются эпизодически. Нет единого стандарта, каждая команда делает по-своему. Знакомо?
• Уровень 2: Инструменты интегрированы в пайплайн, но findings не блокируют деплой. Отчёты генерируются, но никто не несёт ответственности за их разбор. Самый опасный уровень — создаёт иллюзию безопасности.
• Уровень 3: Security gates настроены: critical/high findings блокируют merge. Метрики собираются (MTTR — среднее время исправления уязвимости, количество findings по severity). На этом уровне CI/CD безопасность начинает реально работать.
• Уровень 4: Security Champions в каждой команде, threat modeling перед новой функциональностью, автоматическая отчётность, культура «безопасность — ответственность каждого».

Большинство организаций сидят на уровне 1–2. Задача DevSecOps-инженера — методично переводить процесс на уровень 3 и выше. Категория A09:2021 из OWASP Top 10 — Security Logging and Monitoring Failures — напоминает: без логирования и мониторинга обнаружить инцидент невозможно. Для DevSecOps это означает, что результаты каждого скана должны логироваться, критические findings — генерировать алерты, а метрики — визуализироваться в дашборде.

Именно навык выстраивания процесса отличает DevSecOps-инженера от человека, который умеет запускать trivy image. И именно этот навык нужно искать в программе обучения.

Если смотреть на рынок курсов DevSecOps честно, большинство из них учат запускать сканеры и читать отчёты. Запустил Semgrep, получил список findings, поставил галочку. Но реальная работа начинается после отчёта: как приоритизировать 500 findings, когда разработчики говорят «у нас дедлайн через два дня»? Как объяснить продакт-менеджеру, что релиз нужно отложить из-за уязвимости в транзитивной зависимости третьего уровня? Как написать политику Kyverno, которая не сломает деплой легитимных сервисов?

Этому учатся только через практику на стендах, приближённых к продакшену, с обратной связью от человека, который сам через это проходил. Я убеждён, что через два-три года DevSecOps перестанет быть отдельной ролью и станет обязательным навыком любого DevOps-инженера — как знание Git стало обязательным для разработчиков. Те, кто осваивает shift-left security сейчас, не гонятся за модным словом — они закрывают разрыв, который рынок уже не может игнорировать. Если базы по ИБ и DevOps ещё нет — на IB Basics эта основа закрывается за пару месяцев, без академического тона и лишней воды.