Scope
This guide outlines immediate measures to secure GitHub repositories following the Megalodon campaign, which compromised over 5,500 repositories in six hours. You'll find detection workflows, credential rotation procedures, and automation configurations compatible with your existing CI/CD pipeline. This applies to organizations using GitHub Enterprise, GitHub.com, or self-hosted Git infrastructure.
Key Concepts and Definitions
Repository Compromise: Unauthorized modification of repository contents, settings, or access controls. In the Megalodon case, attackers injected malicious code to exfiltrate credentials and developer secrets.
Secrets Exposure: Any credential, API key, token, or certificate committed to repository history. These persist in Git history even after removal from current branches.
Automated Scanning: Continuous monitoring that inspects commits, pull requests, and repository configurations without manual review, using tools like pre-commit hooks and GitHub Actions.
Blast Radius: The scope of systems an attacker can access after compromising a single repository. With Megalodon, one infected repo could expose credentials for production databases, cloud accounts, and third-party services.
Requirements Breakdown
Compliance Context
PCI DSS v4.0.1 Requirement 6.3.2 mandates identifying and addressing common coding vulnerabilities during development. Secret exposure qualifies as a coding vulnerability. If your repositories interact with cardholder data environments, you need automated secret scanning before merging.
SOC 2 Type II CC6.1 requires logical access controls. Repository access tokens and SSH keys fall under this control. You must demonstrate that you detect and revoke exposed credentials within your defined incident response timeframe.
ISO/IEC 27001:2022 Annex A.8.3 covers handling of assets. Source code repositories are information assets. Your information security management system must address how you protect credentials within these assets.
Detection Requirements
Your scanning must catch:
- API keys and access tokens (AWS, Azure, GCP, GitHub PATs)
- Database connection strings
- Private SSH keys and certificates
- OAuth tokens and refresh tokens
- Webhook secrets and signing keys
Scan targets:
- Every commit before merge (pre-receive hooks)
- Existing repository history (retroactive scan)
- Pull request diffs
- Repository settings and webhooks
- Forked repositories under your organization
Implementation Guidance
Phase 1: Immediate Lockdown (Day 1)
Inventory your exposure. Run git log --all --pretty=format:"%H %an %ae" | wc -l across your repositories to understand commit volume.
Enable GitHub's secret scanning for all repositories. Navigate to Settings > Code security and analysis > Secret scanning. This detects known patterns for 200+ secret types but won't catch custom internal tokens.
Rotate all credentials that could have been committed in the past 90 days. Assume exposure and rotate:
- GitHub Personal Access Tokens (PATs)
- Deploy keys
- Service account credentials
- CI/CD secrets
Phase 2: Automated Prevention (Week 1)
Install pre-commit hooks on developer workstations. Use tools like git-secrets or gitleaks in local mode:
# .pre-commit-config.yaml
repos:
- repo: https://github.com/zricethezav/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
This blocks commits containing secrets before they reach your remote repository.
Configure branch protection rules. Under Settings > Branches, require status checks from your secret scanner before allowing merge. Set "Require status checks to pass before merging" and select your scanning workflow.
Deploy server-side scanning. GitHub Actions example:
name: Secret Scan
on: [push, pull_request]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- uses: gitleaks/gitleaks-action@v2
This creates a second layer after pre-commit hooks fail or get bypassed.
Phase 3: Historical Remediation (Week 2-4)
Scan repository history. For each repository:
gitleaks detect --source . --report-path findings.json
This generates a list of every secret ever committed.
Don't just delete and recommit. Secrets remain in Git history. Use git filter-repo or BFG Repo-Cleaner to rewrite history:
bfg --delete-files credentials.json repo.git
Warning: This rewrites commit hashes. Coordinate with your team before running.
Revoke everything you find. Create a spreadsheet: secret type, location, service, rotation status. Track until every exposed credential is rotated and verified disabled.
Phase 4: Monitoring and Response (Ongoing)
Set up alerts. Configure notifications when secret scanning detects new exposures. Route them to your security team's incident queue.
Define response SLAs. Example policy:
- Critical secrets (production database, AWS root): Rotate within 1 hour
- High secrets (service accounts, API keys): Rotate within 4 hours
- Medium secrets (development credentials): Rotate within 24 hours
Audit access regularly. Run gh api /orgs/{org}/repos --paginate | jq '.[].permissions' monthly to identify repositories with overly broad access.
Common Pitfalls
Scanning only new commits. Megalodon-style attacks exploit secrets committed months ago. Scan your full history, not just recent changes.
Trusting client-side controls alone. Developers disable pre-commit hooks when they're in a hurry. Server-side validation is mandatory.
Ignoring forked repositories. When a developer forks your private repo, they copy its entire history. Scan and monitor forks under your organization.
Using generic regex patterns. Custom internal tokens need custom detection rules. If your API keys follow a format like INTERNAL_[A-Z0-9]{32}, add that pattern to your scanner.
Forgetting CI/CD secrets. GitHub Actions secrets and environment variables don't appear in repository contents, but attackers can exfiltrate them through malicious workflows. Review workflow permissions under Settings > Actions > General.
Quick Reference Table
| Action | Tool | Frequency | Owner |
|---|---|---|---|
| Pre-commit scan | gitleaks, git-secrets | Every commit | Developer |
| PR scan | GitHub Actions + gitleaks | Every PR | CI/CD |
| History scan | gitleaks detect | Quarterly | Security team |
| Access audit | GitHub API | Monthly | Security team |
| Credential rotation | Vault, AWS Secrets Manager | On detection | Security + DevOps |
| Branch protection review | GitHub Settings | Quarterly | Security team |
| Fork monitoring | GitHub API | Weekly | Security team |
Emergency Response Checklist:
- Identify compromised repositories
- Disable compromised credentials (within 1 hour for critical)
- Scan repository history for additional exposures
- Review access logs for unauthorized activity
- Rotate all potentially exposed secrets
- Deploy server-side scanning if not present
- Document incident timeline and root cause
- Update detection rules based on attack pattern
The Megalodon campaign demonstrated that repository compromise isn't a gradual threat—it's a six-hour window between infection and widespread damage. Your defense needs to operate faster than that.
