Organization policy

Growing teams hit the same problem with every code-security tool: each repo owner tunes the rules their way, and the security team loses the ability to make a change once and have it apply everywhere. LGTM Security's org policy is the fix. Create an organization, attach your monitors, define one policy, done — every attached repo inherits it.

Repos still get their own overrides for anything the org has not marked as Enforced. That preserves autonomy for teams that need it while giving the security team a single knob for the rules that actually matter (block on hardcoded secrets, enforce workflow permissions, etc.).

Effective policy = mergeWithOrgPolicy(repoPolicy, orgPolicy). For every rule, the repo's action wins UNLESS the org marked the rule enforced. Allowlists always union — the repo's actions/domains/runners allowlists are added to the org's. policyVersion takes the max of the two.

This is 'repo-wins-except-enforced'. It's a load-bearing invariant in LGTM — Model B repo access gating, the per-repo policy editor, the audit-log filter, and the CI-side pipeline decision all rely on this resolver returning the same answer.

You want a single security team to define what critical means across every repo in your GitHub org. You want to guarantee that hardcoded-secret detection is 'block' everywhere, no matter what a repo maintainer sets. You want teammates to see a live count of overrides they've applied against the org baseline.

You do NOT need an org policy for a solo project or a repo with a single maintainer — the per-repo policy is enough. Orgs shine at 3+ repos and 2+ humans who care about tuning.

From the LGTM dashboard, Security → Organizations → Create. You become the sole Owner initially. Attach any of your enrolled monitors to the org from the org detail page (or via the attach API). Edit the org policy from the org policy editor — same rule + allowlist shape as a per-repo policy, plus a lock icon on each rule to mark it Enforced.