Your public repo builds fork pull requests in a job that can read the deploy secret. What threat does that create?

## What the attacker actually controls On a public repository, opening a pull request is an unauthenticated action. The person on the other end is an external entity with no established trust, and the branch they propose is entirely theirs. When people picture this threat they picture malicious application source, and then reassure themselves that a reviewer would spot it. But the contributor's control is much wider than the code under review: - **Test code**, which the job executes by design - **Build scripts and task definitions**, which run before anyone looks at the result - **Dependency manifests and lockfiles**, which can point at a package the contributor controls, whose install step is itself code - **The pipeline definition**, if the CI system reads it from the proposed branch rather than from the trusted base Any one of these executes commands. The reassurance "we only run unit tests" describes what the job is *for*, not what it *can do*: a test runner is not a sandbox, it is a program that executes repository code with the job's full privileges and network access. ## Why the credential is the prize The artifact of that build is throwaway; nobody ships a fork's pull request. What is not throwaway is the identity in the job's environment. A standing deploy credential outlives the build, and with it the attacker gains what the pipeline has: the ability to change production without going through review at all. The theft is a single request to a host they control — or a print in a log they can read, or a DNS lookup with the value in the name, or an artifact they can download afterwards. Enumerating exfiltration channels is a losing game, which is the point: the mitigation cannot be at the channel. ## Reading it through STRIDE - **Elevation of privilege** (violating authorization) is the headline: an anonymous outsider ends up acting with deployment authority. - **Information disclosure** (confidentiality) is the mechanism — the credential and anything else in the job environment leaves. - **Tampering** (integrity) follows if that build can write to a shared cache or an artifact store that trusted builds later consume. - **Repudiation** matters afterwards: the resulting production change is attributed to the pipeline identity, not to the person who caused it. Rating this is not subtle. The attacker position is anonymous and unauthenticated, the skill required is low, and the consequence is authority over production — this is the one that goes at the top of the list. ## Fixes that do not work - **Scanning the diff for malicious code.** You are asking a heuristic to beat an author who can obfuscate freely, in a language of their choosing, across files nobody reviews carefully. - **Masking secrets in logs.** That defends one channel out of many, and only after the code already holds the value. - **Requiring signed commits.** Signing establishes who wrote it, which was never in doubt; a signed malicious commit executes exactly as well. - **Reviewing after the build.** The build already ran. Ordering is the whole point. ## The structural fix Move the boundary so that untrusted content and production authority are never on the same side: 1. **A pre-merge lane with nothing to steal.** Builds of proposed changes run with no secrets, no deployment identity, no write access to shared caches or artifact stores, and restricted egress. If it is compromised, the loss is compute. 2. **A post-merge lane that is trusted because the content was reviewed.** Anything credentialed runs on the merged commit, on infrastructure the contributor never touched. 3. **Pin what was reviewed.** If a human gate releases a build, it must build the exact commit that was reviewed. Approve-then-push-again is a straightforward time-of-check-to-time-of-use gap. 4. **Read the pipeline definition from the trusted base**, not from the proposed branch, so the change cannot rewrite the rules under which it is evaluated. 5. **Shrink the credential.** Even on the trusted side, the deploy identity should be scoped to what the job deploys and short-lived, so that a compromise later in the path is bounded. ## Where the same reasoning goes next The same boundary question applies to internal repositories with a different attacker: a long-lived shared runner that is not wiped between jobs puts a low-privilege developer from an unrelated team in reach of another team's workspace and the host's identity. The attacker changes from anonymous outsider to authenticated insider, the asset changes from one deploy role to source-code IP plus other teams' credentials, and the modelling lesson is the same — you drew a boundary the infrastructure does not implement.