Secrets in CI/CD: why your pipeline is the crown jewels
GitHub Actions with AWS keys in a forkable repo is game over. Secure patterns for small teams deploying multiple times daily.
The Hacker News regularly reports secret exfiltration from compromised CI — malicious contributor PR, workflows with excessive permissions, logs printing env vars. SMBs with private GitHub/GitLab repos in San Juan are not immune; attackers hunt AWS keys in minutes with bots.
Hard rules: secrets only in native store (GitHub Secrets, OI
Hard rules: secrets only in native store (GitHub Secrets, OIDC to AWS — no long-lived keys), workflows with minimum permissions (contents read default), ban dangerous pull_request_target without security review, branch protection on main requiring checks.
Use OIDC federation for AWS and cloud — ephemeral credential
Use OIDC federation for AWS and cloud — ephemeral credentials per job, scoped to deploy role. Rotate secrets if they ever appeared in log or commit (git history never forgets). Gitleaks or trufflehog in pre-commit/CI — cheap baseline.
Separate pipelines: fork PR gets no secrets; deploy only from main with environment protection and approvers. For sensitive test data, use synthetic fixtures — never prod copy in public artifact.
Secure CI/CD does not slow velocity — it stops Sunday incidents when someone finds your key on Shodan because a workflow echoed $AWS_SECRET_ACCESS_KEY. OWASP CI/CD Security Cheat Sheet is one hour reading with permanent return.
Writes about practical cybersecurity for SMBs in Puerto Rico and the Caribbean — no fluff, just what actually needs to get done.
