Merge branch 'main' into patch-1

Author: Sharra-writes

content/admin/data-residency/network-details-for-ghecom.md

@@ -177,13 +177,43 @@ Japan region:
 
 ### Domains for Azure private networking
 
+#### Required for all regions
+
 * `*.<TENANT>.ghe.com`
 * `<TENANT>.ghe.com`
 * `github.com`
 * `*.githubusercontent.com`
-* `*.blob.core.windows.net`
+* `*.blob.core.windows.net` (can be further restricted by region, see below)
 * `*.web.core.windows.net`
 
+#### EU
+
+`*.blob.core.windows.net` can be replaced with:
+* `prodsdc01resultssa0.blob.core.windows.net`
+* `prodsdc01resultssa1.blob.core.windows.net`
+* `prodsdc01resultssa2.blob.core.windows.net`
+* `prodsdc01resultssa3.blob.core.windows.net`
+* `prodweu01resultssa0.blob.core.windows.net`
+* `prodweu01resultssa1.blob.core.windows.net`
+* `prodweu01resultssa2.blob.core.windows.net`
+* `prodweu01resultssa3.blob.core.windows.net` 
+
+#### Australia
+
+`*.blob.core.windows.net` can be replaced with:
+* `prodae01resultssa0.blob.core.windows.net`
+* `prodae01resultssa1.blob.core.windows.net`
+* `prodae01resultssa2.blob.core.windows.net`
+* `prodae01resultssa3.blob.core.windows.net`
+
+#### Japan
+
+`*.blob.core.windows.net` can be replaced with:
+* `prodjpw01resultssa0.blob.core.windows.net`
+* `prodjpw01resultssa1.blob.core.windows.net`
+* `prodjpw01resultssa2.blob.core.windows.net`
+* `prodjpw01resultssa3.blob.core.windows.net`
+
 ## IP ranges for {% data variables.product.prodname_importer_proper_name %}
 
 If you're running a migration to your enterprise with {% data variables.product.prodname_importer_proper_name %}, you may need to add certain ranges to an IP allow list. See [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations).

content/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses.md

@@ -30,7 +30,7 @@ These ranges are in [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inte
 
 We make changes to our IP addresses from time to time. We do not recommend allowing by IP address, but if you use these IP ranges we strongly encourage regular monitoring of our API.
 
-For applications to function, you must allow TCP ports 22, 80, and 443 via our IP ranges for `github.com`.
+For applications to function, you must allow TCP ports 22, 80, and 443 via our IP ranges for `github.com` and `{% data variables.enterprise.data_residency_domain %}`.
 
 ## Further reading
 

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

@@ -15,7 +15,7 @@ contentType: concepts
 children:
   - /about-code-scanning
   - /about-code-scanning-alerts
-  - /evaluating-default-setup-for-code-scanning
+  - /setup-types
   - /about-integration-with-code-scanning
   - /codeql
 ---

content/code-security/concepts/code-scanning/setup-types.md

@@ -0,0 +1,67 @@
+---
+title: About setup types for code scanning
+shortTitle: Setup types
+intro: Depending on your needs, {% data variables.product.github %} offers a default or advanced setup for code scanning.
+topics:
+  - Code Security
+  - Code scanning
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+contentType: concepts
+---
+
+## About default setup
+
+Default setup for {% data variables.product.prodname_code_scanning %} is the quickest, easiest, most low-maintenance way to enable {% data variables.product.prodname_code_scanning %} for your repository. Based on the code in your repository, default setup will automatically create a custom {% data variables.product.prodname_code_scanning %} configuration. After enabling default setup, the code written in {% data variables.product.prodname_codeql %}-supported languages in your repository will be scanned:
+
+* On each push to the repository's default branch, or any protected branch. For more information on protected branches, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).
+* When creating or committing to a pull request based against the repository's default branch, or any protected branch, excluding pull requests from forks.
+* On a weekly schedule.
+
+If you need more granular control over your {% data variables.product.prodname_code_scanning %} configuration, you should instead configure advanced setup.
+
+### Supported languages
+
+{% data reusables.code-scanning.default-setup-pre-enablement-explanation %}
+
+If the code in a repository changes to include any {% data variables.product.prodname_codeql %}-supported languages, {% data variables.product.prodname_dotcom %} will automatically update the {% data variables.product.prodname_code_scanning %} configuration to include the new language. If {% data variables.product.prodname_code_scanning %} fails with the new configuration, {% data variables.product.prodname_dotcom %} will resume the previous configuration automatically so the repository does not lose {% data variables.product.prodname_code_scanning %} coverage.
+
+### Available runners
+
+You can use default setup for all {% data variables.product.prodname_codeql %}-supported languages on self-hosted runners or {% data variables.product.prodname_dotcom %}-hosted runners.
+
+You can assign self-hosted runners for default setup by giving the runners {% ifversion code-scanning-default-setup-customize-labels %}the default `code-scanning` label, or you can optionally give them custom labels so that individual repositories can use different runners.{% else %}the `code-scanning` label.{% endif %}
+
+{% ifversion code-scanning-default-setup-customize-labels %}
+
+Unless you have a specific use case, we recommend that you only assign runners with the default `code-scanning` label. However, you may want to use custom labels to:
+
+* Assign more powerful self-hosted runners to critical repositories for faster {% data variables.product.prodname_code_scanning %} analysis.
+* Run your {% data variables.product.prodname_code_scanning %} analyses on a particular platform (for example, macOS).
+* Have granular control over the workload for your {% data variables.product.prodname_dotcom %}-hosted runners and self-hosted runners.
+
+{% endif %}
+
+## About advanced setup
+
+Advanced setup for {% data variables.product.prodname_code_scanning %} is helpful when you need to customize your {% data variables.product.prodname_code_scanning %}. By creating and editing a workflow file, you can define how to build compiled languages, choose which queries to run, select the languages to scan, use a matrix build, and more. You also have access to all the options for controlling workflows, for example: changing the scan schedule, defining workflow triggers, specifying specialist runners to use.
+
+{% ifversion fpt or ghec %}
+You can also configure {% data variables.product.prodname_code_scanning %} with third-party tools.
+
+{% else %}
+Your site administrator can also make third-party actions available to users for {% data variables.product.prodname_code_scanning %}, by setting up {% data variables.product.prodname_github_connect %}. For more information, see [AUTOTITLE](/admin/code-security/managing-github-advanced-security-for-your-enterprise/configuring-code-scanning-for-your-appliance#configuring-github-connect-to-sync-github-actions).
+{% endif %}
+
+{% data reusables.code-scanning.about-multiple-configurations-link %}
+
+## Next steps
+
+You can enable default setup for a single repository, multiple repositories, or all repositories in an organization at the same time.
+
+* For a single repository, see [AUTOTITLE](/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-default-setup-for-code-scanning).
+* For bulk enablement, see [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning-at-scale).
+
+To configure advanced setup instead, see [AUTOTITLE](/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning).

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/supply-chain-security/about-dependabot-security-updates.md

@@ -29,11 +29,15 @@ contentType: concepts
 
 ## About {% data variables.product.prodname_dependabot_security_updates %}
 
-{% data variables.product.prodname_dependabot_security_updates %} make it easier for you to fix vulnerable dependencies in your repository. You typically add a `dependabot.yml` file to your repository to enable {% data variables.product.prodname_dependabot_security_updates %}. You then configure options in this file to tell {% data variables.product.prodname_dependabot %} how to maintain your repository.
+{% data variables.product.prodname_dependabot_security_updates %} make it easier for you to fix vulnerable dependencies in your repository.
+
+If you enable {% data variables.product.prodname_dependabot_security_updates %}, when a {% data variables.product.prodname_dependabot %} alert is raised for a vulnerable dependency in the dependency graph of your repository, {% data variables.product.prodname_dependabot %} automatically tries to fix it. For more information, see [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) and [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates).
+
+You can add a `dependabot.yml` configuration file to your repository to customize {% data variables.product.prodname_dependabot %} behavior, including update schedules, pull request settings, and which dependencies to monitor.  For more information, see [AUTOTITLE](/code-security/concepts/supply-chain-security/about-the-dependabot-yml-file). You then configure options in this file to tell {% data variables.product.prodname_dependabot %} how to secure the dependencies your repository relies on.
 
 {% data reusables.dependabot.dependabot-updates-supported-repos-ecosystems %}
 
-If you enable {% data variables.product.prodname_dependabot_security_updates %}, when a {% data variables.product.prodname_dependabot %} alert is raised for a vulnerable dependency in the dependency graph of your repository, {% data variables.product.prodname_dependabot %} automatically tries to fix it. For more information, see [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) and [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates).
+
 
 > [!NOTE]
 > There is no interaction between the settings specified in the `dependabot.yml` file and {% data variables.product.prodname_dependabot %} security alerts, other than the fact that alerts will be closed when related pull requests generated by {% data variables.product.prodname_dependabot %} for security updates are merged.

content/code-security/concepts/supply-chain-security/about-dependabot-version-updates.md

@@ -44,6 +44,8 @@ You enable {% data variables.product.prodname_dependabot_version_updates %} by c
 
 The `dependabot.yml` configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. {% data variables.product.prodname_dependabot %} uses this information to check for outdated packages and applications. {% data variables.product.prodname_dependabot %} determines if there is a new version of a dependency by looking at the semantic versioning ([semver](https://semver.org/)) of the dependency to decide whether it should update to that version. {% data reusables.dependabot.dependabot-updates-supported-repos-ecosystems %}
 
+The `dependabot.yml` file can also be configured to tell {% data variables.product.prodname_dependabot %} how to maintain your dependencies. For more information, see [AUTOTITLE](/code-security/concepts/supply-chain-security/about-the-dependabot-yml-file).
+
 For certain package managers, {% data variables.product.prodname_dependabot_version_updates %} also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. {% data variables.product.prodname_dependabot_version_updates %} can be configured to check vendored dependencies for new versions and update them if necessary.
 
 When {% data variables.product.prodname_dependabot %} identifies an outdated dependency, it raises a pull request to update the manifest to the latest version of the dependency. For vendored dependencies, {% data variables.product.prodname_dependabot %} raises a pull request to replace the outdated dependency with the new version directly. You check that your tests pass, review the changelog and release notes included in the pull request summary, and then merge it. For more information, see [AUTOTITLE](/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates).