Policy inheritance
Policy inheritance in LGTM Security is how a repo's effective policy is computed: repo policy overlaid on org policy, repo wins on every non-enforced rule, allowlists always union.
The resolution rule
mergeWithOrgPolicy(repoPolicy, orgPolicy) is the ground truth. For every rule, the resolver returns the repo's action UNLESS the org marked the rule enforced — then the org's action wins. Allowlists (actions, domains, runners) are always unioned across repo and org. policyVersion takes the max.
This resolver runs everywhere that needs an effective policy: the ci-security agent on the PR side, the monitor-side scan job, the Model B repo-access gate, the pipeline decision endpoint, and the per-repo Policy editor's chip UI.
The chips users see
The per-repo policy editor renders one of three chips on every rule row: 'Enforced by <org>' (locked, no edit), 'Inherited from <org>' (the org set an action, repo has no local override), or 'Override (default: X)' (repo overrides with a Reset-to-inherited button). A banner at the top counts the total overrides and offers a Reset-all-overrides button.
What does NOT change on inheritance
Standalone monitors (no org attached) are unchanged — their policy resolves directly with no merge. This is a strict no-op path preserved by design so users who don't opt into orgs see identical behavior to pre-org LGTM. The 'no-org fallthrough' unit test protects this.
Read the effective-policy contract
Repo-wins-except-enforced; allowlist union
Go to the product pageFAQs
What happens on allowlist overlap?
Allowlists union. If the org allowlists `actions/*` and the repo allowlists `myorg/*`, the effective allowlist is both. There is no way to remove an org-added allowlist entry from a repo — you can only add.
What if two repos disagree about a rule action?
That's fine — inheritance is per-repo. Each attached monitor resolves its own effective policy against the shared org policy. Only enforced rules force uniformity.
Related terms
Organization policy
An organization policy is a shared LGTM Security policy that applies to every repository attached to an organization. Repos can layer their own overrides on top, except on rules the org marks as Enforced.
Enforced rule
An enforced rule is an LGTM organization security rule the org has marked so that no attached repo can override its action. Enforced by <org> shows up as a locked chip on the per-repo policy editor.
CI/CD security
CI/CD security covers the attack surface introduced by your build and deploy pipelines: GitHub Actions workflows, Dockerfiles, IaC configs, dependency management, and secret handling. Distinct from (and complementary to) application-layer AppSec.