Skip to main content
In this walkthrough you will enable GitHub Advanced Security (GHAS) secret scanning for an enterprise, create a custom enterprise configuration that enforces secret protection, and demonstrate how secret scanning (with push protection) detects exposed credentials during a push. What you’ll learn:
  • How to create and enforce a GHAS enterprise configuration focused on secret protection
  • How push protection behaves when a secret is detected
  • Where to find and how to remediate secret scanning alerts
Resources:

Step 1 — Create an enterprise GHAS configuration

  1. In your enterprise account (NextGen Gaming), open Enterprise settings → Advanced Security.
  2. The default configuration uses GitHub-recommended settings (includes secret protection, code security, and Dependabot). For this demo, create a custom configuration focused on secret protection.
  • Click New Configuration.
  • Enter a name (for example, nextgen-advanced-security).
  • Enable Secret protection and any sub-options you want (validity checks, extended metadata, generic patterns, AI-detected secrets, push protection).
  • Configure bypass rules: choose which roles (e.g., enterprise owners, org admins) may request or approve bypasses.
  • Optionally enable prevent direct alert dismissals so users must submit a dismissal request.
  • Disable Code scanning and Dependabot if you only want secret protection for this demo.
  • Set Enforce this configuration and apply it to all repositories (or to repositories without configurations).
A dark-themed GitHub settings page showing the "Advanced Security / New configuration" form with a name field filled ("nextgen-advanced-security") and secret protection options. The screen lists secret scanning features (validity checks, generic patterns, AI-detected secrets, push protection) with various Enabled/Not set toggles.
Note: When applying the configuration to all repositories, GitHub may prompt that additional secret protection licenses will be consumed for private repositories. Confirm to proceed when appropriate.

GHAS Secret Protection options (summary)

Step 2 — Demo repository file (triggering secret scanning)

Below is a minimal Node.js example that intentionally contains high-entropy mock secrets to trigger secret scanning, plus a simple insecure endpoint that CodeQL could flag later.
For testing, use mock or rotated credentials. Never commit production credentials or long-lived tokens to repositories; use short-lived, test, or properly rotated values.
Do not commit real, active credentials or personal access tokens (PATs) to any repository. Treat any detected secret as compromised: rotate it immediately and remove it from the repo history.

Step 3 — Push behavior with push protection enabled

When you commit and push a change that contains a detected secret, GHAS push protection will react according to your policy:
  • If push protection is enforced, GitHub can block the push and show a dialog that describes the detected secret and the file/commit location.
  • If bypasses are allowed and your role is permitted to request/approve bypasses, the dialog can offer:
    • Cancel and remove the secret from the commit before re-pushing.
    • Request or apply a bypass (mark as test/false positive) — the push proceeds if authorized.
    • Allow (rare cases when policy permits).
Even when a bypass is used to allow the push, GitHub records a secret scanning alert for the repository. The alert includes detection metadata and details about any bypass request or approval.

Viewing and triaging secret scanning alerts

After the push, open the repository Security → Secret scanning alerts (or the combined Security & Code Security pages) to inspect detected secrets. GHAS provides context such as where the secret was found, commit ID, severity, and remediation guidance.
A GitHub repository security page showing the Secret scanning alerts tab with one open alert for a leaked GitHub Personal Access Token (marked as a public leak, detected in app.js). The screenshot is a dark‑theme browser view of the repository's Security and quality settings.
Alert detail view typically shows:
  • File path and commit (where the secret was detected)
  • Secret type (e.g., GitHub Personal Access Token, AWS key)
  • Leak visibility (public vs private)
  • Suggested remediation steps
  • Bypass metadata (who requested/approved the bypass, comments)
Helpful tools and references:

Summary

This walkthrough demonstrated:
  • Creating a custom GHAS enterprise configuration focused on secret protection
  • How secret scanning and push protection detect and block (or prompt on) pushes that contain high-entropy secrets
  • Where to find secret scanning alerts and the information they include
  • A recommended remediation workflow to rotate and remove exposed credentials
Follow your organization’s remediation and approval processes for bypasses, and enforce push protection where appropriate to reduce accidental credential exposure.

Watch Video