GitHub Security Audit: Find Leaked Secrets, Overprivileged CI/CD, and Fake Contributors in 30 Minutes

Every Web3 team — from solo devs shipping a DeFi protocol to DAOs managing multi-sig governance — shares one attack surface: GitHub. Leaked private keys, overprivileged CI/CD workflows, rogue collaborators, and hardcoded RPC URLs are all sitting in repos right now. This tutorial shows you how to find them before an attacker does.

Note: All tools in this tutorial are open-source and available in The Red Guild's DevSecOps-toolkit container. If you want a zero-install experience, run make exec and follow along.

Phase 1: Secrets Scanning with Trufflehog

The most common GitHub vulnerability: secrets committed to version control. Private keys, API tokens, Infura/Alchemy URLs, wallet mnemonics — they all end up in git history eventually. Trufflehog scans every commit, every branch, and every file for high-entropy strings and known secret patterns.

Basic scan against a public repo

# Scan a remote GitHub repo for secrets
trufflehog github --repo=https://github.com/your-org/your-repo --only-verified

# Scan your entire GitHub org (requires PAT with repo scope)
trufflehog github --org=your-org --only-verified

# Scan a local clone (faster, works offline)
git clone https://github.com/your-org/your-repo
trufflehog filesystem ./your-repo --only-verified

What to look for

• Private keys (0x... / ed25519 / secp256k1) — immediate rotation required if found. Even if the repo is private, assume compromise.
• RPC URLs with embedded API keys — your Infura/Alchemy key exposed means an attacker can drain your request quota, enumerate your addresses, or front-run your transactions.
• CI/CD secrets echoed in logs — Trufflehog scans GitHub Actions logs too. A printenv in a workflow file is a gold mine for attackers.
• SSH private keys and .pem files — often committed by accident during infra-as-code setup.

Integrate into CI/CD

# .github/workflows/secrets-scan.yml
name: Secrets Scan
on: [push, pull_request]
jobs:
  trufflehog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # scan full git history
      - uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          base: ${{ github.event.before }}
          head: ${{ github.event.after }}
          extra_args: --only-verified

Phase 2: GitHub Permissions Audit with Legitify

Overprivileged GitHub orgs are the norm, not the exception. Legitify checks your org, repos, and members against security best practices — no write access to default branches, no stale admins, branch protection enabled, signed commits required.

# Scan an entire organization
legitify analyze --org your-org --token $GITHUB_TOKEN

# Scan a single repository
legitify analyze --repo your-org/your-repo --token $GITHUB_TOKEN

# Common findings you'll see:
# - "Default branch is not protected"
# - "Organization does not enforce two-factor authentication"
# - "Repository allows force pushes to default branch"
# - "Admin permissions are granted to too many members"

Prioritize these fixes

1. Enable 2FA org-wide — if Legitify reports this, fix it immediately. No exceptions for bot accounts (use fine-grained PATs instead).
2. Branch protection on main/master — require PR reviews, dismiss stale reviews on new commits, block force pushes.
3. Audit admin access — anyone with admin on a repo can bypass branch protection. Keep it to 2–3 people max.
4. Require signed commits — prevents commit spoofing and makes attribution verifiable.

Phase 3: Contributor OSINT with GitXRay

Not every contributor is who they claim to be. GitXRay analyzes contributor patterns — commit frequency, account age, repo associations, and behavioral anomalies. Useful for spotting fake contributors (a known attack vector in Web3 where malicious PRs get merged by compromised or planted accounts).

# Analyze a repo's contributors
gitxray repo --url https://github.com/your-org/your-repo

# Check a specific user's activity across GitHub
gitxray user --username suspicious-dev

# Look for:
# - Accounts created in the last 30 days pushing to critical repos
# - Users with no other public activity suddenly submitting complex PRs
# - Multiple accounts with overlapping commit patterns (sock puppets)

Phase 4: Sensitive File Exposure with Octoscan

Octoscan searches repos for accidentally committed sensitive files — .env files, database dumps, wallet files, SSH configs, kubeconfigs, and anything else that shouldn't be in version control.

# Scan a remote GitHub repository
octoscan --repo https://github.com/your-org/your-repo

# Scan a GitHub organization (requires PAT)
octoscan --org your-org --token $GITHUB_TOKEN

# What Octoscan catches that Trufflehog might miss:
# - .env files (even without secrets, reveals architecture)
# - terraform.tfstate (infrastructure map)
# - .git/config with embedded credentials
# - kubeconfig files with cluster access
# - Hardhat/Foundry config with deployer keys

Putting It All Together: The 30-Minute Audit

Here's a battle-tested workflow for rapid GitHub security audits. Run these in order:

Delta V Hardening Addendum

Beyond the open-source toolkit, Delta V recommends these additional checks for Web3 teams:

• Deployer key isolation. The key that deploys contracts should never touch a GitHub Actions secret. Use hardware wallets for mainnet deployments.
• Multi-sig for admin actions. Even if your GitHub org is compromised, contract upgrades should require multi-sig — not a single EOA whose key was in an env file.
• CI/CD sandboxing. Build and test in ephemeral environments. Never let a CI runner have access to production RPC endpoints or deployer keys.
• Commit signing audit trail. Every merge to main should be a signed commit from a verified identity. No unsigned merges, period.