What's changed: New GH-500 Chapter 2 (enabling & prevention = repo/org enablement, public vs private availability/licensing, Push Protection at the source, validity checks and prioritized alerting, mandatory token revocation; alert management = lifecycle [created→open→resolved/dismissed], role-based/delegated bypass, recipients/exclusions, custom secret patterns [regex])
2.2Managing Secret Protection Alerts, Policies, and Custom Patterns
Understand the Secret Protection alert lifecycle (creation, status, dismissal) and appropriate remediation, role-based/delegated bypass policies, configuring alert recipients and exclusions, and creating/managing custom secret patterns.
Detected secrets are managed as alerts. GH-500 tests the alert lifecycle (creation → triage → response → status update) and the policies, notifications, and customization that support it. The focus is not "detect and done" but remediate appropriately and govern across the org.
2.2.1Alert lifecycle and remediation
A secret alert is created (detected) and becomes open. Owners triage and update status after acting—resolve if properly handled, or dismiss with a reason (false positive, used in tests, risk accepted) if a false positive or accepted. The most important remediation is revoking (rotating) the leaked token. Since deleting the file leaves it in history, revoke first, then consider history handling. Careless dismissal is dangerous—record reasons and follow policy.
2.2.2Policies, recipients, and exclusions
Organizations control who can view/act on/bypass alerts via role-based settings (including delegated bypass approver configuration). Configure alert recipients to notify the right team on new detections. Reduce noise by configuring exclusions for false positives or out-of-scope paths (e.g., test data or docs). These tune the balance between detection precision and operational load, focusing on truly important alerts.
2.2.3Custom secret patterns
GitHub detects many default patterns (major providers’ token formats), but an org’s proprietary tokens or internal system keys aren’t caught by default. So define custom secret patterns via regular expressions to detect org-specific secrets too. When creating, test matches and tune the pattern to avoid excessive false positives. This extends detection coverage to your security requirements.
Common: (1) Alert lifecycle = created → open → resolved/dismissed; the key remediation is revoking (rotating) the leaked token (deleting the file leaves it in history). (2) Role-based/delegated bypass controls view/act/approve; recipients for notifications; exclusions reduce noise. (3) Detect org-specific secrets via custom patterns (regex), tuned to limit false positives. (4) Dismiss with recorded reasons + policy.
Watch out: (1) Dismissing an alert does not revoke the leaked token—always rotate it. (2) Exclusions reduce noise but over-broadening misses real secrets. (3) A too-loose custom-pattern regex causes false positives—tune via tests. (4) Granting delegated-bypass approval too widely weakens prevention.
2.2.4Section summary
- Alerts: created → open → resolved/dismissed; key remediation is revoking (rotating) the leaked token
- Control via role-based/delegated bypass; notify via recipients; reduce noise via exclusions
- Detect org-specific secrets via custom patterns (regex), tuned to limit false positives
- Dismissing doesn’t revoke—always rotate, and record reasons
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What is the most important remediation action for a secret alert about a leaked API token?
Q2. You want Secret Protection to detect your org’s proprietary token format (internal system keys). What do you do?
Q3. Which is the correct flow of the secret-alert lifecycle?
Q4. False positives and test-data paths flood alerts, burying the important ones. Appropriate action?
Q5. You want new secret alerts reliably routed to the right security team. What do you configure?
Q6. Which is a correct understanding of dismissing a secret alert?