harden-gitlab-cilisted

# Harden GitLab CI Harden GitLab CI/CD pipelines against supply-chain attack: pin what runs, minimise what it can reach, and stop long-lived secrets from existing at all. > **GitLab-specific by design.** Like `harden-github-actions`, this skill is deliberately bound to one > forge. The controls are properties of the GitLab CI execution model — `include:` resolution, the > `CI_JOB_TOKEN` allowlist, project/group variable scoping, `id_tokens` — not portable concepts in > GitLab syntax. It is a **sibling** of `harden-github-actions`, not a translation of it: the two > forges differ in what the risks *are*, not merely in how they are spelled. ## When to Use - When adding a `.gitlab-ci.yml` to a project (after `setup-git-hooks`) - When auditing an existing pipeline before making a GitLab project public - When a supply-chain review (or the `supply-chain` skill) flags CI hardening gaps - When standardising pipeline hardening across GitLab projects **Not for:** GitHub Actions (use `harden-github-actions`) or Forgejo/Gitea Actions. The controls do not carry over — say so rather than approximating. ## Required Inputs 1. **Repository** — a GitLab project (auto-detected from git remotes). **Self-hosted GitLab is a first-class target**, not an exception: authenticate once and every control below is identical. 2. **Project visibility** — public/internal or private. Phases 3 and 4 branch on it: public and internal projects expose pipeline artifacts to unauthenticated users, and