Merge branch 'main' into patch-1

Author: Sharra-writes

assets/images/help/copilot/coding-agent/agents-page-input.png

@@ -3,7 +3,7 @@ kind: Deployment
 metadata:
   name: webapp
 spec:
-  replicas: 2
+  replicas: 1
   selector:
     matchLabels:
       app: webapp

assets/images/help/copilot/mcp-icon-in-dropdown.png

@@ -3,7 +3,7 @@ kind: Deployment
 metadata:
   name: webapp
 spec:
-  replicas: 4
+  replicas: 6
   selector:
     matchLabels:
       app: webapp
@@ -23,12 +23,12 @@ spec:
           image: docs-internal
           resources:
             requests:
-              cpu: 4000m
+              cpu: 2500m
               # Absolute minimum to start app is 1000m
               # Node is single-threaded but we want more CPUs
               # for OS and image resizing, and other binary executions
               # Better to increase replicas or memory than CPU
-              memory: 8Gi
+              memory: 6.0Gi
               # Absolute minimum to start app is 4500Mi
               # Would increase with more pages, versions, or languages supported
               # The additional memory helps during traffic surges

assets/images/help/security/security-campaigns-tracking-overview-2tabs.png

@@ -23,7 +23,7 @@ To set up an admission controller for enforcing GitHub artifact attestations, yo
 
 ### Deploy the Sigstore Policy Controller
 
-We have packaged the Sigstore Policy Controller as a [GitHub distributed Helm chart](https://github.com/github/artifact-attestations-helm-charts). Before you begin, ensure you have the following prerequisites:
+The Sigstore Policy Controller has been packaged and made available via a [Helm chart](https://github.com/sigstore/helm-charts). Before you begin, ensure you have the following prerequisites:
 
 * A Kubernetes cluster with version 1.27 or later
 * [Helm](https://helm.sh/docs/intro/install/) 3.0 or later
@@ -34,8 +34,8 @@ First, install the Helm chart that deploys the Sigstore Policy Controller:
 ```bash copy
 helm upgrade policy-controller --install --atomic \
   --create-namespace --namespace artifact-attestations \
-  oci://ghcr.io/github/artifact-attestations-helm-charts/policy-controller \
-  --version v0.12.0-github12
+  oci://ghcr.io/sigstore/helm-charts/policy-controller \
+  --version 0.10.5
 ```
 
 This installs the Policy Controller into the `artifact-attestations` namespace. At this point, no policies have been configured, and it will not enforce any attestations.
@@ -48,7 +48,7 @@ Once the policy controller has been deployed, you need to add the GitHub `TrustR
 helm upgrade trust-policies --install --atomic \
  --namespace artifact-attestations \
  oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies \
- --version v0.6.2 \
+ --version v0.7.0 \
  --set policy.enabled=true \
  --set policy.organization=MY-ORGANIZATION
 ```
@@ -86,7 +86,7 @@ For example, to enforce attestations for images that match the pattern `ghcr.io/
 helm upgrade trust-policies --install --atomic \
  --namespace artifact-attestations \
  oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies \
- --version v0.6.2 \
+ --version v0.7.0 \
  --set policy.enabled=true \
  --set policy.organization=MY-ORGANIZATION \
  --set-json 'policy.exemptImages=["index.docker.io/library/busybox**"]' \
@@ -119,13 +119,13 @@ To see the full set of options you may configure with the Helm chart, you can ru
 For policy controller options:
 
 ```bash copy
-helm show values oci://ghcr.io/github/artifact-attestations-helm-charts/policy-controller --version v0.12.0-github12
+helm show values oci://ghcr.io/sigstore/helm-charts/policy-controller --version 0.10.5
 ```
 
 For trust policy options:
 
 ```bash copy
-helm show values oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies --version v0.6.2
+helm show values oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies --version v0.7.0
 ```
 
 For more information on the Sigstore Policy Controller, see the [Sigstore Policy Controller documentation](https://docs.sigstore.dev/policy-controller/overview/).

assets/images/help/security/security-campaigns-tracking-overview-code-only.png

@@ -105,7 +105,30 @@ For more information, see [AUTOTITLE](/code-security/code-scanning/introduction-
 
 To help mitigate the risk of an exposed token, consider restricting the assigned permissions. For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token).
 
-### Using third-party actions
+{% ifversion custom-org-roles %}
+
+## Mitigating the risks of untrusted code checkout
+
+Similar to script injection attacks, untrusted pull request content that automatically triggers actions processing can also pose a security risk. The `pull_request_target` and `workflow_run` workflow triggers, when used with the checkout of an untrusted pull request, expose the repository to security compromises. These workflows are privileged, which means they share the same cache of the main branch with other privileged workflow triggers, and may have repository write access and access to referenced secrets. These vulnerabilities can be exploited to take over a repository.
+
+For more information on these triggers, how to use them, and the associated risks, see [AUTOTITLE](/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target) and [AUTOTITLE](/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run).
+
+For additional examples and guidance on the risks of untrusted code checkout, see [Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) from {% data variables.product.prodname_security %} and the [Dangerous-Workflow](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow) documentation from OpenSSF Scorecard.
+
+### Good practices
+
+
+* Avoid using the `pull_request_target` workflow trigger if it's not necessary. For privilege separation between workflows, `workflow_run` is a better trigger. Only use these workflow triggers when the workflow actually needs the privileged context.
+
+* Avoid using the `pull_request_target` and `workflow_run` workflow triggers with untrusted pull requests or code content. Workflows that use these triggers must not explicitly check out untrusted code, including from pull request forks or from repositories that are not under your control. Workflows triggered on `workflow_run` should treat artifacts uploaded from other workflows with caution.
+
+* {% data variables.product.prodname_codeql %} can scan and detect potentially vulnerable {% data variables.product.prodname_actions %} workflows. You can configure default setup for the repository, and ensure that {% data variables.product.prodname_actions %} scanning is enabled. For more information, see [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning).
+
+* OpenSSF Scorecards can help you identify potentially vulnerable workflows, along with other security risks when using {% data variables.product.prodname_actions %}. See [Using OpenSSF Scorecards to secure workflow dependencies](#using-openssf-scorecards-to-secure-workflow-dependencies) later in this article.
+
+{% endif %}
+
+## Using third-party actions
 
 The individual jobs in a workflow can interact with (and compromise) other jobs. For example, a job querying the environment variables used by a later job, writing files to a shared directory that a later job processes, or even more directly by interacting with the Docker socket and inspecting other running containers and executing commands in them.
 

config/kubernetes/default/deployments/webapp.yaml

@@ -1159,6 +1159,8 @@ For more information, see the {% data variables.product.prodname_cli %} informat
 
 This event occurs when a workflow run is requested or completed. It allows you to execute a workflow based on execution or completion of another workflow. The workflow started by the `workflow_run` event is able to access secrets and write tokens, even if the previous workflow was not. This is useful in cases where the previous workflow is intentionally not privileged, but you need to take a privileged action in a later workflow.
 
+{% data reusables.actions.workflow-run-permissions-warning %}
+
 In this example, a workflow is configured to run after the separate "Run Tests" workflow completes.
 
 ```yaml

config/kubernetes/production/deployments/webapp.yaml

@@ -37,6 +37,7 @@ By default, the {% data variables.product.prodname_code_scanning %} alerts page
    ![Screenshot of a {% data variables.product.prodname_code_scanning %} alert. The "Show paths" and "Show more" links are outlined in dark orange.](/assets/images/help/repository/code-scanning-alert-details.png)
 
 1. Alerts from {% data variables.product.prodname_codeql %} analysis include a description of the problem. Click **Show more** for guidance on how to fix your code.
+{% data reusables.security.alert-assignee-step %}
 
 For more information, see [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts).