Branch protection covers main, but CI runs a credentialed job on every branch push. How do you map and close the PPE paths?

### Name the exposure first On a settlement-service monorepo at a bank, every engineer has repository write access, and the pipeline builds every branch with the credential it needs to publish artifacts. Branch protection on the default branch is doing exactly what it was designed to do — nothing merges without review — and it is irrelevant to this attack. A low-privilege insider edits the build script on a feature branch, pushes, and their code runs on the CI host with that credential before any human opens the pull request. The attacker position is an authenticated insider with legitimate commit rights; the asset is the build credential and, downstream of it, money movement. No outside access is required at any point. ### The reachability table The systematic version of the question is: for each way this pipeline can start, who can cause it, and what does the resulting job execute and hold? Write it down. | Trigger | Who can cause it | What code it executes | What the job holds | | --- | --- | --- | --- | | Push to default branch | Anyone whose PR merges | Reviewed content | Publish credential | | Push to any feature branch | Any contributor with write | Unreviewed content from that ref | Same credential — the finding | | Push to `release/*` | Any contributor, if unprotected | Unreviewed content | Release credential | | Tag push | Anyone who can create a tag | Content at that tag | Usually the strongest credential | | Path-filtered docs-only run | Any contributor | The whole checked-out tree | Whatever that job holds | | Scheduled run | Nobody directly; fires on default branch | Whatever is merged | Often long-lived credentials | | Manual dispatch | Whoever holds the run permission | Depends on the ref chosen | Depends on the job | Two rows are the ones teams get wrong. **Tag and release-branch pushes** frequently carry the most powerful credential in the estate while being governed less strictly than the default branch — protect the ref patterns, not just the one branch. **Path filters** are not a security boundary: a docs-only filter decides whether the job starts, not what it may execute once it starts, and the job still checks out the whole tree. Skipping CI is also not the same as being safe — it changes only whether the payload runs *now*. Scheduled runs are the mirror image. They cannot be reached from a feature branch, so they are not a PPE path — but they run the default branch with long-lived credentials on a cadence, which makes them the thing an attacker aims at *after* getting something merged. ### Closing it Procedural answers do not hold. Telling everyone to review build-script changes carefully depends on a human noticing six lines in a file they have no context for, and it does nothing about the ordering problem — the job already ran. The structural fixes, in the order they buy the most: 1. **Split trust in the pipeline.** One job compiles and tests arbitrary refs with a read-only token, no secrets, and no ability to publish. A second job does the privileged work, and is reachable only from a protected ref, behind an approval gate that records who approved. 2. **Scope the credential to the ref.** Where the platform supports federated short-lived identity, condition the trust policy on the ref, so a token issued to a feature-branch run cannot publish at all. This turns the whole class from a breach into a failed authorisation. 3. **Protect the ref patterns that matter.** Tag creation and `release/*` need the same governance as the default branch, or better, because their jobs hold more. 4. **Ephemeral runners.** A poisoned job on a reused runner leaves credentials, caches and processes for the next tenant. Destroy the machine after each job. 5. **Path-scoped required review on files the build executes.** This is a real control, but it is the last one on the list because it is the one that depends on a person. ### Verifying rather than assuming Do not take the pipeline definition's word for it. Take a token or a secret that the credentialed job holds and check where it can actually be used from — then push a harmless branch that prints the identity the job assumed, and confirm it is the unprivileged one. The table is a hypothesis; the run is the evidence. ### Detective controls, clearly labelled as such After the structural work, alert on credential use from an unexpected ref, on egress from build jobs to unknown destinations, and on the first appearance of build-affecting file changes in a branch that has no reason to carry them. These are backstops. They fire after the code has run, and they are worth having only because prevention is never complete — never in place of it.