How to Prevent Credential Leaks in CI/CD Pipelines

Pipelines leak credentials in three boring ways: a long-lived cloud key in GitHub secrets, a printenv in a debug step, and a token that landed in the Git history because someone committed .env. Scanners help. They do not replace short-lived identity.

Stop storing cloud keys in the workflow

GitHub Actions, GitLab, and Azure DevOps can all assume a cloud role with OIDC. The job gets a token that lasts minutes. There is no access key to rotate when a contractor leaves.

# GitHub Actions → AWS (sketch)
permissions:
  id-token: write
  contents: read
# Then aws-actions/configure-aws-credentials with role-to-assume.

• Scope the role to one repo and one environment. Production should not be assumable from a fork PR.
• Prefer environment protection rules (approvals) over a shared secret named PROD_KEY.
• Never echo $AWS_SECRET_ACCESS_KEY. CI logs are a public pastebin with extra steps.

Scan what actually ships

Trivy, gitleaks, and cloud-native secret scanners belong on the PR, not on a weekly dashboard nobody opens. Fail the job on high-confidence secrets. Teach the team to use git filter-repo if one already landed on main — rotating the key is the real fix.

What good looks like

• No IAM users created “for Jenkins”.
• A CloudTrail or Azure Activity Log line that names the GitHub repo’s OIDC role.
• A leaked-key runbook that starts with rotate, not with “we will be more careful.”