Merge requests from a contracted partner's fork run on your internal-network CI runners. What do you change, and what do you accept?

## The situation An integration partner develops against your repository and contributes through merge requests from their own fork. Because their tests need to talk to an internal service, the merge-request pipelines were pointed at self-hosted runners that sit inside your network. Everyone is comfortable, because there is a signed contract and a named account manager. This is one of the most common ways an organisation ends up with anonymous-quality exposure at insider-quality trust. ## Separate the threat from the relationship The useful reframing is that the partner's *intent* is not the variable. The variables are: - **their account security** — a phished or credential-stuffed developer account at the partner is now a trigger for pipelines that run inside your network; - **their own supply chain** — a compromised dependency or build tool on their side reaches your runners through the code they propose; - **their offboarding hygiene** — a departed contractor whose access nobody revoked; - **your own configuration drift** — a runner tagged for partner work that also picks up a job with credentials. Against all four, the contract is a *reporting and remedy* instrument, not a control. It changes who pays afterwards. It does not change what executes. And note where the exposure lands: not customer data in a database, but **the internal network position of the build fleet** — service endpoints, metadata services, admin interfaces and lateral movement paths that were never designed to face an outsider's code. ## Choose a tier, and make it explicit The defensible designs are at the two ends; the muddle in the middle is what fails. **Option A — treat them as strangers.** Partner merge requests run exactly like anonymous fork contributions: no secrets, disposable single-use runners, no internal routes, egress restricted to what a build genuinely needs. The cost is that some of their integration tests cannot run, which you solve with data rather than with access (below). The gain is that the partner's security posture stops being part of your attack surface. **Option B — bring them inside.** Named individuals get accounts in your organisation and a branch in your repository, scoped to the paths they work on. This feels like more access, and in a narrow sense it is — but it converts an anonymous, unattributable fork run into an identified user whose actions are logged, whose access is revocable in one place, and whose sessions you can require multi-factor authentication for. You have traded an outsider you cannot see for an insider you can. For a long-running contracted relationship, that is very often the better trade, and it removes the pressure to build a special credentialed fork pipeline in the first place. **The muddle to reject:** keeping the internal runners and adding a maintainer approval in front of the pipeline. That substitutes human attention for a network boundary, at exactly the cadence — dozens of routine merge requests a week from a trusted-feeling partner — where attention is guaranteed to lapse. ## Replace network position with a scoped surface The reason the runners are inside is almost always one requirement: the tests need to reach an internal API. Solve that requirement directly. - Stand up a dedicated staging instance of that service with synthetic data, reachable from outside the internal network. - Issue a per-partner, short-lived credential to it, scoped to the operations the tests need, and revocable independently of everything else. - Restrict the runner's egress to that endpoint and the package sources the build needs. Now a compromise of the partner's pipeline yields a synthetic-data staging service, not a foothold on your internal network — and you can revoke it in one action without touching the repository relationship. ## What the contract should carry, and what it should not be asked to do Ask for things that improve your *detection and response*: mandatory multi-factor authentication for accounts touching your repository, a named contact and an obligation to notify you promptly of a compromise, a list of individuals with access reviewed on a schedule, and the right to revoke immediately without it being a commercial event. Do not write in clauses that pretend to be controls — "the partner shall not introduce malicious code" protects nobody. And be clear internally about risk ownership: if their compromise becomes your incident, the risk is yours to hold and yours to fund, whatever the indemnity says. ## What to measure One metric carries most of this: **the number of pipelines that can be triggered by a party outside your organisation and that hold either credentials or internal network reachability.** Drive it to zero, review it when a new partner is onboarded, and re-check it after every runner-pool change. A second, softer signal: how often someone requests an exception, which tells you whether the credential-free path is genuinely usable or whether you are pushing teams toward workarounds. ## Interview shape The answer that lands separates trust in a *relationship* from trust in a *pipeline*, picks a tier deliberately, offers the scoped-staging alternative to network access, and states plainly that the contract manages consequences rather than preventing execution. A candidate who says "they are a partner, so it is fine" — or who adds an approval step and keeps the internal runners — has missed both halves.