You need every service's pipeline to run a security scan, a license check, and require signed artifacts before deploy. How do you enforce that across a hundred repositories without ending up with a hundred slightly different pipeline files?

Short answer

Ship the gates as a shared, versioned pipeline template that repositories include rather than copy, so an update to the check propagates everywhere at once and drift is visible instead of silent.

Copy-paste is the mechanism, not just a symptom

The moment a compliance requirement is expressed as "add this YAML block to your pipeline file," it will diverge. Someone copies the block into a hundredth repository slightly out of date because that's what the last repository they touched had. A team disables a check temporarily to unblock a release and forgets to re-enable it. Six months later, a hundred pipelines that started identical have a hundred subtly different versions of the same gate, and updating the check — because the scanner shipped a new ruleset, or a regulation changed — means touching a hundred files individually, some of which nobody remembers how to find.

This isn't a discipline problem solvable by better documentation. It's a direct consequence of the enforcement mechanism being copied text rather than a shared, referenced thing. The fix has to change what gets distributed: not the check's implementation, but a reference to a version of it that lives in exactly one place.

Centralising the gate as an included template

Most CI platforms support some form of reusable, centrally maintained pipeline definition — a shared workflow, a template job, a composite action — that an individual repository's pipeline includes by reference rather than by copying its contents. A repository's own pipeline file becomes short: it names which shared template to run and supplies whatever parameters are genuinely specific to it, such as which directory to scan.

# A repository's pipeline references the shared gate by version.
# It does not contain the scan logic, license rules, or signing steps itself.
jobs:
  compliance-gate:
    uses: platform-org/pipeline-templates/.github/workflows/compliance-gate.yml@v3
    with:
      scan-path: ./src

Updating the security scanner's ruleset, adding a new license to the disallowed list, or fixing a bug in how the signature check works now means changing one file in one repository, pipeline-templates, and the change reaches every repository referencing that version the next time their pipeline runs. This is the entire mechanism: the enforcement point moved from a hundred copies to one source, and every consumer became a pointer rather than an independent implementation.

flowchart TD
    A[compliance-gate.yml v3<br/>in pipeline-templates] --> B[repo-1 references v3]
    A --> C[repo-2 references v3]
    A --> D[repo-3 references v2<br/>hasn't upgraded]
    E[Security team updates<br/>ruleset in v4] --> F[repos on v3, v2<br/>unaffected until they bump]

The edge worth noticing in that diagram is repo-3 still on v2. Versioning the template means an update doesn't force itself on every consumer instantly, which is deliberate — a breaking change to the gate shouldn't be able to break a hundred pipelines simultaneously — but it also means version pinning is itself a form of drift that needs tracking, just a visible and queryable one instead of a silent one.

Deciding what blocks versus what only reports

Not every finding should stop a merge. A security scan that returns a genuine critical vulnerability in a direct dependency is a reasonable thing to block on. A license check flagging a dependency under a license the legal team hasn't reviewed yet is a finding that needs a human decision, and blocking every merge on it produces a queue of PRs waiting on legal rather than a safer codebase. The gate mechanism needs both a hard-fail mode and a report-and-continue mode, and the decision of which mode applies to which check belongs to whoever owns the compliance requirement, not to whichever engineer wired up the pipeline.

Building in an explicit, auditable exception path matters for the same reason a golden path needs an escape hatch: a gate a team cannot get past for a legitimate reason will get bypassed some other way — disabling the whole workflow, merging directly to the default branch — and that bypass is invisible to the platform team unless the exception itself is a tracked, reviewed thing rather than an ad hoc workaround.

Finding drift instead of only preventing new drift

Centralising the template prevents new drift for repositories that adopt it, but a hundred existing repositories don't migrate simultaneously, and some will fall behind on template version or quietly override a step locally even after adopting the shared reference. A periodic scan across every repository's pipeline configuration — checking which template version each references, and whether any repository has added local overrides that bypass a step the template defines — turns invisible fleet-wide drift into a list the platform team can act on, the same way an unresolvable owner in a service catalog needs to be surfaced rather than assumed away.

The gate itself is the easy part; what actually determines whether a hundred repositories stay compliant a year later is whether drift from the shared template is visible or silent.

© 2026 Preptima. Originally published at preptima.com.