What's changed: New GH-100 Chapter 3 (policies & rulesets = govern member capabilities vs enforce on code changes, enterprise cascade, audit log/SIEM streaming, defense in depth; repo security features = enable vulnerability alerts/secret scanning/CodeQL, default config, Dependabot/advisories, response plan/SECURITY.md; API & integrations = fine-grained PAT/least privilege/revocation, GitHub App vs OAuth App, rate limits, app approval/denial)
3.1Security Policies and Rulesets
Understand defining organization and enterprise policies, strengthening the enterprise security posture and data protection, and implementing audit logging and reporting—how an admin sets org-wide guardrails.
To embed secure development org-wide, admins must set org-wide guardrails rather than leaving it to individual developers. GH-100 tests defining "what’s allowed / what must be followed" via policies and rulesets, surfacing/tracking via audit logs, and raising the enterprise security posture.
3.1.1Organization and enterprise policies
Policies govern "what members can do"—repo creation and visibility (public/internal/private), forking, Actions usage scope, inviting outside collaborators, and enabling GHAS features. Policy set at the enterprise level cascades to member orgs, which operate within upper constraints. Rulesets are guardrails that enforce branch protection, required reviews, required status checks on code changes—a separate layer from policies (capabilities). Combine both for consistent governance.
3.1.2Security posture and data protection
Admins continuously strengthen the enterprise security posture—enforcing 2FA/SAML SSO (Chapter 1), enabling GHAS org-wide (Chapter 3 s2), least-privilege roles (Chapter 1), and restricting public exposure/forking/outside collaborators. For data protection, consider visibility management of sensitive repos, secret protection (Secret Protection), and data residency (GHEC Data Residency, Chapter 2). These layer defenses so a single misconfiguration isn’t fatal.
3.1.3Audit logging and reporting
The audit log records "who did what, when" in an org/enterprise—member/role changes, policy changes, repo create/delete, access grants. For compliance and incident investigation, you can stream the audit log to a SIEM (audit log streaming) for long-term retention and correlation. Reports reveal usage/access trends to detect excessive permissions or anomalous actions. Auditing matters only when reviewed regularly, not merely recorded.
Common: (1) Policies = what members can do (repo creation/visibility/forking/Actions/outside invites/GHAS enablement); enterprise policy cascades down. (2) Rulesets = guardrails on code changes (enforce branch protection/required reviews/checks)—a separate layer from policies. (3) Audit log tracks who/when/what; can stream to a SIEM. (4) Posture is defense in depth (2FA/SSO/GHAS/least privilege).
Watch out: (1) Don’t confuse policies (capabilities) with rulesets (enforcement on code changes)—use both as separate layers. (2) Enterprise constraints can’t be loosened by orgs (cascade direction). (3) Audit logs need regular review and (if needed) SIEM streaming, not just recording. (4) Data protection combines visibility/secrets/residency—don’t rely on a single setting.
3.1.4Section summary
- Policies = member capabilities (repo creation/visibility/forking/Actions/GHAS); enterprise policy cascades down
- Rulesets = guardrails on code changes (enforce branch protection/required reviews/checks)
- Audit log tracks who/when/what; streamable to a SIEM; valuable when reviewed regularly
- Posture is defense in depth (2FA/SSO/GHAS/least privilege); data protection combines visibility/secrets/residency
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to govern org-wide whether members can make repos public and whether forking is allowed. What do you use?
Q2. You want to enforce branch protection, required reviews, and required status checks org-wide. What do you use?
Q3. For compliance/incident investigation, you want long-term retention and correlation of org activity. Appropriate means?
Q4. How can member orgs treat a security policy set at the enterprise level?
Q5. Which correctly relates policies and rulesets?
Q6. What is the problem with operating the audit log as "record only"?