[SRA + secrets] Improve discoverability with SEO updates to GHSP/ secret scanning docs (#60589)

Co-authored-by: Joe Clark <31087804+jc-clark@users.noreply.github.com>

Author: mchammer01

content/code-security/concepts/secret-security/about-push-protection.md

@@ -18,7 +18,7 @@ category:
 
 ## What is push protection?
 
-Push protection is a {% data variables.product.prodname_secret_scanning %} feature designed to prevent sensitive information, such as secrets or tokens, from ever being pushed to your repository. Unlike {% data variables.product.prodname_secret_scanning %}, which detects secrets after they have been committed, push protection proactively scans your code for secrets during the push process, then blocks the push if any are detected.
+Push protection is a {% data variables.product.prodname_secret_scanning %} feature designed to prevent hardcoded credentials, such as secrets or tokens, from ever being pushed to your repository. Rather than alerting you to credential leaks after the fact, push protection blocks pushes that contain secrets _before_ they reach your repository.
 
 ## How push protection works
 
@@ -74,9 +74,9 @@ If you want greater control over which contributors can bypass push protection a
 
 ## Benefits of push protection
 
-* **Preventative security:** Push protection acts as a frontline defense mechanism by scanning code for secrets at the time of the push. This preventative approach helps to catch potential issues before they are merged into a repository.
+* **Preventative security:** Push protection acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push. This preventative approach helps prevent credential leaks before they become ingrained in the repository's history, making it easier to address and remediate threats.
 * **Immediate feedback:** Developers receive instant feedback if a potential secret is detected during a push attempt. This immediate notification allows for quick remediation, reducing the likelihood of sensitive information being exposed.
-* **Reduced risk of data leaks:** By blocking commits that contain sensitive information, push protection significantly reduces the risk of accidental data leaks. This helps in safeguarding against unauthorized access to your infrastructure, services, and data.
+* **Reduced risk of credential leaks:** By blocking commits that contain hardcoded credentials, push protection significantly reduces the risk of accidental credential leaks and secret sprawl. This helps in safeguarding against potential breaches and maintaining the integrity of the codebase.
 * **Efficient secret management:** Instead of retrospectively dealing with exposed secrets, developers can address issues at the source. This makes secret management more efficient and less time-consuming.
 * **Bypass functionality for flexibility:** For cases where false positives occur or when certain patterns are necessary, you can bypass push protection for users, and designated users can use the delegated bypass feature to bypass push protection for repositories. {% ifversion push-protection-org-enterprise-exemptions %}Additionally, you can exempt trusted actors {% ifversion push-protection-repo-exemptions %}{% else %}at the organization and enterprise levels {% endif %}from push protection entirely. {% endif %}This provides flexibility without compromising overall security.
 * **Ability to detect custom patterns (for repositories in organizations):** Organizations can define custom patterns for detecting secrets unique to their environment. This customization ensures that push protection can effectively identify and block even non-standard secrets.

content/code-security/concepts/secret-security/about-secret-scanning.md

@@ -19,7 +19,7 @@ category:
   - Protect your secrets
 ---
 
-When credentials like API keys and passwords are committed to repositories, they become targets for unauthorized access. {% data variables.product.prodname_secret_scanning_caps %} automatically detects these exposed secrets so you can secure them before they're exploited.
+When credentials like API keys and passwords are committed to repositories as hardcoded secrets, they become targets for unauthorized access. {% data variables.product.prodname_secret_scanning_caps %} automatically detects credential leaks so you can secure them before they're exploited.
 
 {% ifversion secret-risk-assessment %}
 
@@ -32,15 +32,15 @@ When credentials like API keys and passwords are committed to repositories, they
 
 ## How secret scanning protects your code
 
-{% data variables.product.prodname_secret_scanning_caps %} scans your entire Git history on all branches of your repository for API keys, passwords, tokens, and other known secret types. {% data variables.product.github %} also periodically rescans repositories when new secret types are added.
+{% data variables.product.prodname_secret_scanning_caps %} scans your entire Git history on all branches of your repository for hardcoded credentials, including API keys, passwords, tokens, and other known secret types. This helps you identify secret sprawl, the uncontrolled proliferation of credentials across repositories, before it becomes a security risk. {% data variables.product.github %} also periodically rescans repositories when new secret types are added.
 
 {% data variables.product.github %} also automatically scans:
 
 {% data reusables.secret-scanning.what-is-scanned %}
 
 ### {% data variables.product.prodname_secret_scanning_caps %} alerts and remediation
 
-When {% data variables.product.prodname_secret_scanning %} finds a potential secret, {% data variables.product.github %} generates an alert on your repository's **{% data variables.product.prodname_security_and_quality_tab %}** tab with details about the exposed credential.
+When {% data variables.product.prodname_secret_scanning %} detects a credential leak, {% data variables.product.github %} generates an alert on your repository's **{% data variables.product.prodname_security_and_quality_tab %}** tab with details about the exposed credential.
 
 When you receive an alert, rotate the affected credential immediately to prevent unauthorized access. While you can also remove secrets from your Git history, this is time-intensive and often unnecessary if you've already revoked the credential.
 

content/code-security/concepts/secret-security/about-secret-security-with-github.md

@@ -14,7 +14,7 @@ category:
   - Protect your secrets
 ---
 
-Exposed secrets in your repositories can lead to unauthorized access, data breaches, and significant costs to your organization. For details about these risks and how to protect against them, see [AUTOTITLE](/code-security/concepts/secret-security/secret-leakage-risks).
+Hardcoded credentials in your repositories can lead to credential leaks, unauthorized access, data breaches, and significant costs to your organization. For details about these risks and how to protect against them, see [AUTOTITLE](/code-security/concepts/secret-security/secret-leakage-risks).
 
 {% data variables.product.github %} provides tools to help you understand and address your organization's exposure to leaked secrets:
 
@@ -23,7 +23,7 @@ Exposed secrets in your repositories can lead to unauthorized access, data breac
 
 ## Secret risk assessment
 
-The secret risk assessment provides organization owners and security managers with a free point-in-time scan of their organization's repositories to identify leaked secrets like API keys, tokens, and passwords.
+The secret risk assessment provides organization owners and security managers with a free point-in-time scan of their organization's repositories to identify hardcoded credentials like API keys, tokens, and passwords, and understand the extent of secret sprawl across your organization.
 
 {% data variables.secret-scanning.secret-risk-assessment-cta-product %}
 
@@ -52,13 +52,13 @@ Regular assessment helps prevent:
 While the {% data variables.product.prodname_secret_risk_assessment %} provides a point-in-time view of your organization's current secret exposure, {% data variables.product.prodname_GH_secret_protection %}:
 
 * **Implements continuous monitoring** and expands scanned surfaces beyond code to include pull requests, issues, wikis, and discussions
-* **Prevents secret leaks** by blocking commits containing secrets before they are saved to {% data variables.product.github %}
+* **Prevents credential leaks** by blocking commits containing hardcoded secrets before they are saved to {% data variables.product.github %}
 * **Creates actionable alerts** that can be grouped into campaigns and assigned to team members for remediation
 * **Meets your specific needs** by scanning for patterns unique to your organization and unstructured secrets like passwords
 * **Supports governance at scale** with settings dictating who can bypass protections and dismiss alerts
 * **Surfaces key analytics** through a view dedicated to your organization's secret security
 
-Through these features, {% data variables.product.prodname_GH_secret_protection %} provides complete coverage for your organization, reducing the risk of costly secret leaks and high-effort remediation processes.
+Through these features, {% data variables.product.prodname_GH_secret_protection %} provides complete coverage for your organization, reducing the risk of costly credential leaks, secret sprawl, and high-effort remediation.
 
 For more information about the specific features of {% data variables.product.prodname_GH_secret_protection %}, see [AUTOTITLE](/code-security/getting-started/github-security-features#available-with-github-secret-protection).
 

content/code-security/concepts/secret-security/secret-leakage-risks.md

@@ -9,96 +9,90 @@ versions:
 contentType: concepts
 ---
 
-## Secrets and credentials
+## What are secrets?
 
-Secrets are credentials that grant access to sensitive systems and data, including API keys, passwords, authentication tokens, certificates, and encryption keys. When secrets are committed to repositories, they become part of your Git history and remain accessible even after being removed from the latest commit.
+Secrets are credentials that grant access to sensitive systems and data. Common examples include:
 
-Secrets in code repositories can be discovered by automated scanning tools and unauthorized users. Public repositories are particularly vulnerable, but leaked credentials from private repositories can also spread through forks, CI/CD logs, or third-party integrations.
+* API keys and tokens used to authenticate with external services
+* Database passwords and connection strings
+* Cloud provider credentials and service account tokens
+* Certificates and encryption keys
 
-## Security impact of exposed secrets
+When secrets are committed to repositories, they become **hardcoded credentials** that are embedded directly in your source code or configuration files. These hardcoded secrets become part of your Git history and remain accessible even after being removed from the latest commit. This means that addressing a credential leak requires more than deleting the file; you must also revoke and replace the credential to prevent unauthorized access.
 
-Exposed secrets can lead to several types of security incidents:
+## How secrets get exposed
 
-**Unauthorized access and usage**
-* Leaked cloud provider credentials can be used to provision infrastructure or services on your account
-* Database credentials allow access to sensitive customer or organizational data
-* Service account tokens provide entry points to production systems
+**Secret sprawl** occurs when credentials proliferate across repositories, teams, and systems without centralized management or visibility. This makes it difficult to track which secrets exist, where they're used, and whether they've been exposed. Secrets typically enter repositories through several common patterns.
 
-**Operational and compliance issues**
-* Infrastructure can be modified or deleted using leaked credentials
-* Data breaches from exposed secrets may result in regulatory penalties under GDPR, CCPA, and other frameworks
-* Organizations face costs for incident response, credential rotation, and system remediation
+### Development workflows
 
-**Organizational risk**
-* Public disclosure of leaked secrets affects customer trust and organizational reputation
-* Exposed package registry tokens can be used to publish malicious versions of your software
-* Proprietary API keys or service credentials may be exploited
+* Hardcoded credentials added during local testing and inadvertently committed
+* Secrets in configuration files such as `.env` files or infrastructure-as-code templates
+* Example credentials containing real API keys or tokens in documentation, wikis, or README files
 
-## Financial impact of exposed secrets
+### Repository management
 
-Secret leakage can result in direct and indirect costs to your organization, ranging from immediate expenses to long-term business consequences.
+* Legacy repositories containing forgotten but still-active credentials
+* Secrets shared in {% data variables.product.github %} issues, pull request comments, discussions, or gists
+* Credentials introduced by external contributors or contractors
 
-**Immediate costs**
-* Unauthorized cloud resource usage from leaked API keys can generate charges for compute instances, storage, or data transfer
-* Cryptocurrency mining operations on compromised accounts can result in substantial infrastructure bills
-* Emergency incident response requires resources for forensic investigation, security audits, and credential rotation across systems
+### Version control propagation
 
-**Data breach costs**
-* Regulatory fines for data protection violations can reach millions of dollars under GDPR, CCPA, and industry-specific regulations
-* Legal costs include investigation, notification requirements, and potential litigation
-* Credit monitoring and identity protection services for affected customers
+* Secrets persist in Git history even after removal from current code.
+* Credentials propagate to forked repositories, backup systems, and CI/CD logs.
+* Public repositories with exposed secrets are indexed by search engines and specialized scanning services.
 
-**Operational impact**
-* Service disruptions from compromised infrastructure result in lost revenue and productivity
-* Engineering time spent responding to security incidents diverts resources from product development
-* Increased security tooling and monitoring costs following incidents
+## Security risks
 
-**Long-term business impact**
-* Customer churn following public disclosure of security incidents
-* Increased insurance premiums for cyber liability coverage
-* Lost business opportunities due to failed security assessments or compliance audits
+Exposed secrets can lead to several types of security incidents.
 
-## Common secret leakage scenarios
+### Unauthorized access
 
-Secrets typically enter repositories through several common patterns:
+Credential leaks give unauthorized users direct access to your systems. Once exposed, hardcoded secrets can be exploited to:
 
-**Development workflows**
-* Credentials hardcoded during local testing and inadvertently committed
-* Secrets in configuration files like `.env` files or infrastructure-as-code templates
-* Example credentials containing real tokens in documentation, wikis, or README files
+* Provision infrastructure or services on your account using leaked cloud provider credentials
+* Access sensitive customer or organizational data through compromised database credentials
+* Gain entry to production systems via exposed service account tokens
 
-**Repository management**
-* Legacy repositories containing forgotten but still-active credentials
-* Secrets shared in GitHub issues, pull request comments, discussions, or gists
-* Credentials introduced by external contributors or contractors
+### Data breaches
+
+Credential leaks give unauthorized users direct access to your systems, leading to data breaches. Once attackers gain access using exposed credentials, they can exfiltrate sensitive data, modify or delete critical information, and compromise customer trust. Data breaches require immediate incident response, including credential revocation, system remediation, and assessment of the breach's scope and impact.
 
-**Version control challenges**
-* Secrets persist in Git history even after removal from current code
-* Credentials propagate to forked repositories, backup systems, and logs
-* Public repositories with exposed secrets are indexed by search engines and specialized scanning services
+### Supply chain attacks
+
+Exposed package registry tokens can be used to publish malicious versions of your software, affecting downstream users and organizations that depend on your packages.
+
+## Financial impact
+
+Exposed secrets can cost your organization money in several ways.
+
+* **Unexpected cloud bills**: Leaked API keys let attackers use your cloud resources. They can run compute instances, store data, or mine cryptocurrency on your account, generating large bills.
+* **Incident response**: Investigating breaches, rotating credentials, and auditing systems takes significant engineering time and resources.
+* **Legal costs**: Data breaches can result in fines, legal fees, and notification expenses.
+* **Long-term damage**: Lost customers, higher insurance costs, and missed business opportunities after security incidents become public.
 
 ## Secret security with {% data variables.product.github %}
 
 {% data variables.product.github %} provides tools to help you prevent, detect, and remediate secret leakage:
 
-### 1. Prevent new secrets from being leaked
+### 1. Prevent new secrets from being committed
 
-Enable **push protection for repositories** to scan code during `git push` operations and block commits containing detected secrets. This prevents credentials from entering your repositories while providing real-time feedback to developers.
+Enable **Push protection** to scan code during `git push` operations and block commits containing detected secrets before they enter your repository. This prevents hardcoded credentials from being added to your codebase and provides real-time feedback to developers at the point of risk, covering both provider patterns for known services and non-provider patterns such as private keys and generic API keys.
 
-Encourage your contributors to enable push protection for their personal accounts (the feature is referred to as "push protection for users") to protect all their pushes to their repositories, forks, and any repositories they contribute to across {% data variables.product.github %}. This allows individual developers to prevent secret leakage without waiting for organization-level policies.
+Encourage individual developers to enable push protection for their personal accounts to protect all their pushes across {% data variables.product.github %}, regardless of organization policies. This helps prevent secret sprawl by catching leaked credentials before they reach your repositories.
 
 ### 2. Detect existing secrets
 
-Use **{% data variables.product.prodname_secret_scanning %}** to continuously monitor repositories for committed secrets and receive alerts when credentials are detected. This enables you to revoke and rotate compromised credentials quickly.
+Use **{% data variables.product.prodname_secret_scanning %}** to continuously monitor your repositories for hardcoded secrets and generate alerts when credentials are detected, enabling you to revoke and rotate compromised credentials quickly. Beyond default detection of provider patterns, you can expand scanning to non-provider patterns and define custom patterns for organization-specific secrets. This helps you gain visibility into secret sprawl across your organization.
 
 ## Next steps
 
-To protect your organization from secret leakage:{% ifversion secret-risk-assessment %}
-1. Run a free secret risk assessment to understand your current exposure.
-{% data variables.secret-scanning.secret-risk-assessment-cta-product %}
+To protect your organization from secret leakage:
+{% ifversion secret-risk-assessment %}
+1. Run a free secret risk assessment to understand your current exposure. {% data variables.secret-scanning.secret-risk-assessment-cta-product %}
 {% endif %}
 1. Enable push protection to prevent new secrets from being committed.
-1. Enable {% data variables.product.prodname_secret_scanning %} with a click to begin detecting secret leaks.
+1. Enable {% data variables.product.prodname_secret_scanning %} to begin detecting existing secret leaks.
 1. Establish secure credential management practices for your development teams.
 
 {% ifversion secret-risk-assessment %}