Project maintainers control their own .gitlab-ci.yml, but security requires a scan job in every pipeline. How do you actually enforce that in GitLab, and what does that cost the teams?

## Why an `include:` is not a control The first answer everyone gives is "publish a template and have everyone include it": ```yaml include: - project: 'platform/ci-templates' ref: 'v2.3.0' file: '/security-scans.yml' ``` This is fine as a *convention* and useless as a *control*, because the thing that would remove it — deleting a line from `.gitlab-ci.yml` — is precisely what the project's maintainers are allowed to do. Worse, it can be defeated without deleting anything: redefine the included job locally with an empty script, or override its `rules:` so it never matches. Array keys are replaced, not merged, so `rules: [when: never]` in the consuming project silently disables the mandated job. The design principle is the same as elsewhere in delivery: **the enforcement point must be outside the artefact being enforced upon.** Client-side git hooks cannot enforce policy for the same reason. ## GitLab's mechanism: own the root of the pipeline GitLab's answer inverts the include direction. Instead of the project including the mandated jobs, the mandated configuration becomes the pipeline's root and includes the project: ```yaml # .compliance-gitlab-ci.yml, in a project only the platform team can write to include: - project: '$CI_PROJECT_PATH' file: '$CI_CONFIG_PATH' ref: '$CI_COMMIT_REF_NAME' secret-detection: stage: test script: - run-secret-scan ``` This file is attached to a **compliance framework** defined at the group level and applied to projects. When a pipeline runs in a labelled project, GitLab uses this file as the configuration rather than the project's own, and the project's `.gitlab-ci.yml` participates only because the compliance file includes it — via the predefined variables for the project path, its configured CI file path and the branch being built. Remove your include of the security template and nothing changes; the scan still runs, because it was never yours to remove. The framework label itself is managed from the group, so a project cannot detach. Newer GitLab versions move this capability into **pipeline execution policies** under security policies: the same injection, expressed as a policy scoped to groups or projects, with the policy project separately protected. The compliance-pipeline configuration route has been deprecated in favour of it, so a current answer should name both and say which your version supports. ## What it costs A principal-level answer has to price this, because the mechanism is powerful enough to be resented. **Predictability.** A team can no longer read its repository and know what its pipeline does. The merged-configuration view in the pipeline editor becomes essential, and "why is there a job I never wrote?" becomes a recurring question. **Failure ownership.** The injected job fails on someone else's merge request. If the platform team ships a scanner change on Friday, fifty teams are blocked and none of them can fix it. That argues hard for versioning the mandated configuration, rolling it out gradually, and running new mandated jobs as non-blocking before they gate merges. **Resource and time budget.** Mandated jobs consume the project's CI minutes and runner capacity and add to every pipeline's wall-clock time. A scan that adds four minutes to a twelve-minute pipeline is a 33% tax on iteration speed, paid by every team, forever. **Escape hatches.** Real programmes need exceptions — a documentation repository does not need a container scan. Model that inside the mandated configuration with `rules:` on the injected jobs, or with separate frameworks per risk tier. Do *not* model it by letting projects opt out, or you are back to a convention. **Bypass surface.** Even with injection, ask what a determined project can still do: shrink the scope the scanner sees, or arrange for the job to pass trivially. Enforcement of *presence* is not enforcement of *effectiveness*, and the report needs to be collected centrally rather than trusted from the job's exit code. ## The layered answer In practice you use more than one control, matched to how much you need to trust the project: - **Convention** — a published, versioned template teams include voluntarily. Cheap, high adoption, zero enforcement. Right for conventions like a standard build. - **Review gate** — CODEOWNERS on `.gitlab-ci.yml` plus a protected branch and required approvals, so changes to the pipeline need the platform team's sign-off. Enforces *scrutiny*, not presence, and depends on humans. - **Injection** — compliance framework or pipeline execution policy. The only one that survives a hostile or careless maintainer. - **Detection** — independent verification that the scan actually ran and produced a report, since injection guarantees a job ran, not that it meant anything. The answer an interviewer is listening for is that you reach for injection *only* for the small set of genuinely mandatory controls, keep everything else at the convention layer, and are explicit about who gets paged when the mandated job breaks the whole organisation's merges.