# Cicd Security > Harden GitHub Actions, GitLab CI, and similar pipelines against supply-chain attacks, secret exfiltration, and pwn-request abuse. Use when authoring or reviewing workflow files, adding a third-party action, image, or script, wiring cloud or registry credentials into CI, or triaging a suspected pipeline compromise. - Skill: `shieldnet-360/cicd-security` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add shieldnet-360/cicd-security` - Raw SKILL.md: https://api.skillmd.com/api/skills/shieldnet-360/cicd-security/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: ShieldNet-360 (https://skillmd.com/u/shieldnet-360) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/shieldnet-360/cicd-security --- # CI/CD Pipeline Security ## Rules (for AI agents) ### ALWAYS - Pin every third-party GitHub Action by **commit SHA** (full 40-char), never by a floating tag (`@v1`, `@main`, `@latest`) — tags can be re-pushed. The tj-actions/changed-files March 2025 incident exfiltrated secrets from 23,000+ repositories specifically because consumers used floating tags. Same applies to GitLab CI `include:` references and reusable workflows. Renovate / Dependabot can keep the SHA pins fresh. - Declare `permissions:` at the workflow or job level and default to `contents: read` only. Grant additional scopes (`id-token: write`, `packages: write`, etc.) job-by-job, never workflow-wide. - Use **OIDC** (`id-token: write` + cloud provider trust policy) for short-lived cloud credentials. Never store long-lived AWS / GCP / Azure keys as GitHub Secrets. - Treat `pull_request_target`, `workflow_run`, and any `pull_request` job that uses `actions/checkout` with `ref: ${{ github.event.pull_request.head.ref }}` as **trusted-context-on-untrusted-code** — the "pwn request" pattern documented by GitHub Security Lab. Either don't run them, or run with no secrets and no write tokens. A fork's GitLab merge-request pipeline is the same shape — it runs the fork's own `.gitlab-ci.yml` on your runners: isolate them, expose no protected variables. - Echo every untrusted expression (`${{ github.event.* }}`) through an environment variable first; never interpolate it directly into `run:` body — that's the canonical GitHub Actions script-injection sink. The GitLab sink has the same shape: `$CI_*` / `$TRIGGER_*` interpolated into `bash -c` or `eval`, where merge-request metadata carries the shell metacharacters. - Sign release artifacts (Sigstore / cosign) and publish SLSA provenance attestations. Verify provenance in any consumer pipeline that pulls the artifact. - Pin `runs-on` to a dated runner image (`ubuntu-24.04`), not a floating label (`ubuntu-latest`) — the label moves underneath you. On GitLab, use ephemeral Docker-executor runners with `privileged: false`; a shared shell runner with `privileged: true` gives a compromised job root on the host. An egress firewall on runners handling secrets (StepSecurity Harden-Runner or equivalent) is defense-in-depth on top of that, not a substitute. - Require a human reviewer on a dependency-bump PR when `supply-chain-security` raises a **trust-boundary** change — a maintainer or ownership change, a new or changed install hook, a registry or source transition, a provenance regression. Gate on that signal, not on the version number: a patch release that changes maintainer warrants more review than a major bump that does not. - Consult `supply-chain-security` before any dependency install step (`npm install`, `pip install`, `docker pull`) — in CI it is untrusted code execution on a runner holding your credentials. It owns install-script risk (`postinstall`, `setup.py`, `build.rs`) and registry pinning; `container-security` names the command that fixes the lockfile half (`npm ci`, `--frozen-lockfile`) rather than adding flags to `npm install`. ### NEVER - `curl | bash` (or `wget -O- | sh`) any installer script in CI. The 2021 Codecov bash-uploader compromise exfiltrated env vars to an attacker for ~10 weeks because thousands of pipelines ran `bash <(curl https://codecov.io/bash)`. Always download, checksum, then execute. - Echo secrets to logs, even on failure. Use `::add-mask::` for any computed-at-runtime secret, and double-check with the GitHub workflow-log search. - Cache mutable state (e.g. `~/.npm`, `~/.cargo`, `~/.gradle`) keyed only on `os`. A cache hit cross-job is a cross-tenant attack surface — key on a lockfile hash and scope to the workflow ref. - Trust artifact downloads from arbitrary workflow runs without verifying the source workflow + commit SHA. Build-cache poisoning works through unscoped artifact reuse. - Store secrets in repository variables (`vars.*`) — they are plaintext to anyone with read access. Only `secrets.*` are gated by the secret scanning + scope rules. GitLab's equivalent: a CI/CD variable without `protected: true` + `masked: true` is exposed to every feature-branch pipeline. ### KNOWN FALSE POSITIVES - First-party actions in the same organization that you mirror or fork in-house may legitimately be pinned by tag if the org enforces signed tags + branch-protection on the action repo. - Public-data pipelines that handle no secrets and produce no signed artifact (e.g. nightly link-checkers) don't need OIDC or SLSA provenance, and may use floating tags without practical impact. - `pull_request_target` is legitimate for label / triage bots that only call the GitHub API with the minimal scopes needed, do not check out PR code, and don't expose secrets in env. ## Context (for humans) CI/CD is now the most lucrative single supply-chain target. A pipeline runs trusted code against trusted credentials and trusted registries — compromising it once gives access to every downstream consumer of every artifact it produces. The 2021 Codecov compromise, 2021 SolarWinds incident, 2024 Ultralytics PyPI release-pipeline poisoning, and the 2025 tj-actions/changed-files mass exfiltration all hinged on unauthenticated changes to CI-consumed scripts or actions. Most of the defenses are mechanical: pin by SHA, minimize permissions, use OIDC, sign artifacts, verify provenance. The hard part is enforcing them across an organization. OpenSSF Scorecard automates checks for the mechanical defenses and integrates with branch protection. This skill emphasizes the design-pattern weaknesses (pwn requests, script injection, curl-pipe-bash, floating tags, untrusted artifact download) because they are the patterns AI-generated workflow YAML reinvents most often. ## References - `references/verifying-findings.md` — confirm or refute a finding, then lock it - `checklists/gitlab_ci_hardening.yaml` - [OpenSSF Scorecard](https://github.com/ossf/scorecard). - [SLSA v1.0 Build Track](https://slsa.dev/spec/v1.0/levels). - [GitHub Security Lab — Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). - [StepSecurity — tj-actions/changed-files attack analysis](https://www.stepsecurity.io/blog/tj-actions-changed-files-attack-analysis). - [CWE-1395](https://cwe.mitre.org/data/definitions/1395.html).