Repo sync

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

@@ -18,10 +18,10 @@ redirect_from:
 contentType: concepts
 ---
 
-## About delegated bypass for push protection
-
 {% data reusables.secret-scanning.push-protection-delegate-bypass-beta-note %}
 
+## About delegated bypass for push protection
+
 When push protection is enabled for a repository, users with write access can bypass push protection and push a secret if they provide a reason and the bypass is approved.
 
 With delegated bypass for push protection, you can:
@@ -33,7 +33,7 @@ With delegated bypass for push protection, you can:
 
 To set up delegated bypass, organization owners or repository administrators create a list of users with bypass privileges. This designated list of users can then:
 * Bypass push protection, by specifying a reason for bypassing the block.
-* Manage (approve or deny) bypass requests coming from all other contributors. These requests are located in the "Push protection bypass" page in the **Security** tab of the repository.
+* Manage (approve or deny) bypass requests coming from all other contributors. These requests are located in the "Push protection bypass" page in the **Security** tab of the repository, and will expire after 7 days.
 
 The following types of users can always bypass push protection without having to request bypass privileges:
 * Organization owners

content/code-security/concepts/secret-security/index.md

@@ -18,6 +18,7 @@ children:
   - /about-delegated-bypass-for-push-protection
   - /about-secret-scanning-for-partners
   - /github-secret-types
+  - /push-protection-from-the-command-line
   - /working-with-push-protection-and-the-github-mcp-server
   - /working-with-push-protection-from-the-rest-api
 redirect_from:

content/code-security/concepts/secret-security/push-protection-from-the-command-line.md

@@ -0,0 +1,31 @@
+---
+title: Push protection from the command line
+shortTitle: Command line protection
+intro: Understand how {% data variables.product.github %} uses push protection to prevent secret leaks from the command line.
+permissions: '{% data reusables.permissions.push-protection-resolve-block %}'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+topics:
+  - Secret scanning
+  - Secret Protection
+  - Alerts
+  - Repositories
+contentType: concepts
+---
+
+Push protection prevents you from accidentally committing secrets to a repository by blocking pushes containing supported secrets.
+
+When you attempt to push a supported secret from the command line to a repository secured by push protection, {% data variables.product.prodname_dotcom %} will block the push.
+
+You should either:
+
+* **Remove** the secret from your branch. For more information, see [Resolving a blocked push](/code-security/how-tos/secure-your-secrets/work-with-leak-prevention/working-with-push-protection-from-the-command-line#resolving-a-blocked-push).
+* **Follow a provided URL** to see what options are available to you to allow the push. For more information, see [Bypassing push protection](/code-security/how-tos/secure-your-secrets/work-with-leak-prevention/working-with-push-protection-from-the-command-line#bypassing-push-protection) and [Requesting bypass privileges](/code-security/how-tos/secure-your-secrets/work-with-leak-prevention/working-with-push-protection-from-the-command-line#requesting-bypass-privileges).
+
+Up to five detected secrets will be displayed at a time on the command line. If a particular secret has already been detected in the repository and an alert already exists, {% data variables.product.prodname_dotcom %} will not block that secret.
+
+If you confirm a secret is real and that you intend to fix it later, you should aim to remediate the secret as soon as possible. For example, you might revoke the secret and remove the secret from the repository's commit history. Real secrets that have been exposed must be revoked to avoid unauthorized access. You might consider first rotating the secret before revoking it. For more information, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository).
+
+{% data reusables.secret-scanning.push-protection-multiple-branch-note %}

content/code-security/concepts/vulnerability-reporting-and-management/about-coordinated-disclosure-of-security-vulnerabilities.md

@@ -80,7 +80,17 @@ The process for reporting and disclosing vulnerabilities for projects on {% data
 
 {% data reusables.security-advisory.private-vulnerability-reporting-enable %}
 
- Private vulnerability reporting provides an easy way for vulnerability reporters to privately disclose security risks to repository maintainers, within {% data variables.product.prodname_dotcom %}, and in a way that immediately notifies the repository maintainers of the issue. For more information for security researchers and repository maintainers, see [AUTOTITLE](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) and [AUTOTITLE](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/managing-privately-reported-security-vulnerabilities), respectively.
+Private vulnerability reporting provides a secure, structured way for security researchers to privately disclose security risks to repository maintainers directly within {% data variables.product.prodname_dotcom %}. When a vulnerability is reported, repository maintainers are immediately notified, allowing them to review and respond without the risk of premature public disclosure.
+
+Without clear guidance on how to contact maintainers, security researchers may feel forced to disclose vulnerabilities publicly, such as by posting on social media, opening public issues, or contacting maintainers through informal channels, which can expose users to unnecessary risk. Private vulnerability reporting helps avoid these situations by offering a dedicated, private reporting workflow.
+
+For security researchers, private vulnerability reporting offers:
+
+* Less frustration, and less time spent trying to figure out how to contact the maintainer.
+* A smoother process for disclosing and discussing vulnerability details.
+* The opportunity to discuss vulnerability details privately with the repository maintainer.
+
+For more information for security researchers and repository maintainers, see [AUTOTITLE](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) and [AUTOTITLE](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/managing-privately-reported-security-vulnerabilities), respectively.
 
 > [!NOTE]
 > If the repository containing the vulnerability doesn't have private vulnerability reporting enabled, both security researchers and repository maintainers need to follow the instructions described in the [Standard process](#standard-process) section above.