Audit Logs, Security Policies, Compliance Evidence, Repository Governance, and Enterprise Controls: Configuration, Design Choices, and Tradeoffs

1. From evidence mechanics to governance design

Lesson 2 proved that evidence has a lifecycle: collect → preserve → normalize → verify → retain → review. Production design adds a second dimension: where should the control live? A repository file is close to code and reviewable through Git. An organization ruleset can prevent drift across many repositories. An enterprise policy can constrain organizations. An external archive can outlive GitHub's native retention. These choices trade local autonomy against consistency and operational cost.

2. GitHub-native retention versus external archive/streaming

Native audit search is excellent for recent interactive investigations because it is already indexed around GitHub actors/resources. Current documentation describes organization/enterprise audit activity within 180 days and only seven days for Git events. Exports are suitable for bounded snapshots. Enterprise streaming is designed for continuous off-platform retention and large-scale correlation, but it requires Enterprise ownership, external storage/operations, duplicate handling, and currently remains public preview.

“External” should not mean “copy to an engineer's laptop.” Use write-restricted/object-locked storage where policy requires immutability, and record collection provenance.

3. Repository policy versus organization/enterprise policy

Repository policy gives teams autonomy and makes local intent easy to review. It also scales poorly when hundreds of repositories must stay aligned. Organization-wide rulesets centralize ref policy for Team/Enterprise organizations; enterprise policies can limit organization choices on Enterprise Cloud. The further up the hierarchy a control moves, the larger the blast radius of a mistake and the more important staged rollout, exception handling, and delegated administration become.

4. Preventive control versus detective audit

A preventive control tries to stop an undesired state transition: for example, a ruleset can require pull-request review before updating a protected branch. A detective control tells you that an event occurred or a state deviated: for example, an audit event can show a team permission changed. Audit evidence is not a substitute for prevention, and prevention is not a substitute for observability. Reliable governance normally combines both.

Do not create a rule so restrictive that operators bypass it constantly. Frequent bypass turns the exception path into the normal path and destroys signal quality. A preventive control should make the safe path easier than the exception path.

5. Human-readable policy versus machine-enforced rule

SECURITY.md is optimized for people reporting vulnerabilities. CODEOWNERS expresses code stewardship. A ruleset or branch protection is optimized for GitHub enforcement. A security configuration expresses security-feature enablement at scale. These artifacts should reference the same control objective but remain independently testable.

A useful design sentence is: “The policy states what and why; the GitHub control states what the platform will enforce; the evidence plan states how we will prove operation; the exception record states when and why we intentionally deviated.”

6. Current availability boundaries

GitHub Enterprise Server must be evaluated against the exact installed version. Never copy a GitHub.com entitlement table into GHES policy without checking that release's documentation.

7. Security configurations are policy bundles, not security guarantees

A security configuration can establish consistent settings for dependency graph, Dependabot, code scanning, secret scanning, push protection, and related controls. That makes configuration drift easier to manage. It does not guarantee alerts were triaged, developers responded correctly, or every repository is eligible for every paid feature. Evidence should therefore include attachment/coverage state and operational outcomes separately.

# Read-only repository association, when your role/plan allows it.
REPO="OWNER/REPOSITORY"
gh api   -H "Accept: application/vnd.github+json"   -H "X-GitHub-Api-Version: 2026-03-10"   "repos/$REPO/code-security-configuration"   --jq '{status,configuration:(.configuration | {id,name,enforcement})}'

A 204 can mean no configuration is attached; 403/404 may be authorization/availability/resource-scope signals. Diagnose before changing policy.

8. Exceptions are governed objects, not comments

Every exception should carry a control ID, affected repository/resource, rationale, risk owner, approver, start/expiry time, compensating control, and closure evidence. “Temporary” without an expiry is permanent by default. A bypass that leaves no durable ticket/reference cannot be reliably distinguished from unauthorized policy erosion.

Exception ID: EX-2026-0042
Control: SCM-PR-REVIEW-01
Scope: service-api / refs/heads/release-hotfix
Reason: emergency rollback of a verified prior artifact
Owner: release-manager-role
Approver: security-duty-role
Starts: 2026-08-19T18:00:00Z
Expires: 2026-08-20T00:00:00Z
Compensating control: two-person out-of-band review + post-change diff
Closure evidence: PR / audit event / deployment record references

9. Worked scenario and decision table

A 40-repository organization needs consistent review policy, an incident-ready evidence trail, and low cost. The team currently has no Enterprise subscription. The practical choice is layered: repository-level public rulesets where applicable, shared policy templates/CODEOWNERS conventions, periodic state inventory, and hashed evidence exports/fixtures. If the organization later adopts Enterprise Cloud for compliance, add enterprise audit streaming rather than rewriting every repository workflow.

Knowledge check

Summary

Choose scope and evidence intentionally: human policy for intent, machine enforcement for prevention, audit/log state for detection, external retention for resilience, and expiring exceptions for controlled deviation. Lesson 4 stress-tests this design against missing events, bad filters, weak evidence storage, and unenforced policy.

Further reading — current primary sources

• About rulesets
• Creating organization rulesets
• About CODEOWNERS
• GitHub security features
• Security configurations
• Streaming the enterprise audit log