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

Я построю единый control plane для идентификации, политик, provenance, секретов и evidence, а затем дам каждой системе доставки нативную интеграцию с ним.

• GitHub Actions, GitLab CI и Buildkite будут вызывать версионируемые платформенные workflows, которые выдают workload identity, один раз собирают артефакт, подписывают digest, прикладывают SBOM и запрашивают promotion.
• Отдельный путь проверки при promotion в registry и admission в Kubernetes будет проверять подписи cosign, provenance и политики, поэтому скомпрометированная CI-задача не сможет одобрить собственный результат.
• Сначала я подключу две репрезентативные организации, затем доведу охват production-сервисов до 90% к шестому месяцу и долю подписанных, аттестованных деплоев до 98% к девятому.
• Я приму более медленную поддержку редких build-систем ради единой модели доверия, но опубликую ручной путь подключения с теми же контролями.

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

• Я обозначу границы доверия между недоверенными pull requests, runner-хостами, control plane CI, registry, сервисами подписи, хранилищами политик и production-deployers.
• Первый design review охватит кражу токенов, изменение workflow, poisoning кеша, подмену артефакта, обход политик и закрепление между tenant-ами runner-ов с назначенными превентивными контролями.
• Задачи из публичных форков не получат cloud identity или общий записываемый кеш, а доверенные release-задачи будут работать на новых изолированных workers с проверкой repository и ref claims в OIDC.
• К третьей неделе я потребую владельцев и тесты для каждого критического abuse case, а к десятой докажу, что все high-risk пути либо закрываются, либо имеют документированное ограниченное исключение.

Я создам сверенный inventory из фактов о деплоях, ownership исходного кода и активности CI, а не приму список Git-провайдера за denominator.

• Ежедневный collector свяжет registry digests и workloads в кластерах с репозиториями, workflow-файлами, командами-владельцами, классификацией данных, внешней доступностью и последним production-деплоем.
• Репозитории без деплоя за 90 дней останутся видимыми, но не войдут в denominator production coverage, а запущенные workloads без владельца заблокируют платформенный аккаунт команды.
• Команды будут исправлять ownership через проверяемый catalog-файл, но обнаруженные факты из runtime и registry останутся источником истины о реально развёрнутом.
• К 90-му дню 99% production workloads должны быть связаны с репозиторием и владельцем, задержка inventory должна быть меньше 24 часов, а неизвестных tier-one сервисов не должно остаться.

Я централизую политики и trust metadata, но оставлю сборки, секреты и выполнение деплоев внутри изолированных tenant data planes.

• Control plane будет публиковать подписанные версии workflows, bundles политик, trust roots и решения о promotion, не получая архивы исходного кода или переиспользуемые cloud credentials.
• У каждой организации будут отдельные runner pools, namespaces Vault, registry paths и cloud roles, а repository и environment claims предотвратят lateral access.
• Через границы будут передаваться immutable digests и attestations, а не пересобираться артефакты или копироваться bearer tokens между системами.
• Я проверю доступность решений на уровне 99,9%, отсутствие cross-tenant доступа квартальными isolation tests и максимальный RPO policy metadata в 30 минут.

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

• Paved workflow включит OIDC, закреплённые builders, изоляцию кеша, генерацию SBOM, подпись и promotion за одним версионируемым include с migration tooling для типовых pipelines.
• Я привлеку одну high-volume и одну регулируемую команду как design partners, а затем использую их queue time, failure rate и bypass requests для устранения трения до широкой раскатки.
• Adoption будет измеряться production digests, собранными и продвинутыми через платформу, а не репозиториями с файлом шаблона.
• Gate второго квартала потребует не менее 85% adoption, менее трёх добавленных медианных минут, менее 1% сбоев по вине платформы и одобренный план для оставшихся сервисов.

Сначала я профинансирую общий путь identity и artifact trust, потому что каждый последующий контроль зависит от знания, кто что собрал и что развёртывается.

• В первом и втором месяцах появятся inventory репозиториев, эфемерные OIDC identities, изолированные release runners, immutable digests и пилотный registry promotion service.
• В третьем и четвёртом месяцах я добавлю cosign provenance, SBOM и проверки Conftest для 40 самых рискованных сервисов до начала admission enforcement.
• В пятом и шестом месяцах я добавлю динамические credentials Vault и подписанные admission policies с целью охватить 90% production-деплоев и 100% tier-one сервисов.
• Широкую консолидацию CNAPP я отложу, пока эти control points не дадут надёжный ownership, сохранив около $250 000 на миграцию и runner capacity.

Я предоставлю четыре узких сервиса для обмена identity, аттестации артефактов, policy decisions и promotion и зафиксирую для каждого блокирующего деплой интерфейса месячный SLO платформы 99,9%.

• Стабильные версионируемые API будут возвращать машиночитаемые reason codes, а адаптеры GitHub, GitLab и Buildkite преобразуют нативные claims и метаданные jobs.
• Продуктовые команды будут владеть логикой сборки, а платформа будет отвечать за identity mapping, схемы attestations, trust roots и авторизацию production promotion.
• Асинхронный экспорт evidence останется вне hot path деплоя, поэтому сбой audit sink не остановит релизы.
• К 16-й неделе я потребую не менее 99,9% успешных API-запросов за месяц, p95 policy decisions ниже 300 миллисекунд и подключение стандартного репозитория менее чем за час.

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

• Catalog свяжет repository, service, environment и control с основным владельцем, резервным владельцем, адресом пейджинга и business criticality, причем факты production deployment будут важнее устаревших labels.
• Platform on-call будет отвечать за identity broker, verifier, распространение policies и доступность signing, а product on-call за исправление кода, dependencies, configuration и сервиса.
• Неподтвержденное событие вызовет primary owner через пять минут, secondary owner через 10 и platform duty manager через 15, а у межкомандного сбоя будет один incident commander.
• К 90-му дню я сокращу нарушения ownership SLO с 38% до менее 5%, обеспечу автоматическую маршрутизацию 98% сбоев и не оставлю ни одного tier-0 сервиса без проверенного пути эскалации.

Я стандартизирую эфемерные workers и общие классы изоляции, сохранив нативные scheduling adapters каждого CI-провайдера.

• Недоверенные, обычные, privileged-build и release jobs будут использовать отдельные аккаунты, сети, images, instance profiles и concurrency quotas, а не labels в одном общем pool.
• Workers будут загружаться из подписанных immutable images, принимать одну задачу, экспортировать логи, очищать эфемерные диски и завершаться без inbound-пути администрирования.
• Autoscaling будет опираться на queue depth и startup latency, удерживая p95 queue time ниже двух минут и сохраняя warm capacity только для release-класса.
• Gate выхода через четыре месяца требует ноль постоянных runners, 99% покрытия эфемерными задачами и роста compute cost менее чем на 15% после экономии на spot instances.

Я буду считать код из форков враждебным и дам ему физически отдельный runner path без маршрута к release identities, кешам или control services.

• Fork jobs будут работать rootless в одноразовых microVM с read-only исходным кодом, allowlisted egress, без общего записываемого кеша и без CI secrets.
• Для прямой роли GitHub-to-AWS IAM надежно ограничивает только audience и subject; subject с environment заменяет subject с ref, поэтому direct trust не авторизует одновременно repository, ref, workflow и environment.
• Trusted deployments будут использовать protected GitHub environment для ограничений ref и approvals, централизованный reusable workflow и identity broker, проверяющий repository, ref, job_workflow_ref и environment до входа в AWS.
• Rootless BuildKit получит изолированные cache namespaces, а rollout за шесть недель будет заблокирован до прохождения 50 автоматических тестов на escape и credential access.

Я сделаю центральный workload-identity registry источником истины для всех трёх CI-провайдеров и облаков.

• Каждая запись свяжет доверенные issuer, audience и subject patterns с одним repository, одним environment и одной least-privilege target identity в каждом нужном AWS account, Azure subscription или GCP project.
• Generator создаст из registry нативные AWS IAM trust policies, Azure federated identity credentials и bindings провайдера GCP Workload Identity Federation; каждое изменение registry пройдет security review и policy tests.
• CI jobs будут использовать direct federation везде, где нативные claim conditions выражают полное правило, а broker останется только для дополнительного проверенного context; каждая итоговая session ограничена 15 минутами.
• Identities для development, staging и production останутся раздельными; central audit и revocation отключат mappings во всех облаках, а acceptance tests для всех 350 repositories докажут успех разрешенных путей и отказ для cross-repository, cross-environment, wrong-audience и revoked путей.

Я сделаю подписанный центральный promotion manifest единственным разрешением для production и привяжу его к точным artifact digest, configuration digest, provenance decision и target environment.

• Каждый CI adapter передаст immutable digest артефакта и конфигурации вместе с native provenance, а отдельный verifier проверит builder identity, source, materials и версию policy.
• Promotion service запишет решение verifier, identity согласующего environment, время авторизации, expiry и предыдущий manifest в append-only store до подписи manifest.
• Deployment и admission примут только пару артефакта и конфигурации, указанную для этого environment, поэтому CI-система не сможет пересобрать байты или повторно использовать staging authorization в production.
• Сначала я мигрирую tier-0 и репрезентативные сервисы каждой CI, а rollback разрешу только на последний валидный manifest и его исходные digests, но не на пересобранный эквивалент.

Я уберу необъявленные сетевые и toolchain inputs из release builds, сохранив только кеши, доверие к которым устанавливается при создании каждой записи.

• Dependencies, base images, compilers и build actions будут закреплены по digest и зеркалироваться во внутренний repository через проверяемые update jobs.
• Release workers запретят internet egress и завершат сборку ошибкой при запросе необъявленного файла, environment value, зависимости от часов или remote endpoint.
• Cache keys свяжут source, lockfile, builder image и flags, а доверенное создание подпишет cache metadata с producer и content digest.
• Любое несовпадение trust или metadata приведет к удалению записи и чистой пересборке; pipeline никогда не легитимизирует и не подпишет подозрительную запись после обнаружения.

Я буду авторизовать деплои на основе protected environment policy и проверенных фактов об артефакте, оставив human approval для high-risk изменений, а не каждого релиза.

• Deployer потребует protected ref, успешное policy decision, approved artifact digest и OIDC subject, привязанный к repository и target environment.
• Обычные low-risk promotions будут автоматическими, а tier-one schema changes, policy exceptions и первые релизы сервисов потребуют двух authorized reviewers.
• Build identities смогут подавать candidates, но не продвигать их, а platform administrators смогут менять policy, но не выдавать себя за product deployers.
• Цель на восьмую неделю сохранит 95% обычных релизов без согласований, залогирует 100% authorization inputs и отклонит все 20 проверенных путей самоодобрения.

Я объединю autoscaling по классам, небольшой release reserve и interruptible capacity для обычных задач вместо постоянного fleet, рассчитанного на пик.

• Release workers сохранят warm capacity для p95 нагрузки и будут использовать on-demand instances, а test pools станут масштабироваться в основном на spot capacity с безопасным retry от checkpoint.
• Queue fairness ограничит шумные организации и зарезервирует concurrency для 40 tier-one сервисов, не позволяя одному монорепозиторию занять весь fleet.
• Worker images будут pre-pulled, а regional pools получат цель p95 startup в 90 секунд, потому что autoscaling не исправит 10-минутную загрузку.
• Я приму до 2% повторных test jobs ради бюджета ниже $1,4 млн, но потребую p95 release queue time менее трёх минут во время четырёхнедельного load test.

Я стандартизирую подписанные control contracts и evidence schemas, а не стану изобретать pipeline language по наименьшему общему знаменателю.

• Каждый провайдер получит тонкий нативный adapter, который получает identity, вызывает один builder, выпускает то же in-toto statement и обращается к тому же promotion API.
• Версионируемые reference workflows закрепят adapter digests, а продуктовые команды сохранят нативные test и orchestration возможности провайдера вне доверенных release stages.
• Conformance tests проведут одинаковые sample repositories через все три системы и сравнят identity claims, artifact digests, attestations и denial behavior.
• К концу квартала 80% релизов должны использовать не более 12 поддерживаемых templates, semantic drift должен отсутствовать в 25 control tests, а обязательной миграции провайдера не будет.

Я применю keyless workload signing для подключённых CI-релизов и буду проверять точные issuer и subject claims, сохранив managed-key signing только для workloads, где этот flow невозможен.

• Release jobs создадут эфемерные signing keys, получат краткоживущие сертификаты Fulcio на основе CI OIDC identity и запишут entries в Rekor без хранения переиспользуемого signing private key.
• Verification policy привяжет подписи к protected repositories, workflows, refs и ожидаемым issuers, а не просто проверит наличие любого валидного сертификата.
• Обновления trust roots и версий cosign policy пройдут через staging до production, а для disconnected builds будет документированный managed-key fallback.
• К 16-й неделе я потребую 98% подписанных production digests, 100% tier-one coverage и отклонение unsigned, wrong-repository и wrong-issuer samples в admission tests.

Я объединю три нативных trust domain через единый verifier, который выпускает подписанное решение об исходном provenance, а не притворяется, что у всех builders один формат identity.

• Approved-builder registry сохранит issuer, root, шаблон builder identity, owner, разрешенные repositories, версию predicate, expiry и revocation status для каждой платформы.
• Provider adapters сначала проверят native envelope, затем сопоставят source, materials, invocation, builder и output digest с нормализованными in-toto expectations, не переписывая исходный statement.
• Verifier привяжет свое решение к digest исходной attestation и версии policy, а revocation немедленно запретит новые решения скомпрометированного builder, сохранив historical evidence.
• Admission пройдет от observe к block по группам builders и завершится требованием валидного решения approved registry для каждого production digest с проверенным rollback на предыдущую policy verifier.

Я опубликую версионируемый trust bundle в стиле TUF, который поддерживает несколько roots во время миграции и позволяет verifiers обновлять их без доверия производителю артефакта.

• Bundle будет содержать public trust material Fulcio, Rekor, private CA и KMS, а также issuer constraints, validity windows, revocation status и environment scope.
• Изменения root потребуют threshold approval от security и platform owners, будут подписываться offline и сохранят одновременную работу старого и нового verification paths минимум 60 дней.
• Архивные артефакты сохранят signatures, certificate chains, timestamps и transparency proofs, нужные для проверки после изменения online services или identities.
• К шестому месяцу каждый verifier должен получать bundle в течение 24 часов, 100 исторических samples должны проверяться offline, а удаление одного скомпрометированного root не должно отключать остальные units.

Я сохраню единый контракт attestation и verification, но разрешу разные approved signing backends для подключённой и отключённой trust zones.

• Подключённый CI будет использовать OIDC keyless signing с Fulcio и Rekor, а disconnected builders получат non-exportable HSM или private KMS keys с узкими signing identities.
• Offline zone будет получать подписанные snapshots trust roots и policy через контролируемый transfer, а возвращать артефакты, SBOM, provenance и signatures через ту же проверяемую границу.
• Verifiers потребуют signer class, разрешённый для этого source и environment, поэтому offline key не сможет подписать подключённый сервис или обойти transparency requirements.
• К четвёртому месяцу нужны 100% tier-one coverage, trust snapshots не старше семи дней и offline verification 50 артефактов без доступа к сети.