pipeline-hardening

Harden CI/CD pipelines with OIDC federation, artifact signing, and SLSA provenance controls.

Updated Sep 10, 2026
One-click install
npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill pipeline-hardening-serpro-workshop-fortaleza
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pipeline-hardening
Source: https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula/tree/main/.github/skills/pipeline-hardening
Command: npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill pipeline-hardening-serpro-workshop-fortaleza

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? CI/CD pipelines are a prime attack target: long-lived cloud secrets get stolen from logs, third-party actions get compromised, and artifacts get tampered with between build and deploy. This Skill provides a prioritized, threat-model-driven checklist to secure GitHub Actions, Azure DevOps, or GitLab pipelines and reach SLSA compliance levels. ## Core Features & Use Cases - Threat-Model-Based Controls: Addresses five concrete threats (stolen secrets, malicious dependencies, compromised actions, tampered artifacts, privilege escalation) with controls ordered by ROI across three maturity levels. - Concrete Hardening Checklist: Covers OIDC federation instead of long-lived secrets, SHA-pinning third-party actions, least-privilege permissions: blocks, SBOM generation, Cosign signing, SLSA provenance, and deploy-time signature verification. - Structured Audit Report: Produces a standardized hardening report table mapping each control to its status and evidence, plus a target SLSA level and blocking gap count. - Use Case: A team migrating from stored AZURE_CLIENT_SECRET credentials to OIDC federation can invoke this Skill to audit every workflow, pin floating action tags, and produce a gap report toward SLSA Level 2. ## Quick Start Audit our GitHub Actions workflows for security gaps and produce a hardening report targeting SLSA Level 2.

Frequently Asked Questions about pipeline-hardening

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate GitHub Actions from secrets to OIDC?

Replace long-lived cloud credentials stored as repository secrets with OIDC federated identity, which issues short-lived tokens per workflow run. This eliminates the risk of stolen `AWS_ACCESS_KEY_ID` or `AZURE_CLIENT_SECRET` values leaking from logs or compromised runners.

How do I reach SLSA Level 2 or 3 for my pipeline?

Start with Level 1 controls: OIDC auth, SHA-pinned actions, least-privilege permissions, and branch protection. Then add SBOM generation, Cosign artifact signing, and SLSA v1.0 provenance attestations, verifying signatures at deployment time.

Why should GitHub Actions be pinned by SHA instead of tags?

Tags like `@v3` or `@main` are mutable, so a compromised third-party action can silently change what your workflow executes. Pinning to a commit SHA with a version comment guarantees the exact reviewed code runs every time.

What permissions block should a GitHub Actions workflow use?

Every workflow should declare an explicit `permissions:` block defaulting to `contents: read`, elevating scopes only where a specific job requires them. Avoid `permissions: write-all`, which enables privilege escalation if any step is compromised.

How do I verify container image signatures before deployment?

Sign images at build time with Cosign, preferably keyless via OIDC, and publish the attestation alongside the artifact. The deployment job must then verify the signature and reject any unsigned or tampered artifact before rollout.