🛡️ Trust Boundary & Platform Trust
“Before you write a single line of secure code, you must define WHERE your development trust lives.”
A hands-on workshop (30–45 minutes) establishing the foundation layer of the Agentic DevSecOps series — Data Residency, Enterprise Managed Users, branch protections as access control, and Copilot boundary enforcement. Part 1 of 4.
Overview
Workshop Focus
This workshop answers a single driving question:
“WHERE does development happen — and who controls that space?”
Before you can enforce guardrails, verify supply chains, or respond to incidents, you need to know where the trust boundary is. Data Residency, Enterprise Managed Users (EMUs), branch protections, and Copilot policies together define the perimeter within which all secure development takes place.
Key Insight: Data Residency is a security control because it defines the trust boundary of the development platform.
| Attribute | Value |
|---|---|
| Duration | 30–45 minutes |
| Exercises | 3 (Explore Boundary → Identity & Access → Copilot Boundary Enforcement) |
| NIST SSDF Group | PO — Prepare the Organization |
| Presentation Slide | Slide 4 |
| Target Audience | Developers, DevOps engineers, security professionals, regulated enterprise teams |
Series Context
This is Workshop 1 of 4 in the Agentic DevSecOps series. It establishes the foundation layer — the trust boundary on which all subsequent security controls (guardrails, supply chain integrity, operational response) are built.
→ WS1 🛡️ Trust Boundary & Platform Trust ← Foundation layer
WS2 🔒 Secure by Design Guardrails ← Guardrails built ON the boundary
WS3 🔗 Supply Chain Integrity ← Integrity verified WITHIN the boundary
WS4 🔄 Operational Response ← Response loops ACROSS the boundary
NIST SSDF Alignment
Each workshop maps to a group in NIST SP 800-218 (SSDF):
| SSDF Group | Focus | Workshop |
|---|---|---|
| PO — Prepare the Organization | Define security requirements for the development infrastructure | 🛡️ WS1 (this workshop) |
| PW — Produce Well-Secured Software | Secure the codebase with guardrails and checks | 🔒 WS2 |
| PS — Protect the Software (Supply Chain) | Verify dependencies and code-to-cloud integrity | 🔗 WS3 |
| RV — Respond to Vulnerabilities | Detect, respond, and continuously improve | 🔄 WS4 |
Learning Objectives
By the end of this workshop, you will be able to:
- Describe what a Trust Boundary is and why it matters in DevSecOps
- Explain how Data Residency establishes platform trust (and its limitations)
- Demonstrate how Enterprise Managed User (EMU) accounts enforce identity containment
- Configure branch protections as access control mechanisms
- Observe Copilot agentic capabilities operating only within trusted boundaries
Curriculum
| Step | Title | Time |
|---|---|---|
| Setup | Environment Setup | ~15 min |
| 1 | Explore the Trust Boundary | ~10 min |
| 2 | Identity & Access Enforcement | ~12 min |
| 3 | Copilot Boundary Enforcement | ~12 min |
Key Insight
“Data Residency doesn’t mean ALL data stays in Japan. It means you’ve made a conscious decision about where the trust boundary is — and you understand what crosses it.”
NIST SSDF PO.1 requires organizations to “define security requirements for their development infrastructure.” Data Residency is how GitHub Enterprise delivers on this requirement — by giving organizations control over where their development data resides.
References
GitHub Documentation
| Resource | Link |
|---|---|
| GitHub Enterprise Cloud — Data Residency | https://docs.github.com/en/enterprise-cloud@latest/admin/data-residency |
| Enterprise Managed Users (EMU) | https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/understanding-iam-for-enterprises/about-enterprise-managed-users |
| GHE.com Feature Overview | https://docs.github.com/en/enterprise-cloud@latest/admin/data-residency/feature-overview-for-data-residency |
| Copilot Coding Agent | https://docs.github.com/en/copilot/using-github-copilot/using-copilot-coding-agent |
| Copilot Custom Instructions | https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot |
| Branch Protection Rules | https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-a-branch-protection-rule |
NIST Publications
| Resource | Link |
|---|---|
| SP 800-218 — Secure Software Development Framework (SSDF) | https://csrc.nist.gov/publications/detail/sp/800-218/final |
| SP 800-218A — AI-Specific Additions to SSDF | https://csrc.nist.gov/publications/detail/sp/800-218a/final |
GitHub Blog
| Resource | Link |
|---|---|
| GitHub Enterprise Cloud with Data Residency — Japan Region | https://github.blog/changelog/2024-09-25-github-enterprise-cloud-with-data-residency/ |
Discussion Prompts
Use these questions for team discussion after completing the exercises:
-
Data Residency boundaries: What data does YOUR organization need to keep in a specific region? How does that shape your trust boundary?
-
Open-source trade-offs: If EMU accounts can’t contribute to open source, how would your team handle open-source contributions?
-
NIST SSDF criteria: NIST SSDF says organizations should “define criteria for software security checks.” How would you define the security criteria for your trust boundary?
-
Compliance communication: How would you explain the difference between Data Residency and full data sovereignty to a compliance officer?
Series Navigation
| Workshop | Focus | |
|---|---|---|
| 🛡️ | WS1 — Trust Boundary & Platform Trust (YOU ARE HERE) | WHERE does development happen — and who controls that space? |
| 🔒 | WS2 — Secure by Design Guardrails | WHAT prevents bad code from landing in production? |
| 🔗 | WS3 — Supply Chain Integrity & Code-to-Cloud Visibility | HOW do we trust the delivery path? |
| 🔄 | WS4 — Operational Response & Continuous Improvement | WHAT happens when things go wrong? |