Secrets and Pipeline Security

• A pipeline runs code with credentials
• Whoever can change what it runs can steal what it can reach

• Secret store (Vault, AWS Secrets Manager, GCP Secret Manager): central, with access policy, audit log, rotation
• CI variable (GitHub Actions secrets, GitLab masked variables): encrypted at rest, injected as an env var
• Log masking hides only the exact string

• echo a secret to the log
• Bake it into an image or artifact
• Pass it in command-line args
• Trust masking: base64 or split values bypass it

• Static cloud keys in CI never expire
• They leak through logs and forks
• Rotation is manual
• OIDC: no stored key, only short-lived credentials

• IAM role trusts token.actions.githubusercontent.com
• Condition: sub = repo:org/app:environment:prod

• Set permissions: contents: read at the top of the workflow
• Grant write scopes only on the one job that needs them

• Protected branch: PR review, passing status checks, signed commits, no force pushes
• Protected environment (prod): required reviewers, branch restrictions
• Secrets are environment-scoped, not repo-wide

• Risks: compromised dependency, typosquatting, dependency confusion
• Also: tampered action or image, poisoned build output

• Commit lockfiles with hashes: npm ci, pip install --require-hashes
• Pin actions to a full commit SHA, images to a digest
• Never a mutable tag: @v3, :latest

• SBOM (SPDX or CycloneDX): machine-readable inventory of every component
• Keyless cosign signing uses an OIDC identity; signature goes to the Rekor log

syft app:1.0 -o spdx-json > sbom.json
grype sbom:sbom.json
cosign sign reg/app@sha256:abc
cosign verify reg/app@sha256:abc \
 --certificate-identity ID \
 --certificate-oidc-issuer URL

syft lists, grype finds vulnerable versions, verify before deploy

• Fork PR code is untrusted: it can edit the workflow, scripts and tests
• Running it with secrets = remote code execution

• Pwn request: pull_request_target + actions/checkout of PR head + running its code
• Attacker gets your secrets and write token

• Require maintainer approval for first-time contributors

• Keep secrets in a secret store, scoped per environment
• Prefer short-lived or dynamic secrets
• Never print them; rotate on leak

• Job needs permissions: id-token: write
• Trust policy pinned to repo + branch or environment
• Check aud; use no static cloud keys

permissions:
  contents: read
jobs:
  deploy:
    permissions:
      id-token: write
      contents: read

read-only by default, widen per job

• Ephemeral runners
• Protected branches: reviews, checks, no force push
• Protected environments with reviewers