Sync from inner source [auto] (#69)

Sync from github/github-well-architected-internal (main)

Source Repository: github/github-well-architected-internal

Source Branch: main

Source SHA: d1bd890c16bd9d9b203276f8a5e86b8a29fc494c

Co-authored-by: well-architected-sync-bot[bot] <235114805+well-architected-sync-bot[bot]@users.noreply.github.com>

Author: well-architected-sync-bot[bot]

content/library/application-security/recommendations/managing-dependency-threats.md

@@ -274,7 +274,7 @@ Build trust across the supply chain by establishing cryptographic provenance for
 
 For packages you maintain:
 
-1. Link your GitHub repository as a trusted publisher in your package registry settings (npm, PyPI, RubyGems, etc.)
+1. Link your GitHub repository as a trusted publisher in your package registry settings (npm, PyPI, RubyGems, NuGet, crates.io, etc.)
 2. Update your release workflow to use [OIDC authentication](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments) instead of long-lived tokens
 3. Publish with provenance attestations (e.g., `npm publish --provenance`) to create cryptographic proof on the specific commit of the source repository
 4. Create [linked artifact storage records](https://docs.github.com/enterprise-cloud@latest/code-security/concepts/supply-chain-security/linked-artifacts) with the [`actions/attest`](https://github.com/actions/attest) action
@@ -361,7 +361,7 @@ The most secure approach (reviewing every dependency change manually and disabli
 - **Attestations not universally available**: Not all packages support attestations yet. Use attestation availability as one factor in dependency selection and gradually work toward full coverage.
 - **Keeping lockfiles current**: Lockfiles prevent unexpected updates but can become stale. Regularly update dependencies through Dependabot or scheduled audits to ensure security patches aren't missed while maintaining reproducible builds.
 - **Breaking changes in security updates**: Security updates sometimes include breaking changes that require code modifications. Establish separate processes for security updates (expedited) vs. feature updates (standard review), and allocate time for security debt remediation.
-- **Workflow security risks**: The `pull_request_target` trigger runs with elevated permissions and access to secrets, even for pull requests from forks. Prefer the regular `pull_request` trigger, define least-privilege workflow permissions, and enable [CodeQL workflow analysis](https://docs.github.com/enterprise-cloud@latest/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning) to detect vulnerabilities.
+- **Workflow security risks**: The `pull_request_target` trigger runs with elevated permissions and access to secrets, even for pull requests from forks. Prefer the regular `pull_request` trigger, define least-privilege workflow permissions, and enable [CodeQL workflow analysis](https://docs.github.com/enterprise-cloud@latest/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning) to detect vulnerabilities. See the [GitHub Actions 2026 security roadmap](https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/) for upcoming capabilities addressing these risks.
 
 ## Seeking further assistance
 
@@ -384,6 +384,7 @@ Specifically, you may find the following links helpful:
 - [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) - GitHub's response to the Shai-Hulud attack
 - [The second half of software supply chain security on GitHub](https://github.blog/security/supply-chain-security/the-second-half-of-software-supply-chain-security-on-github/) - Build provenance and artifact attestations
 - [Securing the open source supply chain: The essential role of CVEs](https://github.blog/security/supply-chain-security/securing-the-open-source-supply-chain-the-essential-role-of-cves/) - Understanding vulnerability data and automation
+- [Securing the open source supply chain across GitHub](https://github.blog/security/supply-chain-security/securing-the-open-source-supply-chain-across-github/) - Prevention steps for secret exfiltration attacks and GitHub's security roadmap
 
 ### External resources
 

content/library/governance/recommendations/copilot-policies-best-practices/copilot_pru_enterprise_admin_playbook.md

@@ -154,9 +154,11 @@ Upon completion of this playbook, administrators will be able to:
 Premium Request Units (PRUs) represent usage credits for advanced GitHub Copilot features that exceed standard plan allowances. These units enable access to:
 
 - Advanced AI models (Claude, Gemini, etc.)
-- Agentic coding capabilities (Copilot Coding Agent)
+- Agentic coding capabilities (Copilot cloud agent)
 - Enhanced code review capabilities (Copilot Code Review)
 
+For governance-specific controls around cloud agents — policy configuration, security boundaries, MCP governance, and audit pipelines — see [Governing AI cloud agents in GitHub Enterprise]({{< relref "governing-agents.md" >}}).
+
 **Key Principles:**
 
 - PRUs reset monthly on the 1st at 00:00:00 UTC
@@ -176,7 +178,7 @@ Premium Request Units (PRUs) represent usage credits for advanced GitHub Copilot
 
 - Enhanced developer productivity with advanced AI models
 - Improved code quality through advanced review features
-- Accelerated development cycles with coding agents
+- Accelerated development cycles with cloud agents
 
 ### 2. Planning & Configuration
 
@@ -443,7 +445,7 @@ From the Enterprise Admin, three different types of organizations are defined:
    - Access limited to standard features.
    - Standard users have basic Copilot features but no PRU access.
 
-**In summary:**  
+**In summary:**
 The Enterprise Admin governs and manages policies and budgets across all organizations, while each organization determines licenses and access based on business requirements. Team members and standard users then utilize features and resources aligned with their assigned roles and budget levels.
 
 {{< callout type="info" >}}
@@ -531,7 +533,7 @@ Response timeframes are suggested based on enterprise best practices. Organizati
 **Symptoms:**
 
 - Premium models not available in Copilot Chat
-- Coding agents disabled or restricted
+- cloud agents disabled or restricted
 - Error messages about PRU limitations
 
 **Diagnostic Steps:**

content/library/governance/recommendations/governance-policies-best-practices/index.md

@@ -98,6 +98,8 @@ Use these key strategies as a baseline to implement GitHub's best practices for
 
 14. Initiate and impose **commit signing** whenever possible. This will deter malicious actors from creating a commit with malicious code and help prevent a possible supply chain attack.
 
+    > **Note:** Copilot cloud agent signs its commits automatically. For broader agent governance guidance, see [Governing agents in GitHub Enterprise]({{< relref "governing-agents.md" >}})
+
 15. **Bypass of rulesets should not be allowed** under the Repository Ruleset configuration. Enforcing policies around repo ruleset is designed for a reason and allowing users to bypass rulesets might allow an attacker to gain access as a user who is allowed to bypass ruleset and compromise the integrity of the codebase.
 
 16. **Runner groups should be limited** to a select number of repositories. Configuring a runner group for all repositories can expose vulnerabilities or allow malicious actors to exploit misconfigured runners. Additionally, maintaining runner groups for specific repositories ensures that self-hosted runners are used for their intended specialized workloads. Granting access to everyone in the organization can lead to wasting resources on unnecessary execution tasks.