GH-500

The "used in tests" close reason means the detected secret is used only for testing, so it gives no access that needs protecting. What counts is how the secret is used, not where it sits: a real credential committed to a test file or to readme.md is still exposed and must be revoked and replaced. Saying a value is not a secret in production does not establish that it is only a test value, because it could still grant access elsewhere.

Once enabled, secret scanning analyzes the repository without changing it: it scans the Git history on all branches, plus content such as issues, pull requests and discussions, and reports any known secret types. People with access to security alerts, such as repository administrators and security managers, then see the detected secrets as secret scanning alerts on the Security tab; these are not Dependabot alerts, which come from a separate feature. Enabling secret scanning does not switch on dependency review or code scanning, which are enabled separately. It also does not subscribe a team to security alerts: a team gets access only when an administrator grants it, and notifications follow each person's own settings.

Push protection checks pushes for highly identifiable secrets and blocks the push before the secret reaches the repository. The contributor must then remove the secret or, if needed, bypass the protection. It does not disable buttons in the GitHub UI or add a 2FA challenge to pushes. It also acts at push time, so it is not a merge rule requiring existing alerts to be closed.

A security policy is a SECURITY.md file in a repository that tells people how to report a security vulnerability responsibly. An alert issued to a community about a vulnerability describes a security advisory. An alert about vulnerable dependencies is a Dependabot alert. Automatic detection of vulnerabilities and coding errors in code is code scanning.

The repository's Security tab lists its security features, such as Dependabot, code scanning and secret scanning, with the number of open alerts for each. GHAS settings are configured under the repository's Settings, in Advanced Security, not on the Security tab. Access management is also part of the repository's Settings. Two-factor authentication options belong to a user's personal account settings.

Code scanning searches for potential security vulnerabilities and coding errors, secret scanning detects secrets such as keys and tokens, and dependency review shows the full impact of dependency changes before a pull request is merged. Together these match the third option. Automatically raising pull requests to update dependencies is what Dependabot does, and alerts about vulnerable dependencies are Dependabot alerts. Confidentially reporting and privately fixing vulnerabilities is the role of security advisories.

The repository's Security tab is where secret scanning, Dependabot and code scanning alerts appear and are reviewed. There is no alert type called security status alerts. Repository permissions are not alerts at all; they are managed in the repository's Settings.

When dependency review finds a dependency with a known vulnerability, the warning message gives a brief description of that vulnerability so the reviewer can see what the problem is before merging. A visualization of the dependency changes, how many projects use the components, and the security impact of the changes describe what dependency review offers as a whole. They are not the content of the warning for a vulnerable dependency.

Secret scanning and dependency review are free on public repositories, but on private and internal repositories they need a paid GitHub Advanced Security product: GitHub Secret Protection for secret scanning and GitHub Code Security for dependency review. Without it, the feature cannot be used on those repositories. A security policy is simply a SECURITY.md file that any repository can add, and GitHub Packages is a separate package hosting service, so neither depends on an Advanced Security license.

Secret scanning looks for known types of authentication credentials, such as tokens and private keys, that were committed to a repository. Usernames and personal information are not credentials with a recognizable pattern, so they are not detected unless you define a custom pattern for them. A sealed box is an encryption technique, not a type of secret that secret scanning looks for.

Repository and organization administrators grant view access to security alerts under Settings, in Security > Advanced Security > Access to alerts, by searching for people or teams and saving the change. The Security tab is where alerts are viewed and triaged, not where access to them is granted. Insights shows repository activity, and Secrets is where encrypted secrets for workflows are stored.

An active secret can still be used to reach the service it belongs to, so it presents the most immediate risk. The alert list can be filtered by validity, which lets you remediate active secrets before looking at ones already revoked. Sorting by age says nothing about whether a secret still works, and limiting the list to custom patterns would hide active secrets found by the built-in patterns.

Validity checks query the relevant provider to determine whether a detected token is still active and, when possible, whether it was ever active. Push protection blocks supported secrets before they are pushed but does not test whether they work. Custom patterns only define additional formats to detect, and branch protection governs changes to branches rather than being a secret scanning feature.

Custom patterns extend secret scanning, so secret scanning must be enabled on the repository before you can configure one. Additional match criteria are optional settings within the pattern form, not a prerequisite. Repository visibility does not need to be changed to Internal, and existing alerts have no effect on creating a pattern.

Secret scanning is enabled by default on public repositories, with no configuration needed. On private repositories it must be enabled manually and requires GitHub Advanced Security, which rules out private and user-owned private repositories. New repositories in an organization only get it automatically if someone has configured that at the organization level, which the question excludes.

A validity check works by asking the provider that issued a secret whether it is still active, so it applies to partner patterns, where that provider is known. A custom pattern describes a format unique to your organization, so GitHub has no issuing provider to ask. High entropy strings have no identified provider either, and push protection is a way of blocking secrets at push time rather than a set of patterns that validity checks target.

To exclude files from secret scanning, you create a .github/secret_scanning.yml file and list the paths under the paths-ignore key, using special characters such as * to filter them. secret_scanning.yml is the name of the file that holds the setting, not the syntax used inside it. branches-ignore filters branches for workflow triggers and does not exclude files from secret scanning, and decrypt_secret.sh is a shell script rather than YAML syntax.

Secret scanning scans the entire Git history on all branches of your GitHub repository, along with content such as issues, pull requests and discussions. It works on repositories hosted on GitHub, not on any Git repository wherever it is hosted. It does not scan continuous integration systems. External services are what leaked secrets can give access to, and a partnered provider may be notified about a leak, but those services are not scanned.

Secret validation, known as validity checks, determines whether an exposed secret is still active, so you can remediate active secrets before ones that have already been revoked, and you can filter alerts by validity. Push protection blocks supported secrets before they are pushed, so it prevents new exposures rather than ranking existing alerts. Non-provider patterns widen what is detected without saying whether a secret is live. Custom pattern dry runs only test a pattern before it is published.

Secret scanning has to be enabled on a repository before it can be configured, and custom patterns are part of that configuration. Adding the custom pattern is the act of defining it, so it cannot come first. Providing the regular expression and any additional match requirements are also steps within defining the pattern, not prerequisites for it.