How do you secure the CI/CD pipeline itself?

A CI/CD pipeline holds the keys to the kingdom: it can read all your source, build and sign artifacts, and deploy to production. If an attacker owns the pipeline, every scanner and gate downstream is moot. So you defend it like production.

Isolate and ephemeral-ize the runners

Build runners execute arbitrary code — including, on public repos, code from untrusted pull requests. Use ephemeral runners that are destroyed after each job so nothing persists between builds, and isolate them from your internal network and from each other. Never run untrusted PR builds with privileged credentials.

Least-privilege, short-lived credentials

The biggest win is killing long-lived secrets. Instead of storing a permanent cloud key in CI, use OIDC federation: the pipeline presents a short-lived, workload-scoped token that the cloud provider exchanges for temporary credentials. Tokens should be scoped narrowly (this job, these resources, read vs write) and expire fast, so a leaked token is nearly worthless.

Protect the pipeline definition

Pipeline config is code with production access. Put it under protected branches with required review, so no one can quietly add a step that exfiltrates secrets. Pin third-party actions/plugins to a commit digest (not a mutable tag) — an unpinned action can be repointed to malicious code that runs with your pipeline's permissions. This is exactly how real supply-chain incidents have unfolded.

Audit everything

Log who triggered what, which credentials were used, and what was deployed. You can't detect or investigate pipeline abuse you didn't record.

What interviewers look for

They want you to frame the pipeline as a top-tier target, lead with OIDC and least privilege over stored secrets, and mention ephemeral runners and pinned dependencies — the controls behind recent real-world CI/CD compromises.