Your CI must post a coverage comment on pull requests opened from forks, so a team proposes running the fork's build in a job that already holds the repository write token. Why is that dangerous, and what is the safe pattern?

## The rule underneath the question There is one rule and everything else follows from it: **whatever a job can reach, the author of the code that job runs can reach.** A pull request from a fork is code written by someone you have granted no access to. If the job that executes it holds a write token, you have granted them write access — you have simply routed it through your CI system. The subtlety candidates miss is *how much* of the pull request is executable. It is not only the test files. It is the build script, the task runner configuration, the dependency manifest with its install hooks, the linter plugins, the compiler plugins, and — depending on the platform — the pipeline definition itself. A malicious contribution does not need to look malicious; a single line in a lifecycle hook of a dependency, or a one-character change to a build script, executes before a human ever reads the diff. ## Why the tempting shortcut exists The feature people want is legitimate: post a coverage or benchmark comment, apply a label, update a status. All of those need a credential with write permission, and the job that produced the numbers is the obvious place to use it. So teams reach for the mechanism their platform offers for running a pipeline in a privileged context on pull requests — the pipeline definition is taken from the *target* branch, which is trusted, and the elevated token is available. That part is sound. The mistake is the next line: adding an explicit checkout of the pull request's head so the job can actually build the contributor's code. Now trusted pipeline definition plus untrusted source code plus a write token are in one execution context, and the trust of the definition is irrelevant, because the definition tells the job to run the contributor's build. GitHub Actions names such a trigger `pull_request_target`, and the same shape exists on any platform that lets you take the pipeline from one ref and the code from another. The signature of the bug is always identical: *the pipeline is trusted, the checkout is not, and they run together with a credential.* ## The two-stage pattern Split the work along the trust line. **Stage one — untrusted execution.** Triggered by the pull request itself. It checks out the contributor's code and runs the build and tests with: - no repository secrets and no cloud credentials of any kind; - a token scoped to read the public repository, or no token at all; - a disposable runner from a pool that never touches anything internal — a provider-hosted instance is the natural choice, and self-hosted machines inside your network must be excluded outright; - no route to internal registries, databases or metadata services; - and a required maintainer approval before it runs at all, for contributors who have not landed a change before. It writes its result — the coverage number, a benchmark JSON, a report file — as an artifact, along with the pull request number. **Stage two — trusted publication.** Triggered by stage one *completing*, not by the pull request. It runs the definition from your default branch, so a contributor cannot change what it does. It never checks out the fork's code. It downloads the artifact and posts the comment using the write token. ## The part that is still sharp The artifact crossing that line is attacker-controlled data. Stage two must handle it as data: read the file, parse it, validate the shape and bounds, and never interpolate its contents into a shell command, a template that gets evaluated, or a comment body that could carry markup with side effects. Also validate the pull-request number itself — if stage two takes a number from the artifact and posts to it, a contributor can direct the comment anywhere. Give stage two the narrowest token you can: permission to write comments on pull requests, nothing else. If it can only comment, the worst outcome of a mistake is a rude comment rather than a push to your default branch. ## Simpler answers that are often better Before building the handoff, ask whether the comment is worth it. Two alternatives are frequently sufficient: publish the result as a check or status from a trusted context that reads the numbers from your own storage, or accept that fork pull requests get a link to the run instead of a rendered comment. A large fraction of the incidents in this category exist because a convenience feature was allowed to determine the trust boundary.