What does a team lose by copy-pasting a shared CI pipeline template instead of referencing a versioned one?

## What a shared pipeline template is A platform or security team maintains one pipeline definition that encodes the controls every build is meant to have: dependencies resolved from an approved source, a scanning step, a build step running with a narrow token, and the stage that emits the artifact together with its SBOM, its provenance statement and its signature. A service then adopts it one of two ways. It can **reference** the definition — its CI config names the template and a version, and the platform team's copy is what actually runs. Or it can **copy** the text into its own repository. On adoption day the two are indistinguishable. Every day after that they diverge, and the divergence is the whole subject of this question. ## Direction one: fixes stop arriving The template is not finished. It gets narrowed when someone realises the build token was over-scoped; it gains an attestation stage; an unsafe interpolation of untrusted text into a shell step gets removed. Each of those is a security fix, and each reaches only the pipelines that resolve the template at build time. A copy is frozen at its cloning date and keeps running the old behaviour indefinitely. What makes this dangerous rather than merely untidy is that nothing fails. The copied pipeline goes green every day. Staleness in a pipeline has no natural symptom, so the drift is discovered by an audit, an incident, or not at all. A central fix therefore has a *distribution* problem, not an authoring problem — writing the fix is the easy half. ## Direction two: the platform team goes blind Copies are also invisible upward. Ask a platform team how many services sign their release artifacts and, in a copy-based estate, the honest answer is that nobody knows: the only way to find out is to read several hundred repositories. Worse, a copy is *editable*. Under deadline someone comments out the scanning step, or loosens a permission, and no reviewer with security context ever sees that change, because it happens inside a service repository where the reviewers are the service team. ## What a versioned reference buys - **One source of truth.** The control lives in one place, is reviewed by the people who own it, and is changed once. - **A version number as telemetry.** Every build can record which template version it resolved. Adoption becomes a query instead of a survey, and you can see the *distribution* of versions across the estate, not just presence. - **Deliberate upgrades.** Moving from one version to the next is a reviewable change with a changelog, not a manual re-copy nobody will ever perform. - **A deprecation lever.** A version can be marked end-of-life, then warned on, then failed. A copy offers no such handle. ## The tension to be honest about Referencing means the platform team can change what executes in your pipeline without your review. That is exactly the point, and it is also a genuine risk: the template is code that runs in every build, which makes it a single point of compromise. The answer is not to copy; it is to treat the template as production software — restricted write access, review on changes, its own tests, released versions, a changelog. Consumers then choose how tightly to bind, trading currency against stability, and the platform team keeps a way to move them forward. ## When a copy is legitimate Sometimes a service genuinely needs a shape the template cannot express. The first move is to contribute the capability upstream so the next team gets it too. If a copy really is the answer — an emergency, or a one-off build shape — make it an exception with a named owner, a recorded reason and a return plan, and count it in the adoption report as *not adopted* rather than quietly as a success. ## How this gets asked Interviewers usually pose it as a small concrete scene: your CI config was copied from the platform team a year ago, what is the risk. A weak answer talks about duplication and maintenance effort. A strong answer names both directions — fixes that never arrive, and edits nobody sees — and then says how you would measure which repositories are on which version.