Собеседование DevSecOps: что спрашивают и почему ответ про сканер без контекста пайплайна проваливает интервью

За последний год я провёл около сорока технических интервью на позицию DevSecOps-инженера. Паттерн один и тот же: три четверти кандидатов на вопрос «как обеспечите безопасность пайплайна» начинают с «добавлю Trivy в security-stage». Окей. Следующий вопрос: «Сборка упала на Critical CVE в зависимости, которую используют три микросервиса с разным SLA на фикс. Что делаете?» Тишина. Разрыв между «знаю название тулзы» и «понимаю, как встроить безопасность без остановки деплоя» — ровно то, что отделяет оффер от вежливого «мы вам перезвоним». Ниже — конкретные вопросы, которые задают на собеседовании DevSecOps, с разбором сильных и слабых ответов.

Почему ответ «поставлю сканер в CI» проваливает интервью DevSecOps

Сканер уязвимостей в CI/CD (Continuous Integration / Continuous Deployment — конвейер сборки и доставки кода) — инструмент, не решение. Когда кандидат на собеседовании DevSecOps отвечает «добавлю SAST/DAST в пайплайн», интервьюер слышит: «я умею написать stage в .gitlab-ci.yml, но не понимаю, что произойдёт дальше».

А дальше происходит вот что:

• Первый запуск выплёвывает сотни находок. Разработчики получают стену алертов и через неделю игнорируют security-stage целиком. Я видел это на трёх проектах подряд — один в один.
• Сканер блокирует сборку на Critical, но критичность определена по голому CVSS (Common Vulnerability Scoring System — числовая шкала серьёзности уязвимости от 0 до 10) без контекста. Библиотека с CVSS 9.8 используется в тестовой утилите без сетевого доступа, а деплой критического бизнес-фикса стоит, потому что --exit-code 1 не различает окружения.
• Никто не определил политику: порог срабатывания, SLA на исправление, маршрут находок в трекер. Сканер крутится, но не встроен в процесс управления уязвимостями.

Интервьюер хочет услышать архитектурное решение: как сканер вписывается в пайплайн, кто и когда работает с результатами, что происходит с находками разной критичности и как вы не парализуете delivery, обеспечив безопасность. Вот это отличие DevOps-инженера, который добавил security-stage, от DevSecOps-инженера, который выстроил процесс.

Что на самом деле оценивают на собеседовании DevSecOps-инженера

На интервью проверяют не инвентарь инструментов из резюме. Три уровня, по которым интервьюер калибрует кандидата.

Уровень 1: инструментальный

Кандидат знает, что SAST (Static Application Security Testing — анализ исходного кода на уязвимости без его запуска) сканирует код, DAST (Dynamic Application Security Testing — тестирование работающего приложения «снаружи», как чёрный ящик) проверяет runtime, а SCA (Software Composition Analysis — анализ сторонних библиотек на известные уязвимости) ищет уязвимые зависимости. Может назвать Semgrep, Trivy, OWASP ZAP. Для стажёра хватит. Для DevSecOps-позиции — нет.

Уровень 2: процессный

Кандидат объясняет, когда и где в пайплайне работает каждый тип сканирования, как настроена политика допуска сборки (quality gate), какие находки блокируют деплой, а какие уходят в трекер с SLA. Знает, что SAST стоит на этапе build, DAST — на staging, а SCA запускается и при коммите, и в пайплайне.

Уровень 3: архитектурный

Кандидат рассуждает о компромиссах. Как выбрать порог блокировки, чтобы не остановить delivery, но поймать критичное. Как организовать исключения (suppress/allowlist) без потери контроля. Как измерять эффективность security-гейтов метриками: MTTR уязвимостей (среднее время от обнаружения до фикса), escape rate (процент уязвимостей, дошедших до прода), false positive rate. Как вписать всё это в культуру команды, а не навязать приказом сверху.

Middle и senior интервью целиком проходят на уровне 2–3. Скатывание к перечислению тулзов — красный флаг.

Вопросы на собеседовании DevSecOps по безопасности пайплайна

«Как вы реализуете безопасность в CI/CD-пайплайне?»

Самый частый и самый показательный вопрос на собеседовании DevSecOps-инженера.

Слабый ответ: «Добавлю стейджи с Trivy для контейнеров, Semgrep для кода и OWASP Dependency-Check для зависимостей. Если Critical — сборка падает.»

Почему слабый: описан набор инструментов, но не процесс. Непонятно, кто разбирает находку, как отличить true positive от шума и что делать с hotfix-ом в пятницу вечером.

Сильный ответ: «Безопасность пайплайна строю уровнями. На commit — pre-commit hooks: проверка секретов через gitleaks, линтинг IaC (Infrastructure as Code — описание инфраструктуры кодом: Terraform, Helm-чарты, Kubernetes-манифесты) через checkov. На build — SAST через Semgrep с кастомными правилами под стек проекта, SCA через trivy fs для зависимостей. На staging — DAST через OWASP ZAP в headless-режиме. Политика: Critical и High с подтверждённым эксплойтом блокируют MR, остальное уходит задачей с SLA 14 дней. Для false positives — файл .semgrepignore с обязательным ревью от security-чемпиона. Метрики — MTTR по severity, процент подавленных находок, тренд новых уязвимостей по спринтам.»

Разница: сильный ответ показывает процесс. Интервьюер видит, что кандидат уже сталкивался с реальными проблемами — false positives, блокировка delivery, alert fatigue — и выработал рабочие компромиссы.

«Что такое Shift Left Security и как вы это реализуете на практике?»

Shift Left (сдвиг безопасности на ранние этапы — чем раньше нашли уязвимость, тем дешевле исправить) — термин, который знают все и реализуют единицы.

Слабый ответ: «Shift Left — это интеграция безопасности на ранних этапах SDLC. Добавляем SAST в CI.»

Сильный ответ: «Shift Left — перенос security-решений туда, где фикс дешевле всего. По данным IBM, исправление уязвимости на этапе разработки стоит условно $100, при тестировании — $1500, в проде — $7500. Конкретно: в IDE — плагин Semgrep или SonarLint для мгновенного фидбека. На pre-commit — обязательная проверка секретов и IaC-линтинг. В CI — SAST + SCA с graduated policy: для feature-веток — предупреждения, для MR в main — блокировка на Critical. Параллельно — разборы реальных находок из кода команды на ретро по 15 минут, не формальный курс на 40 часов. Shift Left работает, когда разработчик чинит уязвимость до того, как она попала в merge request.»

«Пайплайн нашёл Critical CVE в зависимости. Ваши действия?»

Вопрос проверяет принятие решений под давлением — ключевая DevSecOps-компетенция.

Слабый ответ: «Останавливаю деплой, обновляю зависимость, перезапускаю пайплайн.»

Сильный ответ: «Зависит от контекста. Первый шаг — оценить реальную эксплуатабельность: есть ли публичный эксплойт, включена ли CVE в каталог CISA KEV (список уязвимостей, которые УЖЕ эксплуатируются в реальных атаках), какой EPSS (оценка вероятности от 0 до 1, что уязвимость начнут эксплуатировать в ближайшие 30 дней). Затем — контекст использования: зависимость вызывается в runtime или только в тестах? Доступна ли уязвимая функция из внешней сети? Если зависимость критична и эксплойт публичный — блокирую MR, эскалирую обновление. Если зависимость тестовая или уязвимая функция не вызывается — задача с SLA, компенсирующий контроль (WAF-правило), деплой с approve от security-инженера. Автоблокировка по голому CVSS без контекста приводит к тому, что через месяц команда заменит --exit-code 1 на --exit-code 0 и сканер станет декорацией.»

По данным IBM X-Force Threat Intelligence Index, среднее время между публикацией CVE и устранением в организации — 29 месяцев. Кандидат, который понимает этот разрыв и предлагает приоритизацию вместо «чиним всё сразу», сразу выделяется.

SAST и DAST: вопросы на собеседовании, которые отсеивают

«В чём разница между SAST и DAST и когда что использовать?»

Выглядит базовым, но проверяет глубину понимания.

Сильный ответ включает не определения, а операционные отличия:

Для полной картины нужны оба плюс SCA для зависимостей и IaC-сканирование для инфраструктурного кода. По рекомендациям OWASP DSOMM (DevSecOps Maturity Model — модель зрелости DevSecOps с категориями Build, Test, Patch, Culture) начинать стоит с SCA: наименьший false positive rate и максимальный эффект — уязвимые зависимости остаются одним из ведущих векторов атак.

«Какие метрики вы используете для оценки эффективности DevSecOps?»

Вопрос для middle/senior. Кандидаты без реального опыта с метриками видны сразу.

Метрики, которые стоит назвать:

• MTTR по severity — среднее время от обнаружения до фикса, разбитое по критичности. Если Critical MTTR больше 7 дней — процесс не работает.
• Escape rate — процент уязвимостей, дошедших до прода. Главный индикатор эффективности всех гейтов.
• False positive rate — если выше 30%, разработчики перестают доверять сканеру. Проверено на практике: после этого порога команда просто перестаёт читать отчёты.
• Тренд сборок с security-нарушениями — динамика важнее абсолютного числа.
• Coverage — процент репозиториев и сервисов, реально охваченных сканированием. Почти никогда не 100%, и честный ответ «у нас 70%, но мы знаем, какие 30% не покрыты» звучит сильнее, чем «всё покрыто».

Секреты и supply chain: вопросы на собеседовании DevSecOps-инженера

«Как вы организуете управление секретами в пайплайне?»

Secrets management (хранение и ротация паролей, токенов, API-ключей) — одна из самых практических тем.

Красные флаги в ответе: «Храним в переменных CI/CD» без уточнений. «Используем .env файл» — в 2026 году это провал. Хранение секретов в файлах — прямой путь к технике Credentials In Files (T1552.001 по классификации MITRE ATT&CK — открытой базе тактик и техник атак; T-коды вроде T1552.001 — её идентификаторы, где число до точки — техника, после — подтехника).

Сильный ответ: «Секреты живут в специализированном хранилище — HashiCorp Vault или встроенные механизмы облака (AWS Secrets Manager, Azure Key Vault). Пайплайн получает секреты через short-lived токены, не через переменные окружения с бессрочным доступом. Pre-commit hook с gitleaks не даёт закоммитить секрет случайно. В CI — дополнительная проверка trufflehog по истории коммитов. Ротация автоматизирована: API-ключи обновляются каждые 90 дней без ручного участия.»

«Что вы знаете о supply chain атаках на CI/CD?»

Supply chain security (безопасность цепочки поставок ПО) — обязательная тема после крупных инцидентов последних лет. В MITRE ATT&CK этому посвящена группа техник: Supply Chain Compromise (T1195), включая Compromise Software Dependencies and Development Tools (T1195.001) и Compromise Software Supply Chain (T1195.002). Отдельно стоит Poisoned Pipeline Execution (T1677) — атакующий модифицирует конфигурацию пайплайна, чтобы запустить вредоносный код.

Что интервьюер хочет услышать:

• Векторы: dependency confusion (подмена пакета через публичный реестр), typosquatting (пакет с похожим именем), компрометация CI/CD-конфигурации. Случай с event-stream в npm — классический пример: мейнтейнер передал пакет незнакомцу, тот добавил вредоносный код.
• Контрмеры: lock-файлы (package-lock.json, Pipfile.lock) с фиксацией хэшей, приватный registry как прокси с фильтрацией, подпись артефактов через cosign/sigstore, генерация SBOM (Software Bill of Materials — машиночитаемый список всех компонентов сборки).
• Мониторинг: алерт на добавление новой зависимости через SCA, ревью Dockerfile и CI-конфигурации как security-sensitive кода.

Как подготовиться к собеседованию DevSecOps: делай раз, делай два, делай три

Практический блок. Каждый шаг укладывается в один-два вечера.

Шаг 1: соберите минимальный пайплайн с security-гейтами.

Что нужно: аккаунт на gitlab.com (бесплатный) или GitHub. Базовое понимание YAML.

Создайте репозиторий с простым приложением (Flask, Express, Spring Boot — что ближе). Добавьте конфигурацию пайплайна с тремя проверками: SCA через trivy fs, SAST через semgrep scan --config auto, поиск секретов через gitleaks detect. На старте ставьте allow_failure: true — сканер работает в наблюдательном режиме. Ожидаемый результат: пайплайн завершается, вы видите отчёт с находками или пустой вывод. Если находки есть — попробуйте настроить исключения и разделить по severity.

# Минимальный security pipeline для GitLab CI
# Предпосылки: проект с зависимостями (requirements.txt / package.json)
stages:
  - security

sca-scan:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
  allow_failure: true  # Наблюдательный режим на старте

sast-scan:
  stage: security
  image: returntocorp/semgrep
  script:
    - semgrep scan --config auto --error
  allow_failure: true

Через пару недель, когда разберёте основные false positives — переключайте на allow_failure: false для Critical.

Шаг 2: свяжите OWASP Top 10 с этапами пайплайна.

OWASP Top 10 — десятка наиболее критичных рисков веб-приложений. Возьмите каждую категорию и ответьте: какой инструмент на каком этапе пайплайна её поймает?

• A03:2021 Injection (SQL, NoSQL-инъекции) — SAST ловит паттерны при сборке, DAST проверяет на staging.
• A05:2021 Security Misconfiguration (небезопасные конфигурации) — IaC-сканирование через checkov при коммите.
• A06:2021 Vulnerable and Outdated Components (уязвимые зависимости) — SCA через trivy или snyk при каждой сборке.

Это упражнение формирует связку «риск → контроль → место в пайплайне», которая нужна в любом ответе на интервью. Попробуйте пройтись по всем десяти категориям — пробелы покажут, где нужно подтянуть теорию.

Шаг 3: подготовьте три истории из своего опыта.

Даже если вы переходите из чистого DevOps или разработки — у вас были ситуации, связанные с безопасностью: обновление уязвимой библиотеки, настройка доступов, разбор инцидента. Оформите каждую по STAR (Situation — Task — Action — Result): что случилось, какая стояла задача, что вы сделали, какой результат получили. Три готовых истории закрывают большинство поведенческих вопросов.

Контейнерная безопасность и IaC: дополнительные вопросы DevSecOps-интервью

«Как вы обеспечиваете безопасность Docker-образов?»

Ответ, который ждут — не «сканирую Trivy», а полный цикл:

• Минимальный базовый образ: distroless или alpine вместо ubuntu:latest. Меньше пакетов — меньше поверхность атаки.
• Multi-stage build: сборочные зависимости не попадают в финальный образ.
• Непривилегированный пользователь: директива USER с конкретным UID вместо root.
• Сканирование: trivy image --severity CRITICAL,HIGH <image> в CI перед пушем в registry.
• Подпись: cosign sign — гарантия, что в registry лежит именно тот образ, который прошёл все проверки.
• Admission control: OPA Gatekeeper или Kyverno в Kubernetes не пропускают образы без подписи или с Critical CVE.

Всё это перекликается с требованиями Kubernetes STIG (Security Technical Implementation Guide — руководство по безопасной конфигурации от DoD): контроль образов, запрет привилегированных контейнеров, ограничение capabilities.

«Как вы сканируете Infrastructure as Code?»

IaC-сканирование — проверка Terraform-файлов, Helm-чартов, Kubernetes-манифестов на небезопасные конфигурации до их применения к инфраструктуре. Инструменты: checkov, tfsec, kics.

Что ловит IaC-сканер: S3-бакет с публичным доступом, Security Group с 0.0.0.0/0 на порту 22, Kubernetes Pod без resource limits. Всё это — категория A05:2021 Security Misconfiguration из OWASP Top 10.

Запускать нужно максимально рано — в pre-commit или при создании MR. Чинить конфигурацию в pull request дешевле, чем пересоздавать развёрнутую инфраструктуру. Я как-то видел, как Security Group с открытым 22 портом на весь мир продержалась в проде три месяца — checkov на pre-commit поймал бы это за секунду.

Из сорока проведённых интервью я вынес одно наблюдение: кандидатов проваливает не отсутствие знаний. Semgrep, Trivy, ZAP — все их знают, все могут запустить. Проваливает неспособность ответить на вопрос «а что дальше?». Дальше — это когда сканер нашёл 400 находок и нужно решить, какие десять блокируют релиз, а какие 390 идут в бэклог с SLA. Когда разработчик просит suppress на Critical и нужно аргументировать, почему «да» или почему «нет». Когда менеджер спрашивает «security замедляет релизы?» и нужно показать метрики, а не говорить «безопасность важна».

DevSecOps-компетенция — не список инструментов в CI-конфиге. Это умение принимать решения о допустимом риске в конкретном контексте пайплайна и бизнеса. Инструмент можно выучить за вечер. Контекст набирается месяцами практики, и именно его проверяют на интервью. Если фундамент в ИБ ещё шаткий — IB Basics на codeby.school закрывает базу за пару месяцев без академической воды, дальше проще собирать DevSecOps-стек на прочном основании.