Вопросы на собеседовании: DevSecOps-инженер

В распространённой модели DevSecOps-инженер поддерживает общие защитные механизмы процесса доставки, но точное распределение ответственности зависит от организации.

• Роль часто интегрирует и применяет согласованные контроли для CI/CD-процессов, доступа раннеров, секретов, проверок зависимостей и целостности артефактов.
• Разработчики продукта отвечают за исправления кода, а AppSec или другая security-команда может владеть правилами сканеров и решениями о риске.
• Junior обычно поддерживает ограниченный workflow или интеграцию сканера под ревью, а не определяет правила для всей компании.

DevOps сосредоточен на надёжной доставке, а DevSecOps явно отвечает за встроенные в неё механизмы безопасности.

• Задача DevOps может заключаться в ускорении и повторяемости деплоя через GitLab CI.
• Задача DevSecOps ограничивает job token, сканирует артефакт и проверяет согласование перед этим деплоем.
• Роли пересекаются в механике пайплайнов, но для DevSecOps снижение рисков безопасности является обязательным результатом.

DevSecOps часто сосредоточен на общих контролях доставки, а Application Security напрямую работает с рисками в дизайне и коде продукта.

• AppSec может владеть моделями угроз, рекомендациями по коду, платформами сканирования или правилами этих сканеров.
• DevSecOps может интегрировать результаты сканеров в GitHub Actions или GitLab CI, поддерживать надёжность проверок и применять контроли, согласованные с AppSec и командами доставки.
• Разработчики исправляют затронутый код, а каждая организация должна явно определить владельцев инструментов, политик и исправлений.

DevSecOps сосредоточен на пути доставки ПО, а инженер по облачной безопасности защищает облачные аккаунты, сервисы и конфигурации.

• Инженер по облачной безопасности может определять сетевые границы или общие правила доступа в облаке.
• DevSecOps-инженер ограничивает учётные данные пайплайна и проверяет контейнер перед деплоем в облако.
• Для безопасной интеграции DevSecOps нужны знания облака, но повседневное администрирование облачного IAM не составляет всю роль.

Безопасный SDLC размещает подходящие проверки и доказательства безопасности на этапах планирования, сборки, тестирования и выпуска.

• Изменения исходного кода проходят ревью и автоматические проверки до попадания в защищённую ветку.
• При сборке сканируются зависимости и секреты, а результаты сохраняются вместе с точным артефактом.
• Контроли выпуска проверяют согласования и идентичность артефакта, а не предполагают, что предыдущий этап наверняка прошёл.

Shift-left означает более раннюю полезную обратную связь по безопасности, а не перенос всей ответственности на разработчиков.

• SCA-проверка в pull request может найти уязвимую зависимость до её попадания в основную ветку.
• Ранние проверки должны быть быстрыми и понятными, а более медленный DAST всё ещё может запускаться на развёрнутом тестовом окружении.
• Контроли в runtime и проверка выпуска остаются нужны, потому что проверки исходного кода не доказывают безопасность продакшена.

Защитный механизм автоматически меняет путь доставки, а отчёт лишь сообщает человеку о наличии риска.

• Правило GitHub Actions, отклоняющее сторонний action без фиксации по хешу, не даёт смержить рискованное изменение.
• OpenSSF Scorecard может найти рискованные практики в репозитории, но становится защитным механизмом только при использовании результата чётким правилом.
• Хороший механизм объясняет причину отказа и способ исправления, чтобы команды не обходили его из-за непонимания.

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

• Типичные задачи включают обновление job с Trivy, разбор результатов сканирования или сокращение прав в одном CI-шаблоне.
• Изменения нужно проверять на тестовом репозитории и отправлять на ревью до превращения в обязательный гейт.
• Неясные исключения, сломанные релизы и запросы на более широкие права нужно эскалировать, а не решать догадками.

Граница доверия возникает там, где код или данные переходят между компонентами с разным уровнем контроля.

• Pull request из форка менее надёжен, чем уже проверенный код в защищённой ветке.
• Раннер с токеном деплоя переходит от логики сборки к привилегированному доступу к инфраструктуре.
• На каждом переходе нужны явная аутентификация, минимальные права и проверка входных данных или артефакта.

В GitLab CI есть явные стадии, а в GitHub Actions нет примитива stage и порядок jobs задаётся через needs.

• Jobs GitLab назначаются стадиям, последующие стадии обычно ждут предыдущие, а jobs одной стадии могут выполняться параллельно.
• В GitHub Actions jobs без зависимостей могут выполняться параллельно, а needs указывает, от каких успешно завершённых jobs зависит следующий job.
• В обеих системах разделение сканирования, сборки и деплоя по jobs упрощает проверку учётных данных, результатов и условий отказа.

Разные jobs уменьшают объём недоверенного кода и чувствительных данных в одном контексте выполнения.

• Job для pull request не должен получать секрет для деплоя в продакшен.
• Job подписи может принимать digest, а не повторно собирать или выполнять код репозитория.
• Права на уровне job явно показывают, какой этап может записывать пакеты, запрашивать OIDC-токены или выполнять деплой.

CI-артефакты пересекают границы jobs и времени, поэтому нужно контролировать их источник, содержимое и срок хранения.

• Следующий job не должен доверять артефакту из недоверенного workflow без проверки источника и целостности.
• Логи, отчёты тестов и архивы могут случайно содержать токены или закрытые файлы исходного кода.
• Короткое хранение, ограничение скачивания и digest, связанный со сборкой, снижают риск утечки и подмены.

Облачные раннеры обычно одноразовые и управляются провайдером, а собственные дают больше контроля, но сохраняют больше рисков.

• Новый GitHub-hosted runner ограничивает сохранение данных между jobs и сокращает работу по очистке.
• Self-hosted runner может открыть внутреннюю сеть, закешированные учётные данные или файлы от предыдущего job.
• Недоверенные pull requests нельзя запускать на привилегированном self-hosted runner без сильной изоляции.

Pull requests из форков содержат код под контролем внешнего автора, который может попытаться прочитать секреты или изменить workflow.

• Обычные jobs для pull request должны работать только с правами чтения и без учётных данных деплоя.
• Триггер с доверенным контекстом основной ветки не должен выполнять код форка с повышенными правами.
• Привилегированная упаковка или деплой должны ждать ревью и запускаться из защищённой ветки или окружения.

Настройте GITHUB_TOKEN только на чтение по умолчанию и выдавайте каждому job лишь необходимые ему права.

• Job с тестами обычно нужен доступ на чтение содержимого репозитория, но не запись пакетов или деплоев.
• Job публикации может получить запись пакетов только после успешных тестов в доверенной ветке.
• Право id-token write выдаётся только тому job, который действительно выполняет OIDC-обмен.

GitLab CI job token нужно считать временными учётными данными и ограничивать его доступ к проектам задачей текущего job.

• Предпочитайте job token персональному токену доступа, если целевой сервис его поддерживает.
• Ограничивайте проекты, которые могут использовать или принимать токен, вместо доверия всем внутренним репозиториям.
• Не сохраняйте токен в артефактах, кеше, выводе команд или файлах, остающихся после job.

Защищённые ветки заставляют изменения проходить заданное ревью и статусные проверки до попадания в доверенную историю выпуска.

• Запрет прямых push не позволяет одной скомпрометированной учётной записи разработчика незаметно пропустить ревью.
• Обязательные CI-проверки обеспечивают тестирование и сканирование именно того коммита, который будет смержен.
• Ограничение force push сохраняет проверенную историю коммитов для последующих сборок и provenance.

Защищённые окружения контролируют, когда доверенный коммит может получить доступ для деплоя в чувствительную цель.

• Окружения GitHub Actions могут требовать согласования перед выдачей секретов окружения job.
• Protected environments в GitLab могут ограничивать ветки, теги и пользователей с правом деплоя.
• Job деплоя должен ссылаться на проверенный артефакт, а не пересобирать другое содержимое после согласования.

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

• Оно может прослеживать подозрительные потоки данных, небезопасное использование API и характерные для языка шаблоны кода.
• Проверка подходит для pull-request или build jobs, потому что ей не нужна развёрнутая цель.
• Результат SAST является поводом для проверки, а не доказательством эксплуатации проблемы в развёрнутой системе.

SAST должен рано проверять изменённый код и полностью запускаться перед выпуском доверенного кода.

• Быстрое сканирование pull request даёт обратную связь рядом с изменением разработчика.
• Сканирование основной ветки может покрыть весь репозиторий с конфигурацией production-сборки.
• SAST может пропустить конфигурацию runtime, поведение аутентификации после деплоя и пути, которые не умеет точно моделировать.