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

Я бы публиковал небольшие версионируемые шаблоны со стабильными контрактами и отдельно обеспечивал неизменяемость каждого типа ссылки.

• Шаблоны сборки, сканирования, подписи и деплоя разделены, поэтому каждая задача получает только необходимые права и секреты.
• Типизированные входы, обязательные выходы, дайджесты артефактов и семантика ошибок позволяют командам подключаться без копирования YAML.
• GitHub Actions закреплены по полным 40-символьным SHA коммитов, а контейнерные образы и скачиваемые инструменты по их нативным дайджестам содержимого.
• SemVer-теги используются для навигации, но потребители указывают полный SHA коммита, а тег считается неизменяемым только при отдельной защите или контроле повторного назначения.

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

• Задачи pull request получают доступ к исходникам только для чтения, не получают секреты репозитория и облачную роль и используют отдельное пространство кэша.
• Задача защищённой ветки берёт проверенный коммит, получает краткоживущую идентичность и пишет только в staging-репозиторий артефактов.
• Подпись и продвижение в production запускаются после policy-проверок в защищённом окружении с явными правами и неизменяемыми входами.
• Артефакты из недоверенной зоны считаются недоверенными данными и пересобираются в релизной зоне, а не продвигаются напрямую.

Я бы предоставил аутентифицированный удалённый rootless BuildKit service с изоляцией workers и доверенного состояния по задачам и командам.

• Каждая сборка работает в новом rootless worker или равнозначной границе user namespace без Docker socket хоста, privileged container и переиспользуемого рабочего каталога.
• OIDC- или mTLS-идентичность задачи разрешает конкретный репозиторий и cache namespace, а недоверенные pull requests не могут записывать cache для последующих защищённых релизов.
• Egress ограничен allowlist, secret и SSH mounts существуют только в build session, а логи, слои и экспортируемый cache проверяются на отсутствие сохранённых секретов.
• Я проведу canary типовых сборок всех 8 команд и отключу Docker-in-Docker только после прохождения isolation tests и достижения p95 не более чем на 15% медленнее текущего baseline.

Я бы создал отдельные пулы runners по уровню доверия и уничтожал worker после одной задачи.

• Недоверенные pull request никогда не используют общий пул, подсеть, кэш или service account с релизными задачами.
• Каждый worker получает минимальную сетевую политику с доступом только к исходникам, зеркалу зависимостей, логам и назначенному репозиторию артефактов.
• Оркестратор выдаёт идентичность на время задачи только после назначения worker, а базовый образ не содержит облачных ключей или учётных данных репозитория.
• Метки пула служат только для планирования, поэтому изоляция обеспечивается отдельными аккаунтами, сетями, идентичностями и autoscaling groups.

Ephemeral runner должен создаваться из проверенного образа для одной задачи и уничтожаться независимо от её успеха или ошибки.

• Контроллер получает краткоживущий registration token, затем регистрирует runner с --ephemeral или использует JIT-конфигурацию, чтобы worker принял ровно одну задачу; сам registration token не считается одноразовым.
• Краткоживущая workload identity и сетевая политика задачи подключаются только после выбора worker планировщиком.
• Логи и разрешённые артефакты уходят через контролируемые приёмники, а рабочие каталоги, cache с учётными данными и локальные диски не переживают удаление.
• Я оповещаю о workers, живущих дольше ожидаемой длительности сборки с небольшим запасом, потому что сбой удаления создаёт постоянную поверхность атаки.

Я бы разделил сканирование по уровню доверия, чтобы форки получали сокращённый путь без credentials, а защищённый код проходил обязательный лицензионный скан.

• Внешние pull requests из форков запускают открытый или локально упакованный сокращённый ruleset с read-only доступом, без vendor credential, секретов и записываемого cache, общего с доверенными задачами.
• CI control plane помечает очищенный результат коммитом, версией scanner, версией правил и классом доверия fork-reduced, который не удовлетворяет gate защищённой ветки.
• После review защищённая ветка запускает лицензионный scanner с узким credential и публикует доверенный результат, связанный с проверенным коммитом и релизным артефактом.
• Promotion пересобирает код в доверенной зоне и требует лицензионный результат, а regression tests доказывают, что форк не может заменить evidence, отравить его cache или продвинуть свои артефакты.

Я бы собирал артефакт один раз, идентифицировал его по дайджесту и продвигал этот же дайджест между окружениями.

• Задача сборки отправляет артефакт в неизменяемый staging-репозиторий и выпускает дайджест образа, SBOM, provenance и результаты тестов.
• Policy-проверки подтверждают, что эти объекты относятся к одному дайджесту, прежде чем создаётся запись о продвижении.
• Задачи деплоя копируют или ссылаются на одобренный дайджест, не принимая изменяемый тег за источник истины.
• Admission в production снова проверяет подпись и provenance, поэтому одобрение одного дайджеста не авторизует подменённый образ.

Я бы выпустил новую major-версию шаблона, автоматизировал проверки миграции и назначил ограниченный срок вывода старой версии.

• Проверка совместимости сканирует каждого потребителя на удалённые входы, изменения прав и неподдерживаемые предположения о runners до начала раскатки.
• Первыми переходят два сервиса на разных стеках, а длительность, доля ошибок и отклонённые права служат канареечными сигналами.
• Команды получают сгенерированный pull request с обновлением версии и точным исправлением, а не только объявление в wiki.
• Старая версия остаётся неизменяемой на время миграционного окна, затем policy запрещает новые подключения до финального срока для существующих потребителей.

Я бы использовал граф зависимостей репозитория для быстрых проверок затронутых компонентов и сохранял плановое полное покрытие репозитория.

• Детектор изменений связывает изменённые файлы с сервисами, общими библиотеками, lockfiles, определениями контейнеров и зависимыми компонентами.
• Pull request параллельно запускает релевантные SAST, SCA, IaC и secret scans с нормализованными находками и одним итоговым гейтом.
• Ночная задача сканирует все сервисы и базовые образы, чтобы находить новые advisory, появившиеся без изменения кода.
• Оркестратор записывает версию scanner, набор правил, коммит, компонент и результат, поэтому пропущенная работа видна и не считается успешной проверкой.

Дифференциальный gate должен сравнивать предлагаемый коммит с явно заданным доверенным baseline и блокировать новый риск в затронутой области.

• Для SAST сравниваются стабильные fingerprints, а не только номера строк, потому что рефакторинг перемещает ту же находку.
• Для SCA учитываются новые пакеты, изменения версий и уязвимости, которые начали затрагивать существующий граф зависимостей.
• Для IaC оценивается изменение запланированных ресурсов вместе с унаследованными изменениями модулей.
• Плановый полный gate всё равно оценивает всю систему, потому что дифференциальные сканы не обнаруживают каждое обновление правил или advisory.

Я бы связал переиспользование результатов scanner с графом зависимостей монорепозитория и каждым входом, способным изменить находку.

• Cache keys включают хеши исходников и lockfile, ревизии общих библиотек, разрешённый digest базового образа, build configuration, версии scanner, правил и advisory data.
• Изменение общего lockfile, базового образа, библиотеки или build template инвалидирует результаты для полного множества downstream-сервисов, а неизвестное влияние запускает полный scan вместо cache hit.
• Cache namespaces адресуются по содержимому и разделяются по классу доверия, а отсутствующий, устаревший или ошибочный результат никогда не превращается в pass.
• Плановый полный scan сверяет все 40 сервисов с переиспользованными результатами, показывает необъяснимые расхождения и отключает дефектный cache path до исправления правила инвалидации.

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

• Достижимая уязвимая функция во внешнем сервисе является веским основанием для блокирующего гейта.
• Результат о недостижимости может быть неточным при reflection, plugins, сгенерированном коде, native bindings или путях только времени исполнения.
• Я объединяю reachability с расположением пакета, внешней доступностью, зрелостью эксплойта, компенсирующими мерами и глубиной зависимости.
• Доказательства и версия инструмента сохраняются с решением, чтобы изменение call graph или приложения запустило повторную оценку.

Нет, я бы гейтил по контекстному риску, а не только CVSS, сохраняя консервативное правило для подтверждённой эксплуатации.

• Наличие в CISA KEV или надёжный эксплойт для доступного пути может требовать немедленной блокировки даже при меньшей исходной оценке.
• EPSS, reachability, доступность из интернета, использование пакета и компенсирующие меры уточняют приоритет.
• Уверенность scanner и наличие исправления влияют на действие, но отсутствие патча не отменяет риск или ответственность.
• Матрица решений версионируется и выдаёт записанную причину, чтобы команды получали согласованные результаты во всех 40 сервисах.

Я бы применял анализ изменённых компонентов для обычных pull requests, а полный cross-service dataflow оставил для risk-triggered и плановых gates.

• Проверяемый граф зависимостей связывает изменённые файлы с сервисами, generated code, общими библиотеками, entry points и downstream callers, поэтому pull-request scan покрывает затронутые компоненты, а не только изменённые строки.
• Обычные изменения сервиса запускают high-confidence межпроцедурные правила в фиксированном бюджете pull request и помечают пропущенный scope как incomplete, а не clean.
• Изменения общих библиотек или cross-service interfaces запускают полный анализ на 28 ГБ как обязательный merge gate, потому что их dataflow impact нельзя безопасно ограничить одним компонентом.
• Плановый изолированный полный scan на 35 минут сверяет все сервисы, направляет стабильные findings владельцам и создаёт regression cases, когда путь изменённых компонентов пропускает flow.

Я бы сканировал lockfiles до сборки и финальный образ по дайджесту, потому что эти представления отвечают на разные вопросы.

• SCA в pull request проверяет прямые и транзитивные зависимости по сохранённым lockfiles и рано обнаруживает рискованные изменения версий.
• Скан образа находит пакеты операционной системы, скопированные бинарные файлы и артефакты сборки, отсутствующие в lockfile приложения.
• Ночные повторные сканы сохранённых production-дайджестов находят новые CVE без пересборки образа.
• Результаты связываются по сервису, пакету, версии, слою или манифесту и дайджесту, чтобы у дублей был один владелец и один статус.

Я бы запускал аутентифицированный DAST против ephemeral environment после деплоя и сохранял подписанную запись доказательств, связанную с релизным дайджестом.

• Smoke-профиль работает на кандидатах в релиз, а более широкий crawler и набор активных тестов запускаются ночью для контроля задержки и риска тестов.
• Тестовые аккаунты, подготовленные данные, разрешённые hosts, частота запросов и исключения разрушающих тестов заданы явно и воспроизводимо.
• Результат хранит версии scanner и правил, целевой коммит, дайджест образа, время, покрытие, находки и незавершённые проверки.
• Релизный gate использует нормализованный вердикт, но команды могут открыть исходный отчёт с доказательствами запросов и ответов.

Для каждого окружения я бы использовал самую сильную доступную нативную workload identity и не распространял общий токен Vault.

• CI аутентифицируется по JWT или OIDC claims, привязанным к репозиторию, ветке, audience и workflow, затем получает короткий токен Vault.
• Workloads Kubernetes используют Kubernetes auth с service account identity, привязанной к точному namespace и service account.
• Legacy VM используют машинную идентичность, например cloud IAM auth; AppRole служит запасным вариантом, только если доставка RoleID и SecretID разделена.
• У каждой auth role узкие политики, короткий TTL токена, телеметрия использования и нет общего пути по умолчанию для всех 40 сервисов.

Я бы дал каждому сервису роль базы данных, выпускающую пользователей с узкими правами и короткими возобновляемыми leases.

• SQL роли Vault выдаёт права только на нужные сервису схемы и операции, с отдельными ролями для миграций и обычной runtime-работы.
• Default TTL покрывает нормальную смену соединений, а max TTL принудительно заменяет учётные данные вместо бесконечного продления.
• Приложения продлевают lease до истечения и плавно ротируют пулы соединений, чтобы новые учётные данные начали работать до закрытия старых сессий.
• Владелец lease, роль базы данных, время выпуска, продление, истечение и отзыв отслеживаются по сервису для аудита и планирования ёмкости.

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

• У каждой роли Vault есть детерминированный revocation SQL, который отключает или удаляет только созданного пользователя базы данных, не затрагивая идентичности других сервисов.
• Для немедленного containment отдельно авторизованный путь запрещает login и завершает активные сессии этого созданного пользователя вместо ожидания старения пула соединений.
• Обычное время жизни соединения ограничено, а ошибки отзыва попадают в очередь повторов и alerts с идентификаторами lease, роли, сервиса и базы данных.
• Периодическая сверка сравнивает активные leases Vault, пользователей базы и живые сессии, чтобы найти осиротевшие credentials или сохранившийся доступ с обеих сторон.

Я бы использовал response wrapping для доставки чувствительного bootstrap-материала через посредника без раскрытия самого секрета.

• Vault возвращает одноразовый wrapping token с коротким TTL вместо самого AppRole SecretID или начальных учётных данных.
• Целевая workload разворачивает значение напрямую из Vault и проверяет ожидаемый creation path и wrapping metadata перед использованием.
• Истёкший или уже развёрнутый токен закрывает доступ и создаёт audit event, что выявляет перехват или задержку доставки.
• Wrapping защищает доставку, но не заменяет аутентификацию workload, узкую политику или ротацию после bootstrap.