🔁 Secrets Management in CI/CD: How to Stop Hardcoding Credentials

Secrets Management in CI/CD: How to Stop Hardcoding Credentials

Hardcoding credentials in CI/CD pipelines is one of the most common — and most dangerous — security mistakes in modern software development. A single exposed API key in a GitHub Action YAML file can lead to a full infrastructure compromise. For robust secrets management, 1Password integrates directly with CI/CD pipelines to securely inject credentials without hardcoding them in your codebase.

The Scope of the Problem

Research shows that over 30% of organisations have accidentally committed credentials to source control. Automated scanners from GitHub, GitLab, and third-party services detect thousands of new credential leaks every day. The cost is severe: leaked AWS keys alone have been responsible for data breaches costing companies millions.

Why CI/CD Secrets Leak

CI/CD pipelines are especially vulnerable because they need credentials to:

• Authenticate to cloud providers (AWS, GCP, Azure)
• Push to container registries (Docker Hub, ECR, GCR)
• Deploy to production environments
• Access third-party APIs (Twilio, Stripe, SendGrid)
• Run database migrations

The pressure to make pipelines work quickly leads developers to hardcode credentials directly in CI configuration files, environment variable stanzas, or deployment scripts.

Best Practice: Dedicated Secrets Managers

Every major CI/CD platform has a built-in secrets manager. Use them instead of environment variables in pipeline definitions.

GitHub Actions:

name: Deploy
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to AWS
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: |
          aws s3 sync ./dist s3://my-bucket/

GitLab CI:

deploy:
  script:
    - aws s3 sync ./dist s3://my-bucket/
  variables:
    AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID  # Set in CI/CD Settings
    AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY  # Set in CI/CD Settings

CircleCI:

version: 2.1
jobs:
  deploy:
    docker:
      - image: cimg/python:3.11
    steps:
      - checkout
      - run: aws s3 sync ./dist s3://my-bucket/

All three platforms encrypt secrets at rest and mask them in logs automatically.

Preventing Secrets from Entering CI/CD

The best defence is preventing secrets from being committed in the first place. Use these tools:

1. GitHub Secret Scanning — enabled by default for public repos, available for private repos
2. GitLeaks — open-source tool that scans for secrets in git history
3. TruffleHog — entropy-based scanner that finds high-entropy strings
4. Pre-commit hooks — block commits containing potential secrets

Example pre-commit hook:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Short-Lived Credentials

Where possible, avoid long-lived secrets altogether. Use:

• AWS IAM Roles for OIDC — GitHub Actions can assume IAM roles directly without storing keys
• HashiCorp Vault dynamic secrets — generate credentials on-demand with TTL
• Terraform Cloud ephemeral workspaces — workspace credentials exist only during a run

Incident Response Plan

If a credential is leaked despite these precautions:

1. Immediately revoke the compromised credential
2. Rotate any credentials that shared the same permissions
3. Audit logs for unauthorised access using the leaked credential
4. Scan git history to ensure the credential is fully removed
5. Post-mortem to understand how the leak happened and prevent recurrence

The shift from hardcoded secrets to proper secrets management is one of the highest-impact security improvements a development team can make. It requires upfront configuration but prevents the most expensive class of security incidents.