cicd-hardeninglisted

# CI/CD Hardening ## When to use This skill treats the pipeline itself as the attack surface, not the code flowing through it. CI/CD compromise is a supply-chain incident: whoever owns the pipeline owns the release artifacts. Triggers on: - A question like "review our workflow files for security", "set up OIDC between GitHub and AWS", "why is `pull_request_target` dangerous", "pin all actions to SHA", "can we hit SLSA-L3". - New or changed `.github/workflows/*.yml`, `.gitlab-ci.yml`, Jenkinsfile, Azure Pipelines YAML, CircleCI config, reusable workflow definitions, composite actions. - An incident or near-miss: a forked PR could use secrets, a third-party action had a compromise, a self-hosted runner was abused. - A compliance audit asking for SSDF evidence or SLSA-level attestation. - A supply-chain moment where the pipeline is the last link before release (`supply-chain` skill calls in here for build-provenance setup). ### When NOT (handoff) - SAST in the pipeline → `sast-orchestrator` for tool choice and ruleset. This skill only decides that it runs somewhere in the workflow phase. - Secret scanning in the pipeline → `secrets-scanner`. Same split. - Dependency scanning and CVE triage → `cve-triage` and `supply-chain`. The gate logic is in `security-gate`. - Container build itself (Dockerfile, base image) → `container-hardening`. We only cover the workflow that builds it here. - Kubernetes deployment by a GitOps agent (Argo CD, Flux) → `k8s-security`. - Infrastructure