An outside contributor cannot merge anything to your main branch, but they can open a pull request that triggers CI. What can they still make your pipeline execute, and how do you limit it?

## Naming the class Poisoned pipeline execution is the situation where someone who cannot merge code can nevertheless get the build system to execute code of their choosing. It is the defining risk of running CI on contributions, and it is the reason "they can't merge" is not a security answer. ## Direct: the pipeline definition is source code too The pipeline definition lives in the repository, on a branch, next to everything else. If the CI system evaluates the definition from the *branch being tested* — the common default, because that is how a contributor changes their build — then modifying the build is as easy as modifying any other file. The contributor adds a step that prints the environment, uploads it somewhere, or uses the job's token, and the pipeline dutifully runs it because it is doing exactly what pipelines do. The structural answer is to decide, explicitly, which ref the *definition* is read from for untrusted contributions, and to treat pipeline files as protected paths requiring maintainer review — the same way you would treat a deployment manifest. ## Indirect: the build runs their code anyway This is the part teams miss, and the part interviewers probe. Suppose the pipeline definition comes from the trusted ref, so the contributor cannot add steps. The pipeline still checks out their branch and then runs things *in* it. Every one of the following is attacker-controlled content that executes: - **build scripts** — a `Makefile`, a task-runner target, a build file in a language that is itself executable - **package lifecycle hooks** — install scripts that run during dependency installation of the branch's manifest - **the test suite** — arbitrary code by definition; a test can open a socket as easily as it can assert - **test and lint configuration** — configuration files that load plugins from the workspace, so "just running the linter" executes branch code - **code generation and pre-processing steps** the build invokes - **the dependency manifest** — a contributor can add a dependency whose install hook is the payload So the correct mental model is: *any* job that checks out an untrusted ref and does more than read files is executing untrusted code. The interesting question stops being "can they run code?" — assume yes — and becomes "what does the job that runs their code hold?" ## Limiting it **1. Make the untrusted job worth nothing.** The build that validates a contribution should have no deploy credential, no registry push right, no signing key, and a read-only token. If the attacker gets code execution and finds an empty environment, the attack ends there. This single decision does most of the work. **2. Split trusted from untrusted work.** Publishing, signing, deploying and any step touching production belong to a pipeline that runs on the merged, reviewed ref — after review has happened. Do not try to build one pipeline that both validates strangers' code and holds release credentials, gated by conditionals; conditionals are easy to get subtly wrong and easy to trigger accidentally. **3. Read the definition from the trusted ref** for untrusted contributions, and require review on changes to pipeline files. **4. Gate the first run.** Requiring a maintainer to approve before CI runs on an outside contribution converts an automated attack into one that needs a human mistake. It costs contributor latency, which is a real tradeoff worth stating. **5. Beware the privileged-trigger trap.** Most platforms offer a trigger variant that runs in the *base* repository's context — with its secrets — while still relating to the contribution. Those variants exist for legitimate reasons (labelling, commenting) and are safe only if they never check out or execute the contributed code. Checking out the branch under such a trigger recreates the full vulnerability with credentials attached. **6. Do not let one bad run poison the next.** Where the same worker serves many jobs, code execution in an untrusted build can leave state behind for a later privileged build. Ephemeral, per-job workers remove that path; the general isolation design is its own topic, but the pipeline-design consequence — never schedule untrusted contributions onto the same workers as release builds — belongs in this answer. ## What a strong answer sounds like "Assume they get code execution — running their tests grants it, and often they can rewrite the build outright. So I design for it: the contribution pipeline holds nothing, the release pipeline runs only on merged code, the pipeline definition comes from the trusted ref, and the two never share a worker."