> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo GHAS Secret Scanning

> Walkthrough to enable and enforce GitHub Advanced Security secret scanning with push protection, demonstrate detection of exposed credentials, and show alert triage and remediation steps.

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:

* GitHub Advanced Security overview: [https://docs.github.com/en/enterprise/marketplace/github-advanced-security/about-github-advanced-security](https://docs.github.com/en/enterprise/marketplace/github-advanced-security/about-github-advanced-security)
* Dependabot: [https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot](https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot)
* CodeQL: [https://docs.github.com/en/code-security/code-scanning/using-codeql-code-scanning-for-your-project](https://docs.github.com/en/code-security/code-scanning/using-codeql-code-scanning-for-your-project)
* git-filter-repo (history rewriting): [https://github.com/newren/git-filter-repo](https://github.com/newren/git-filter-repo)

## 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.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-GHAS-Secret-Scanning/github-advanced-security-secret-scanning.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=938d1e45ff8bfdf37e49f23c7e233290)

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)

| Option | What it does | Typical setting |
| - | - | - |
| Validity checks | Validates token formats (e.g., PAT, AWS keys) | Enabled |
| Extended metadata | Adds richer context about detected secrets | Enabled |
| Generic patterns | Detects secret-like high-entropy strings | Optional |
| AI-detected secrets | Uses ML to find secrets that patterns miss | Optional |
| Push protection | Blocks or warns on pushes that contain detected secrets | Recommended for enforcement |

## 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.

```javascript theme={null}
// app.js
const express = require('express');
const path = require('path');
const app = express();
const PORT = process.env.PORT || 3000;

// ===============================
// DEMO 1: Secret Scanning
// High-entropy mock AWS credentials and a GitHub PAT.
// GitHub Secret Scanning will detect these patterns upon push.
// ===============================
const AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE";
const AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";
const GITHUB_PAT = "ghp_mlyMx1HClBgh3v1FVASyALwmktHOta4frOZX";

// ===============================
// DEMO 2: CodeQL (Static Analysis / SAST)
// This endpoint takes unvalidated user input (req.query.file)
// and passes it to res.sendFile(), which can allow path traversal.
// CodeQL will flag this as "Arbitrary file read/write".
// ===============================
app.get('/download', (req, res) => {
  // Unsafe: using user input directly in a filesystem path
  const userFile = req.query.file;
  const filePath = path.join(__dirname, 'public', userFile);
  res.sendFile(filePath);
});

app.get('/', (req, res) => {
  res.send('GHAS Demo App is running.');
});

app.listen(PORT, () => {
  console.log(`App listening on port ${PORT}`);
});
```

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.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-GHAS-Secret-Scanning/github-secret-scan-pat-leak-appjs.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=2d0afd8983c045c075564966520be236)

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)

## Recommended remediation workflow

| Step | Action |
| - | - |
| 1 | Treat any leaked credential as compromised. Immediately rotate/revoke the credential. |
| 2 | Remove the secret from your repository (commit a removal) and then purge it from history (use `git filter-repo` or similar). |
| 3 | Re-run scans or verify via GitHub that the alert is resolved. |
| 4 | Close the alert in GitHub once remediated and confirmed. |
| 5 | Review and update policies to prevent recurrence (e.g., enforce push protection, add scanning patterns, use secrets management). |

Helpful tools and references:

* git-filter-repo: [https://github.com/newren/git-filter-repo](https://github.com/newren/git-filter-repo)
* GitHub docs: secret scanning remediation: [https://docs.github.com/en/code-security/secret-scanning/remediating-secret-scanning-alerts](https://docs.github.com/en/code-security/secret-scanning/remediating-secret-scanning-alerts)
* Use secure secret storage: GitHub Secrets, HashiCorp Vault, cloud provider secret managers

## 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.

> [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/d477d0b2-5ca0-43b2-aed7-7d82887400f7/lesson/699ebf51-2045-4343-afe8-d98771d1a76b)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.