Why Secret Scanning Matters for SOC 2

CC6.7 of the SOC 2 Trust Services Criteria requires protecting credentials and preventing unauthorized access via leaked secrets. The single most common way credentials end up exposed: a developer accidentally commits an API key, database password, or AWS access key to a GitHub repository.

GitHub's secret scanning detects these credentials automatically — both before they're committed (via push protection) and after (via repository scanning). For SOC 2 auditors, having secret scanning enabled is increasingly expected for any organization that stores code in GitHub.

Enable Secret Scanning at the Organization Level

Enable secret scanning across your entire GitHub organization from a single settings page:

Go to Organization Settings → Security → Code Security and Analysis

Enable GitHub Advanced Security (required for private repos on GitHub Enterprise; free for public repos)

Enable Secret Scanning — this scans all existing commits and new pushes across all repositories

For organizations on GitHub Free or Teams, secret scanning for public repositories is enabled by default. For private repositories, you need GitHub Enterprise or Advanced Security.

Enable Push Protection

Push protection blocks commits that contain secrets *before* they enter the repository — preventing exposure rather than detecting it after the fact. This is the stronger control.

# Enable push protection via GitHub API
curl -X PUT \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  "https://api.github.com/orgs/YOUR_ORG/secret-scanning/push-protection" \
  -d '{"enabled": true}'

Or via the UI: Organization Settings → Security → Code Security → Secret Scanning → Push Protection → Enable.

When push protection is active, a developer who tries to push a commit containing a recognized secret receives an error that blocks the push. They must explicitly bypass it with a documented reason — creating an audit trail.

What GitHub Scans For

GitHub maintains a database of over 200 secret patterns including:

• AWS access keys and secret keys
• GitHub personal access tokens and app tokens
• Google API keys and service account credentials
• Stripe API keys
• Slack tokens
• Azure connection strings
• Database connection URLs with embedded passwords
• Private keys (PEM, PPK)

Partner patterns are reported directly to the service provider — AWS, Google, Stripe, etc. — who can automatically revoke the leaked credential. This is the fastest remediation path for accidentally committed credentials.

Responding to Secret Scanning Alerts

When secret scanning finds a match, the alert appears in Security → Secret Scanning. Your response process should be:

Immediately revoke the credential — assume it's been scraped by credential monitoring bots within seconds of being pushed. Don't wait to investigate first.

Create a new credential and update all systems using it

Investigate impact — did anything access your systems using the leaked credential? Check CloudTrail if it was an AWS key.

Document the incident — even if no breach occurred, document the detection, remediation, and any access review. This is evidence of your change management and incident detection controls.

For SOC 2 auditors, the response documentation is as important as having the scanning enabled.

Custom Patterns for Your Organization

If your organization uses internal tokens or API keys not covered by GitHub's default patterns, add custom secret scanning patterns:

Organization Settings → Security → Code Security → Custom Patterns → New Pattern

Example: a custom pattern for an internal service token format:

sk-prod-[A-Za-z0-9]{32}

This catches internal credentials that GitHub's default patterns wouldn't recognize.

What SecureSpect Checks

SecureSpect monitors:

• github.org.secret_scanning — secret scanning is enabled at the organization level
• github.repo.push_protection — push protection is active across repositories

Both checks map to CC6.7 (logical access over credentials) and CC6.8 (authentication credentials). Every SecureSpect check produces timestamped evidence that maps directly to the SOC 2 control.