Repository Baseline¶

A repository baseline is the minimum viable governance that every repository receives at creation. It is the GitHub equivalent of a subscription baseline in Azure Landing Zone: a predefined set of configurations, metadata, protections, and CI plumbing that ensures no repository starts from zero.

When a team creates a repository through the service catalog, the platform template delivers the baseline automatically. The team writes code from day one instead of configuring branch protection, wiring up CI, or figuring out which security scanners to enable.

What makes up the baseline¶

The baseline is not a single mechanism. It is the intersection of four layers, each managed by a different owner.

Template contents¶

Every repository created from a platform template includes the following files. The template archetype determines the exact structure, but these files are common to all archetypes.

Standard files¶

Template archetypes¶

Not every repository is a microservice. The platform provides three archetypes, each with a tailored directory structure.

Inherited controls¶

These controls apply to the repository automatically through org-level and enterprise-level configuration. The team does not need to set them up and cannot remove them.

Enterprise policies¶

Applied to every repository in every organization. Managed by the enterprise admin.

• Two-factor authentication required
• Secure 2FA methods enforced (no SMS)
• Workflow permissions default to read-only
• Allowed actions restricted to enterprise + verified creators
• Default branch name set to main

See Enterprise policies for the full list.

Org-level rulesets¶

Applied to all repositories in the organization. Managed by the cockpit automation.

• default-branch-protection — PR required, 1 approval, stale review dismissal, code owner review, status checks, no force push, no delete
• ci-enforcement — build, test, and security-scan status checks must pass
• release-protection — 2 approvals, signed commits, tag creation restricted to release automation
• sensitive-repo-protection — additional controls for repos tagged with pci, sox, or hipaa

See Rulesets for detailed rule tables.

Security features¶

Enabled at the org level and inherited by every repository.

• Secret scanning with push protection enabled
• Dependabot alerts and security updates enabled
• Code scanning (CodeQL) via the platform security-scan workflow
• Copilot Autofix enabled for code scanning alerts

Custom properties at creation¶

When the repository is provisioned, the platform automation assigns custom properties based on the team's request.

These properties drive ruleset targeting. A repository tagged compliance-scope: pci automatically receives the sensitive-repo-protection ruleset without any manual configuration.

What teams can and cannot customize¶

The baseline is a floor, not a ceiling. Teams can add strictness but cannot remove it.

Baseline verification checklist¶

Use this checklist to verify that a repository meets the baseline after creation. The platform automation should validate these items automatically; this list serves as a manual fallback.

• [ ] Default branch is main
• [ ] Branch protection via org-level rulesets is active (not bypassed)
• [ ] build, test, and security-scan status checks are required
• [ ] CODEOWNERS file exists and maps to a valid team
• [ ] Secret scanning with push protection is enabled
• [ ] Dependabot alerts are enabled
• [ ] Code scanning (CodeQL) is configured via CI workflow
• [ ] Custom properties (risk-level, compliance-scope, team-ownership) are assigned
• [ ] PR template exists at .github/PULL_REQUEST_TEMPLATE.md
• [ ] SECURITY.md exists with valid contact information
• [ ] No direct push to main is possible (force push and deletion blocked)

Anti-patterns¶

Creating blank repositories¶

Problem: A team creates an empty repository through the GitHub UI instead of the service catalog, skipping the template entirely.

Why it breaks: The repository has no CODEOWNERS, no CI stub, no PR template, and no custom properties. Org-level rulesets still apply, but the ci-enforcement ruleset will block all merges because the required status checks never run.

Fix: Enforce repository creation through the service catalog. Use the enterprise policy to restrict repo creation to org owners, and have the cockpit automation handle provisioning.

Forking a template instead of using it¶

Problem: A team forks a template repository instead of creating a new repository from it.

Why it breaks: A fork maintains a git relationship with the upstream template. Template updates create noisy pull requests. The fork's custom properties and CODEOWNERS do not match the new team.

Fix: Always use "Use this template" or the service catalog API. Never fork a template repo for project use.

Disabling security features¶

Problem: A developer disables Dependabot or secret scanning because the alerts are "noisy."

Why it breaks: The repository drops below baseline. Compliance reporting flags the gap, and the team loses visibility into real vulnerabilities hidden in the noise.

Fix: If alerts are noisy, triage and suppress false positives through .github/dependabot.yml or code scanning configuration. Do not disable the feature. If the noise is systemic, raise it with the platform team to improve the workflow.

Drift through manual changes¶

Problem: A repository starts from the template but accumulates manual changes that weaken the baseline over time (deleted CODEOWNERS, removed CI jobs, changed branch protection).

Why it breaks: Org-level rulesets cannot be removed, but template files can. A deleted CODEOWNERS file means code owner review requirements have no effect. A removed CI stub means status checks never report, blocking merges.

Fix: The nightly compliance scan catches drift. Teams should treat baseline files as infrastructure: changes require a PR and review, not silent deletion.

Next: Enterprise policies