How does API key token leakage work? Practical Secrets Management from GitHub to CI/CD

"I pushed my AWS access key to GitHub"
"CI environment variables were logged"
"The API key used by the retiree was still valid."

It is often dismissed as an "inadvertent mistake", but the essence is different.
It cannot be prevented by simply "preventing leakage". It is important to create a system based on the premise that it will leak.

1. 4 Ways Secrets Leak

Path (1): Incorrect commit to Git repository

This is the most common route.
Typical examples include forgetting to add the '.env' file to gitignore, hardcoding, etc.

What's especially scary is that once a Secret is committed, it will remain in git history even if it is deleted.

Pathway (2): CI/CD Log Output

When using Secrets with GitHub Actions, Jenkins, etc., the output of the command may remain in the log.

bash

# Dangerous examples
echo "Connecting with token: $API_KEY"
curl -H "Authorization: Bearer $API_KEY" ...

Pathway (3): Embedding in Container Image

A case where you pass Secrets at build time in a Dockerfile and include them in the image as they are.

Path (4): Paste into Slack or Docs

A case where you "share in a hurry" and paste the API key directly into Slack DM or Notion.

2. Prevention: How Secrets "Don't Put in Code"

Detection with Git pre-commit hook

Introduce a tool to auto-scan before commit.

Typical tools:

• git-secrets (AWS)
• detect-secrets (by Yelp)
• truffleHog

bash

# Example of setting up detect-secrets
pip install detect-secrets
detect-secrets scan > .secrets.baseline
# Add to .git/hooks/pre-commit

Using Secrets Management Tools

Don't write Secrets in your code, but design them to get them from a dedicated management tool.

Typical Services:

• AWS Secrets Manager
• Azure Key Vault
• HashiCorp Vault
• GCP Secret Manager

3. Detection: Quickly Discover Leaked Secrets

Prevention alone is not enough. There is also a need for early detection mechanisms in case of leakage.

Secret Scanning on GitHub

GitHub has a feature called Secret Scanning, which automatically detects and notifies Secrets (AWS keys, GitHub PATs, etc.) contained in pushed code.

We recommend enabling it for private repositories as well (GitHub Advanced Security required).

Periodic Repository Scanning

Periodically scan your existing codebase for past Secrets.

bash

# Scanning the entire repository by truffleHog
trufflehog git https://github.com/your-org/your-repo.git

4. Rotation: A system that can be "disabled immediately" if it leaks

When Secrets leak, the most important thing is the speed of response after discovery.

Key points for system development:

• Manage an inventory of all Secrets (which Secrets are used on which system)
• Create a rotation procedure in advance
• Set up regular automatic rotation (e.g. 90 days)
• Practice emergency deactivation procedures (manual and automatic)

5. Secrets Management in CI/CD

Best practices in GitHub Actions:

yaml

# Good example: Secrets from GitHub Secrets
steps:
  - name: Deploy
    env:
      API_KEY: ${{ secrets. API_KEY }}
    run: |
      # Do not output to logs
      deploy.sh

Notes:

• Do not output Secrets variables with 'echo'
• Do not enable debug mode (ACTIONS_STEP_DEBUG) in production CI
• Minimize the scope of Secrets on a per-job basis.

6. Colorkrew Security's Approach

The Secrets management system is not "introduction and end", but requires continuous operational design from inventory maintenance, regular rotation, and immediate disabling in case of incidents. If you don't know how to manage it for your environment or want to check your existing repositories for leakage, an expert design review is the most reliable and fast solution.

Colorkrew Security provides design assistance and security reviews for DevSecOps, including Secrets management. Please feel free to contact us first.