โ—€ Playbook index
NO.19.4

Secret Scanning

Updated: 2026-09-11

In a nutshell

Secret Scanning is GitHub's detection feature that automatically finds API keys, tokens, and connection strings lurking in your repository.

Secrets already committed get an alert; secrets about to be pushed are blocked at git push time by Push protection. Stopping leaks before they happen is the core strategy.

Why secrets matter in private / internal repos

Private does not mean the breach stays contained. An attacker who compromises one developer account or runner can use internally exposed secrets to expand the attack. Keep secrets in a secret manager and block leaks with Push protection. Here are 8 reasons why.

โ–ธ CLICK + TO REVEAL

01Internal repos, external developers

An internal repo does not mean an internal-only workforce. Employees, contractors, systems integrators, and subcontractors with read access can all read committed secrets. Outsourcing extends access beyond your own employees and the devices you manage.

02One click from public

A misclick, repo transfer, Org misconfiguration, or policy change flips it public. Attacker scanners detect new public repos within seconds; leaked tokens have been abused within 60 seconds.

03Git history is forever

Deleting it in a later commit does not remove it. It stays in history, every local clone, forks, backups, and CI caches. The only fix is rotation, not file deletion.

04Git distributes your secrets, too

Git is a distributed version control system. A normal git clone copies code and history, including committed secrets, onto each developer's workstation, whether employee or contractor. Protecting the server is not enough. Revoking repo access when a contract ends does not erase those local copies.

05Account compromise = instant access

One phished developer exposes every secret in every repo they can read. The secrets themselves have no extra protection (no MFA, no self-managed encryption at rest, no expiry).

06Privilege escalation and lateral movement

Once inside your network, attackers can steal secrets from private / internal repos to gain higher privileges and move into production, cloud, or artifact registries. One compromised account can become an organization-wide breach, without any repo ever going public. MITRE ATT&CK โ†—

07Compliance and audit

ISO 27001, SOC 2, PCI-DSS, and ISMAP require central management, rotation, and access tracking. Plaintext secrets in Git fail all three, and audit findings are guaranteed.

08The real cost of an incident

Emergency rotation, production outage, forensics, customer notification. Compare that to the 30 minutes it takes to set up a secret manager.

Main capabilities

DEMOSecret ScanningFOR PRESENTER ONLY

  1. PUSH PROTECTION

    In ghas-test-1, push a generated secret.

    ./demo/secret-scanning/01-push-protection.sh

    The push is blocked and the terminal prints an unblock URL.

    Show which patterns are push-protected, enterprise-wide: octodemo โ†’ Pattern configurations โ†—. Flip a pattern in the Enterprise setting column; the Alert total, False positives, and Bypass rate columns back the noise-vs-risk call with real data.

    Same page is revisited on the What gets detected slide, to dig out the generic patterns.

  2. BYPASS PUSH PROTECTION

    Open the unblock-secret URL from the block message in your browser, pick a reason and bypass.

    You get โ€œsecret can now be pushedโ€.

    Push the same branch again.

    git push origin HEAD

    Open the closed alert under Security โ†’ Secret scanning and show who bypassed it and why.

    To keep bypasses under control: Settings โ†’ Advanced Security โ†’ Push protection, set Who can bypass push protection to Specific roles or teams (= Delegated bypass).

  3. VALIDITY CHECK

    In the default view under Security โ†’ Secret scanning, use the Validity filter.

    Triage by real risk: start with the secrets that are still live.

Secret Scanning is made up of five capabilities. Push protection closes the door and comes first; the rest cover detection, triage, and provider-side revocation.

โ–ธ CLICK + FOR DETAILS

Push protectionRight before git pushDocs

What it doesRejects the push on the spot when it contains a secret. Bypass is possible, but the reason is recorded

ScopeIncoming changes only. AI-detected passwords are not covered (too noisy to block)

Secret scanning alertsAfter commit, continuousDocs

What it doesNotifies you of detected secrets in the Security and quality tab

ScopeFull Git history on all branches, Issues, PRs, GitHub Discussions, Wikis, secret gists. Rescanned as new secret types ship

Validity checksWhen an alert firesDocs

What it doesAsks the provider API whether the secret is still active, so you can triage by real risk

ScopeSelect supported providers (AWS, GitHub, Slack, and others). AI-detected passwords are not covered (no provider to ask)

Partner programAlways on, public reposDocs

What it doesWhen a partner secret leaks, GitHub reports it straight to the provider, who revokes or reissues it

ScopePublic repos and public npm packages only. Reports never appear in your alert list (free, not configurable)

Public monitoringReal-time across github.comDocs

What it doesDetects secrets leaked outside your own repos (personal forks, OSS, public issues and PRs) and attributes them to your enterprise

ScopePublic content only, and it never scans private repos. GHEC Enterprise

What gets detected

DEMODetection typesFOR PRESENTER ONLY

  1. WHERE THE GENERIC PATTERNS HIDE

    Open octodemo โ†’ Pattern configurations โ†— and scroll the default patterns tab.

    It is one flat list: no category column, no provider / generic split, no filter. The generic patterns are in there, just never labelled as generic.

    Point them out by name โ€” these ten are the entire set:

    rsa_private_key openssh_private_key ec_private_key pgp_private_key generic_private_key mongodb_connection_string mysql_connection_url postgres_connection_string http_basic_authentication_header http_bearer_authentication_header

    Every one reads Disabled under GitHub default: detection is on, push protection is not. Flip one in the Enterprise setting column to opt it in.

  2. CUSTOM PATTERN + DRY RUN

    Settings โ†’ Advanced Security โ†’ Custom patterns โ†’ New pattern

    Matching secrets are already planted in the demo repo, so you only need to create the pattern:

    Pattern name โ€” Octodemo internal service token

    Secret format โ€” octodemo_(live|test)_[A-Za-z0-9]{32}

    Test string โ€” octodemo_live_L1QNGy4DLxQJ8C85kfwP0lmvCHLDuVxJ

    The test string has to go green before the form will save. Then use Save and dry run.

    The dry run reports the planted secrets without creating alerts. Review the hits, then Publish pattern and optionally turn push protection on for it.

Four detection engines, layered from exact partner formats to unstructured secrets that only AI can catch.

โ–ธ CLICK FOR DETAILS

Provider patterns

Provider patterns

Regex patterns registered by 200+ partners including AWS, Azure, GCP, Stripe, Slack, OpenAI, and GitHub PATs. Extremely low false-positive rate.

๐Ÿ“˜ Supported secrets โ†—

Generic patterns

Generic patterns

Private keys, connection strings, HTTP basic auth, and other generic formats. A wider net by design, so expect more triage than provider patterns. Not push-protected by default โ€” opt each pattern in under Pattern configurations.

AI-detected secrets

AI-detected secrets

Uses AI to detect unstructured secrets such as passwords, covering the ground no regex can reach. Supports neither push protection nor validity checks, at any setting โ€” triage these as alerts.

Custom patterns

Custom patterns

Define regexes for your own token formats: internal service tokens, legacy credentials, anything a partner will never register.

๐Ÿ“˜ Defining custom patterns โ†—

SELECT A TYPE โ–ธ

How to manage exposed secrets

DEMOSecurity campaignsFOR PRESENTER ONLY

  1. THE CAMPAIGNS TAB

    Open theomonfort-org โ†’ Campaigns โ†—.

    The tracking view: each campaign with its due date, manager, and a burn-down of open vs closed alerts. The point to land: alerts get an owner and a deadline here, not in a spreadsheet.

  2. CREATE ONE FROM SECRET SCANNING FILTERS

    Create campaign โ†’ From secret scanning filters

    Build the filter live so they see the triage logic. Start from is:open, narrow to the repos that matter, then set Validity to Active and Unknown.

    Watch the alert count drop with each filter. That is the whole argument: a finishable list instead of a backlog. Must be 1000 alerts or fewer to save.

  3. NAME IT, DATE IT, SHIP IT

    Save as โ†’ Draft campaign, then fill in the name, description, due date, and campaign manager.

    Note the manager picker only offers org owners and security managers.

    Review and publish notifies everyone who can see the alerts, and the campaign shows up in each repo's Security tab. Mention secret campaigns are in public preview.

When a secret is found, remediation matters more than detection. At scale, donโ€™t work the raw alert list, run it as a security campaign.

โ–ธ CLICK A STEP FOR DETAILS

SCOPE

๐ŸŽฏ SCOPE โ€” critical repos first

Org โ†’ Security and quality โ†’ Campaigns โ†’ Create campaign โ†’ From secret scanning filters

Not the whole org. Target the repos that matter, for example with a repository custom property (props.BusinessPriority:Urgent). Cap it at 1000 alerts, which is also the hard limit.

TRIAGE

โšก TRIAGE โ€” by real risk

Filter validity to Active and Unknown. Active is a live key someone can use right now. Unknown means nobody could confirm it is dead, so treat it as live.

Inactive can wait. This is what turns a backlog into a list worth someone's week.

OWN

๐Ÿ‘ค OWN โ€” a name and a date

Every campaign gets a due date and a campaign manager. The picker only offers org owners and security managers.

Without both, nothing gets rotated. Publishing notifies everyone who can see the alerts, and the campaign appears in each repo's Security tab.

ROTATE

๐Ÿšจ ROTATE โ€” then close it out

Deleting it from the repo is not enough: it stays in the history and in everyone's clones.

Partner secrets leaked in public repos are revoked provider-side and never reach your alert list. Then close each alert as Revoked, False positive, or Used in tests so the campaign burns down.

SELECT A STEP โ–ธ

Getting started (fastest path)

Settings โ†’ Advanced Security โ–ธ STEP 1 ยท PUSH PROTECTION

Blocks new secrets at push time.

Security โ†’ Secret scanning โ–ธ STEP 2 ยท EXISTING LEAKS

Scans past history too. Rotate down the list.

โ€ฆ โ†’ Custom patterns โ–ธ STEP 3 ยท CUSTOM PATTERNS

Your own token formats, by regex.

Org โ†’ โ€ฆ โ†’ Configurations โ–ธ STEP 4 ยท ROLL OUT

One config applies all of it, org-wide.

โš ๏ธ Legacy org REST API fields were removed 2026-04-21. Use the security configurations API.

Availability by product

Feature Public repo Private / internal
without product		 Secret Protection / GHAS
Secret scanning alertsโœ… FreeโŒโœ… Included
Push protection (repo / org)โœ… FreeโŒโœ… Included
Partner program alerts (sent to the provider)โœ… Free, always onโŒโŒ Public repos only
Validity checksโŒโŒโœ… Supported providers
Generic patternsโŒโŒโœ… Included
Custom patternsโŒโŒโœ… Included
AI-detected secretsโŒโŒโœ… Included
Public monitoringโŒโŒโœ… GHEC Enterprise

๐Ÿ†“ User push protection is free and enabled by default on all plans, but only covers pushes to public repositories. Partner alerts also notify providers only about leaks in public repositories and public npm packages โ€” always on, and not configurable.

๐Ÿ‘ค User-owned repositories are a special case: alerts require GHEC with Enterprise Managed Users, or GHES with Secret Protection enabled on the enterprise. Org-owned private / internal repos only need Secret Protection on Team or GHEC.

๐Ÿ’ฐ Generic, custom, and AI detection, validity checks, and private / internal repository coverage require Secret Protection or a legacy GHAS license. Public monitoring is an enterprise-wide feature for GHEC Enterprise.

๐Ÿ“˜ Details: Advanced Security products โ†— / Partner program โ†— / Public monitoring โ†—

Public monitoring (NEW) ๐Ÿ“– Docs

  • ๐ŸŒ Public only โ€” git, PR comments, issues, discussions. Never your private repos.
  • โšก Real time. Needs Secret Protection or GHAS. Public preview, no extra cost.
  • ๐Ÿงฉ No setup โ€” enable it and existing findings appear straight away.
Attributed byWhat it checksCatches
๐Ÿ‘ค MemberCommitter is a memberManaged and known accounts
๐ŸŒ Verified domainEmail on your domainPersonal account, work email

โš™๏ธ Turned on under Security and quality, by an enterprise owner or security manager.

Secret Risk Assessment ๐Ÿ“– Docs

Scans every org repo to show what secrets sit where. Free for Team and Enterprise orgs.

  • ๐Ÿ”Ž Scope โ€” every repo, any visibility, archived included
  • ๐Ÿ“Š Output โ€” secret types and counts per repo. Values are never stored or shown.
  • ๐Ÿ•’ Frequency โ€” point-in-time, rerunnable every 90 days. Not continuous monitoring.
  • ๐Ÿš€ Run it โ€” Org โ†’ Security and quality โ†’ Assessments โ†’ Scan your organization. The first run also starts the free code security assessment.

๐Ÿ“Š Answers โ€œhow many secrets are leaking?โ€ and gives you the numbers for a budget case.