What criteria admit a third-party build step into an infrastructure pipeline that holds cloud admin credentials?

## Why the criteria start with blast radius A third-party step executes in your job with your job's identity. In an infrastructure pipeline that means the credentials that can create, modify and destroy cloud resources, and often the state file describing everything you run. The attacker position that matters here is not an anonymous internet user - it is a compromised upstream, or a maintainer whose account someone else now controls, arriving through a step your own engineers chose to add. The asset is the control plane, and the failure is not data theft but an attacker with the same power your platform team has. So the first question is never *is this step good*. It is *what would this step's worst version be able to do here*. That answer sets the bar; everything below is calibrated against it. ## The criteria **1. Does it need a secret at all?** This is the largest lever, and it is usually the fastest decision. Steps that lint, format, render a diagram or compute a diff need nothing. Put them in a job with no credentials and no write token, and the review becomes shallow because the worst case is a wasted build minute. A surprising share of the third-party steps in a pipeline can be relocated this way, which frees the reviewers for the few that cannot. **2. Who publishes it, and how?** An organisation with multiple maintainers, a public release process and a security contact is a different proposition from a personal account with one maintainer and ad-hoc tags. This is not about trusting a badge - a verified-publisher marker says an identity was checked, not that anyone read the code. What you are looking for is whether a single compromised individual can ship to you unreviewed. **3. Can you actually read it?** At the revision you intend to pin, is the source small enough that a reviewer will genuinely read it, or is it a large prebuilt bundle compiled from a tree that is not in the repository? If nobody can read it, you are not reviewing, you are hoping. That is acceptable for a zero-credential job and not acceptable next to cloud admin credentials. **4. What does it do at run time?** Does it download a payload, install a toolchain, contact a telemetry endpoint, write outside the workspace, read environment variables it has no business reading? A step that fetches code at run time drags an unpinned dependency into the highest-privilege job you own; treat that as close to disqualifying at this tier. **5. Is it alive, and is it pinnable?** Release cadence, whether security reports get answered, whether there is a stable revision to pin. An abandoned step is not neutral: when it breaks or a vulnerability lands in it, nobody upstream will fix it. **6. Is there a first-party alternative?** Many popular steps wrap a handful of commands. Owning those lines yourself removes an entire trust relationship at a cost you can measure in an afternoon. The honest comparison is *our maintenance* against *their unreviewed change*, not *free* against *effort*. ## Applying it Take three candidates for the same pipeline. - A formatting or policy check that reads files and reports. Needs no secret. Admit it, pinned, in a job with no credentials, with a light review. - A step that posts the planned change back to the pull request. It needs a write token. Admit it only with a narrowly scoped, short-lived token, in a job that never sees cloud credentials, and read its source at the pinned revision. - A step that would perform the actual apply against the cloud account. Highest bar. Prefer a first-party script; if you keep the third-party step, keep the credential acquisition in a step you own and hand the third-party step only the outputs it needs. Notice the pattern: most of the decision is not *yes or no*, it is *where does this run and what does it hold*. Splitting the pipeline so that privileged work sits in jobs with no third-party code is often cheaper than reviewing that code. ## Making it stick A decision that is not recorded gets re-litigated, and a decision that is never re-taken becomes a rubber stamp. Record for each admitted step: who reviewed it, at what revision, into which job tier, and when it is reviewed again. Pinning to a digest is what makes re-review possible at all - the new version arrives only when someone bumps the pin, so the bump is the natural review point. If bumps are automated, route the ones touching privileged jobs to a human and let the zero-credential tier flow through. The common failure is uniformity: applying the same heavyweight review to every step until reviewers stop reading, or the same light one until something with real reach slips in. Tier the bar by what the job holds, and most of the estate becomes cheap to govern.