Production Capstone: Govern a GitHub Organization and Build a Secure End-to-End Delivery System: Security, Governance, and Reliability Validation

1. Validate claims as invariants

Validation asks a different question from implementation. Instead of “did we configure a ruleset?”, ask “can a change reach main without the expected review/check path, and what evidence would reveal that?” Instead of “does the workflow use OIDC?”, ask “which job can request OIDC, for what purpose, and which consumer trusts that identity?”

Every production claim below therefore has four fields: policy objective → enforcement surface → independent evidence → accountable owner. If one field is missing, the control is incomplete even when the UI looks correct.

2. Personal ownership versus organization governance

3. Permissions and trust-boundary matrix

4. Validate ruleset, review, merge, and release governance

1. Ruleset: retrieve the current ruleset via API and confirm it targets the intended branch, is Active, has no unintended bypass actor, and names the stable check that every relevant PR creates.
2. Review: verify who actually approved the reviewed SHA. In the solo lab, explicitly mark independent approval as “not demonstrated.”
3. Merge identity: record the merge commit or squash result that became main. PR head SHA and final main SHA may differ.
4. Release identity: verify the tag resolves to the intended release SHA and the release assets match the attested digest.
5. Rollback: identify a previous source SHA and artifact/release pair before you need it; do not invent rollback under incident pressure.

5. Hosted versus self-hosted execution and credential strategy

The mandatory capstone intentionally selects a standard GitHub-hosted runner because it removes the learner from runner registration, patching, persistence, and production-network governance. Public repositories also make standard hosted execution the no-paid path. This does not mean hosted runners are automatically “more secure” in every architecture; it means the trust and operating responsibilities differ.

6. Free security baseline versus enhanced controls

7. Monorepo/multi-repo and API/App automation boundaries

The capstone uses one repository because its components share one release and one learner. Production should split only when ownership, release cadence, visibility, compliance boundary, or operational independence outweigh cross-repository coordination cost. If a monorepo is chosen, path filtering must preserve cross-cutting/global changes and ownership rules must stay maintainable.

API automation follows the same identity rule. Use a first-class gh command when it expresses the operation clearly; use gh api/REST/GraphQL for structured automation; use a GitHub App when a service needs durable installation-scoped identity and events. Do not turn a human PAT into a pseudo-service account by default.

8. Control → enforcement → evidence → owner map

9. Plan and deployment compatibility matrix

GitHub Enterprise Server capabilities change by server release and administrator policy. The matrix intentionally avoids pretending GitHub.com behavior is automatically present on every GHES instance; operators must check their deployed version and enabled features.

10. Measurable acceptance criteria

Knowledge checks

Summary

The implementation has now been challenged as an operating model. Human and machine identities have separate authority, each policy maps to evidence and ownership, plan-sensitive features have honest substitutes, and success criteria are measurable. Lesson 4 deliberately breaks these assumptions to prove the recovery model.

Official references

• GitHub Docs — GITHUB_TOKEN
• GitHub Docs — OIDC
• GitHub Docs — Code scanning
• GitHub Docs — Secret scanning
• GitHub Docs — Artifact attestations
• GitHub Docs — REST API