Question 1

How would you manage secrets in a CI/CD pipeline?

Accepted Answer

Lead with eliminating stored secrets rather than storing them better: short-lived credentials minted at run time via OIDC federation, so there is nothing in a settings page to steal. Then the handling rules for what remains — never as build arguments, because those are recorded in image metadata and docker history prints them; scoped per step rather than injected pipeline-wide; redaction at the logger.

Question 2

A secret was committed to Git and reverted twenty minutes later. Is that fine?

Accepted Answer

No, and the reason is structural rather than procedural. Git is content-addressed and immutable, so the revert adds a commit while the original blob stays reachable — in history, and in every clone anyone already made. Rewriting history does not help with clones. Revocation is the only remedy; removing the file is housekeeping. And the exposure window is genuinely unknowable, so “we caught it fast” is not a measurement.

Question 3

You accept pull requests from outside your team. What worries you?

Accepted Answer

Name poisoned pipeline execution and then trace where the executed text comes from. If the workflow, a build script, a test fixture or a lint plugin is read from the PR branch, then proposing a change is running code on your build host. The subtlety worth raising: people protect the workflow file and leave the script it calls wide open. Mitigations are trigger types that withhold secrets from forks, and requiring a maintainer action before anything privileged runs.

Question 4

Your build step only compiles TypeScript. Why does its permission set matter?

Accepted Answer

Because a build is untrusted code execution by design — it runs whatever is in the repository plus whatever the dependency tree does at install time. Runners are usually provisioned once with the union of every permission any job might need, so the compile step holds credentials that reach production. The gap between “the build ran” and “an attacker ran” is not a boundary, it is a hope. Fixes: per-step credentials, ephemeral runners, egress control, and not building on a host that runs anything you care about.

Question 5

You deploy myapp:v2.1 and it passed all tests. What have you actually proven?

Accepted Answer

That a tag resolved to something that passed tests, at the time it was resolved. A tag is a pointer that can be moved unless the registry locks it, and nothing in the reference tells you which, so the tested artifact and the deployed artifact are two lookups of a name rather than two uses of a thing. Only a digest is bound to content, and only a signature makes it verifiable rather than merely agreed.

Question 6

Which of these would you fix first, and how would you justify the order?

Accepted Answer

Have a position and defend it with reasoning rather than a framework. A defensible order: credential hygiene first, because credentials are what an attacker in a pipeline looks for first and a leaked secret cannot be un-leaked; then flow control, because one required review converts a compromise from an outcome into an attempt; then dependency handling, because two flags close most of it. What matters is that the ranking follows from likelihood and irreversibility, not from a list.

CI/CD security: the pipeline as an attack surface

How would you manage secrets in a CI/CD pipeline?

Sources

Where to go next