Quick take: Secrets in pipeline logs are one of the fastest ways to compromise a system. Store secrets in a dedicated manager, inject them at runtime and never commit them to source control.
A developer added a database password to a GitHub Actions workflow file for convenience. Three months later, an ex-employee forked the repository and the password was still there. The credential had never been rotated. A proper secret manager and runtime injection would have prevented both the exposure and the long-lived credential.
The problem it solves
CI/CD pipelines need credentials for deployment, testing and integration. Storing those credentials insecurely creates persistent risk that is hard to detect and harder to clean up.
Core concepts
| Concept | What it is |
|---|---|
| Secret manager | A service that stores and controls access to sensitive values. |
| Runtime injection | Providing secrets to a pipeline step when it runs. |
| Secret rotation | Regularly changing credentials to limit exposure. |
| Masking | Hiding secret values in pipeline logs. |
| Least privilege | Granting pipelines only the credentials they need. |
Architecture
How it works
The pipeline authenticates to a secret manager using a short-lived identity. It retrieves the needed secret, injects it as an environment variable, uses it, and the value never appears in code or logs.
If a secret is leaked, rotation replaces it in the manager. Downstream consumers pick up the new value automatically.
Real-world scenario
The team implemented:
- GitHub repository secrets for CI-level values like API tokens.
- Azure Key Vault / AWS Secrets Manager for production credentials.
- Workload identity federation so pipelines had no long-lived secrets at all.
- Log masking and scanning for accidental secret exposure.
- Quarterly rotation for all non-federated credentials.
When a token was accidentally printed in a log, it was rotated within an hour and the incident was closed.
Advantages
- Reduces exposure of long-lived credentials.
- Centralized control over who and what can access secrets.
- Audit logs show every secret access.
- Faster incident response through rotation.
Disadvantages
- Extra tooling and initial setup.
- Rotation requires coordination with consumers.
- Wrong injection can still leak secrets to logs.
When to use it (and when not)
Use a secret manager for all production credentials. Use workload identity or OIDC where possible to eliminate static secrets entirely.
Never commit secrets to source control. Never pass secrets as plain workflow inputs.
Best practices
- Use OIDC/workload identity instead of long-lived pipeline secrets.
- Scope secrets to the job that needs them.
- Enable masking and audit logging.
- Rotate credentials automatically on schedule and on incident.
- Scan repositories and logs for secrets.
Secret management is not exciting until it fails. Build it well before that happens.