Multi-Repo Governance: One Policy, Many Repositories

Right now, somewhere in your org, a repository has governance rules from eight months ago. Nobody updated them when the policy changed. Nobody knows which repos are current and which are stale. If an auditor picked a random repo and compared its config to your stated security policy, would they match?

I watched a team burn three full sprints trying to answer that question. Two hundred repositories. Thirty-seven unique variations of the governance config. Eleven repos with no config at all — governance was “planned but not yet rolled out.” The payment service had weaker review rules than the marketing blog. Nobody noticed for five months.

Copy-paste governance across repositories is not governance. It is the appearance of governance with a drift problem baked in from day one.

The Copy-Paste Trap

It starts innocently. You configure governance for your first repository. The config works. Your second repository gets the same file, maybe with a small tweak. By the fifth repository, you have a “template” that you paste into new repos during setup.

By the fiftieth repository, you have fifty versions of that template, each slightly different. Some differences are intentional — the payments repo has stricter rules. Most are accidental — someone updated the AI model list six months ago in their repo but not in the template.

This is the same problem that infrastructure-as-code solved for server configuration. Nobody manually configures fifty servers anymore. But teams still manually configure fifty governance policies. That is a category error. Governance policy is infrastructure. Treat it like infrastructure.

The Policy Repository Pattern

GuardSpine’s solution is a dedicated policy repository. One repository, owned by the security or platform team, that contains the governance policy for the entire organization.

The structure looks like this:

guardspine-policy/
  org-policy.yml          # Organization baseline
  teams/
    payments.yml          # Team-level overrides
    platform.yml
    mobile.yml
  repos/
    auth-service.yml      # Repo-level overrides (rare)

The org-policy.yml defines the baseline. Every repository in the organization inherits this policy unless overridden. It specifies:

• Minimum risk tier thresholds per branch
• Required AI models in the review council
• Evidence bundle requirements (which fields are mandatory)
• Escalation rules
• Excluded file patterns (org-wide, like generated protobuf files)

Team-level overrides in teams/ extend or tighten the baseline. A team override cannot weaken the org baseline. If the org requires two AI reviewers, a team cannot reduce that to one. But a team can add a third reviewer, raise the risk threshold, or add team-specific excluded paths.

Repository-level overrides in repos/ handle genuine edge cases. A repo that contains only Terraform modules might need a different file-pattern configuration than the default. A repo that interfaces with a legacy system might need specific model instructions. These are rare and should stay rare.

How Policy Propagation Works

When a PR is opened in any governed repository, GuardSpine resolves the effective policy through three steps:

1. Fetch the org baseline from the policy repository.
2. Check if a team override exists for the repository’s team. If so, merge it with the org baseline (stricter wins on conflicts).
3. Check if a repo override exists. If so, merge it with the result of step 2 (stricter wins).

The resolved policy is cached per repository with a TTL of 15 minutes. Policy changes propagate within 15 minutes to every governed repository without any per-repo action. No PRs to update config files. No deployment scripts. No “did you remember to update the config in all thirty repos?”

When you merge a change to org-policy.yml, every repository picks up the new baseline within 15 minutes. When you merge a change to teams/payments.yml, only the payments team’s repos pick up the change. The blast radius matches the scope of the change.

Inheritance Rules

The merge logic follows three principles:

Additive fields accumulate. If the org policy lists two required AI models and the team policy adds a third, the effective policy requires all three. Models are never removed through inheritance.

Threshold fields take the maximum. If the org sets a minimum risk tier of L2 and the team sets L3, the effective threshold is L3. Risk thresholds only go up, never down.

Boolean fields AND together for restrictions, OR together for permissions. If the org requires evidence bundles (require_bundles: true) and a team tries to set require_bundles: false, the effective value is true. Restrictions are sticky.

These rules mean that a team or repo can always make governance stricter but never weaker. The security team sets the floor, and nobody can lower it without changing the org policy itself — which is itself a governed change with an evidence bundle.

Policy Changes Are Governed Changes

This is the part most governance tools miss. The governance policy is one of the most security-critical artifacts in your organization. A change to the policy affects every repository. A malicious or accidental policy weakening could disable protections across the entire codebase.

GuardSpine applies governance to its own policy repository. A PR that modifies org-policy.yml gets the highest risk tier (L4) automatically. It requires security team review. It generates an evidence bundle. The policy change itself has a full audit trail.

This is not a philosophical choice. It is a practical one. When an auditor asks “who approved the change to your governance policy and when,” you need the same quality of answer you provide for code changes. Evidence bundles give you that.

Handling Acquisitions and Mergers

When you acquire a company or merge engineering organizations, you suddenly have hundreds of new repositories that need governance. The policy repository pattern makes this tractable.

Step 1: Add the new repositories to your GitHub organization (or equivalent).

Step 2: Install the GuardSpine GitHub App at the org level. Every new repo is automatically governed by the org baseline.

Step 3: Create team override files for the acquired teams if their risk profiles differ from your baseline.

Step 4: Done. No per-repo configuration. No onboarding meetings about governance setup. The acquired repos are governed from the moment they join the org.

I have seen this process take two days for 200 repositories. Without centralized policy, the same migration took three months and still had gaps.

Monitoring Policy Health

A centralized policy is only as good as your visibility into its effectiveness. Three signals tell you whether the policy is healthy:

Override density. How many team and repo overrides exist relative to the total repository count? If 60% of repos have overrides, your org baseline is wrong — it is either too strict (driving override requests) or too generic (forcing teams to customize). Aim for 10-20% of repos having overrides.

Policy age. When was the org baseline last updated? A policy that has not changed in six months is either perfect or ignored. Review it quarterly. The threat landscape changes. Your codebase changes. Your AI models change. The policy should change too.

Conflict rate. How often does the merge logic resolve a conflict between levels? High conflict rates mean teams are frequently pushing against the org baseline. Either the baseline needs updating or the teams need education on why the baseline exists.

Migration Path

If you are currently using per-repo config files, here is how to migrate:

1. Export all existing .guardspine.yml files across your repos. Diff them to find the common baseline and the intentional variations.
2. Create the policy repository. Set the org baseline to the common denominator of your existing configs.
3. Create team overrides for the intentional variations.
4. Remove the local .guardspine.yml files from each repository (or leave them as repo-level overrides if they contain genuinely repo-specific settings).
5. Verify by opening a test PR in each team’s representative repo and confirming the resolved policy matches expectations.

The migration is a one-time cost. The ongoing benefit is never having to copy a config file again.

Book a call if you want help designing your policy hierarchy. I will bring examples from organizations at your scale.