My CI/CD configuration file got exposed. What should I do?

01Identify what was exposed

CI/CD config files vary by platform, but the types of credentials found in them are consistent. Work through the exposed file and catalogue everything sensitive:

• Deploy keys and SSH private keys — used to push deployments to servers. If present as inline values (e.g., echo "$DEPLOY_KEY" > ~/.ssh/id_rsa where DEPLOY_KEY was set to the literal key value), they're exposed.
• Cloud provider credentials — AWS AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, GCP service account keys, Azure service principal credentials set inline rather than as platform secrets.
• API tokens — package registry tokens (npm, PyPI, Maven), Docker Hub credentials, Slack or PagerDuty notification tokens.
• Docker registry passwords — credentials for logging in to push built images: docker login -u user -p password registry.example.com.
• Encrypted Travis CI values — if you see secure: … entries in .travis.yml, those are Travis-encrypted and safe. Plain values are not.

02Revoke all exposed tokens in the CI/CD platform and providers

Go to each relevant service and revoke the exposed credential. Here are the paths for common providers:

• Travis CI — Settings > Environment Variables > delete the exposed variable and recreate it with a new value. Also check Settings > SSH Key if a deploy key was configured there.
• CircleCI — Project Settings > Environment Variables > delete and recreate. For SSH keys: Project Settings > SSH Keys > remove the old key.
• GitHub Actions — Repository Settings > Secrets and variables > Actions > delete and recreate the affected secrets.
• Jenkins — Manage Jenkins > Credentials > find and delete the exposed credential, then create a replacement.

Also revoke directly at the service that issued the credential: deactivate the AWS IAM key, regenerate the Docker Hub access token, revoke the npm publish token, and so on.

03Remove credentials from config files and use encrypted env vars

Every CI/CD platform provides a way to store secrets that are available to pipeline jobs but never visible in the config file. Replace any hardcoded value with a reference to the platform-stored secret:

jobs:
  deploy:
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-1

For maximum security, prefer OIDC federation over static credentials: GitHub Actions can authenticate to AWS and GCP using a temporary token tied to the specific workflow run, with no static secret ever stored.

04Review pipeline logs for credential misuse

Your own CI/CD pipeline may have been the first place the credentials were used inappropriately — if a pull request from a fork triggered a build, the credentials could have been exfiltrated via a malicious build step. Check recent pipeline runs:

• Travis CI — by default, encrypted environment variables are not available to pull request builds from forks. Verify your settings.
• GitHub Actions — secrets are not passed to pull request workflows from forks by default, but pull_request_target events are an exception — check your workflow triggers.
• Look for pipeline runs that included unexpected network calls, file exfiltration (curl or wget to external IPs), or credential printing (accidental echo $SECRET in logs).

05Audit deployed environments for backdoors

If deploy keys or cloud credentials were exposed, an attacker may have used them to push to your production environment. Review what was deployed during the exposure window:

Also check your cloud environment for new resources created during the exposure window (new EC2 instances, IAM users, S3 buckets). Review your container registry for any images pushed that you didn't build, and check your deployed servers for new cron jobs, user accounts, or modified files.