Model B repo gating
Model B repo gating is how LGTM Security decides whether a given user can see an org-attached repo's monitor, findings, or audit log — by checking their live GitHub access against `GET /repos/{owner}/{name}`, cached 10 minutes in Redis, fail-closed on error.
Why not just check org membership?
Being an LGTM org member doesn't mean you have access to every repo attached to that org. A GitHub organization can have private repos that only a subset of its members can see. If LGTM leaked findings from a repo you don't have GitHub access to just because you happened to be an LGTM org member, that would be a data-exposure bug.
Model B fixes this by asking GitHub every time: 'does this user actually have access to this repo?' The answer is cached briefly to keep the hot path fast, but the source of truth is always GitHub.
How it works
Every attached-org repo read (monitor payload, findings, audit log, policy read) runs canUserAccessRepo(user, repo) first. That function calls GitHub's `GET /repos/{owner}/{name}` with the user's OAuth token. On 200, access is granted; on 404 or any error, access is denied — fail-closed.
Results are cached in Redis for 10 minutes keyed by (userId, repoId). Cache misses are the normal case; cache hits skip the GitHub round-trip. The original enroller of the monitor auto-passes (they clearly had access at enrollment time and we don't want a self-lockout race).
Why fail-closed
If GitHub is having a bad day, the safe default is 'don't leak data'. Model B returns 403 on any GitHub error rather than fall through to 'assume access'. Users see a temporary access error, retry works once GitHub comes back. This is the correct trade-off for a security surface — availability of a settings page is not worth risking a cross-tenant data leak.
Read the Model B contract in the docs
10-min Redis cache, fail-closed
Go to the product pageFAQs
Does Model B slow down every request?
First check is a GitHub round-trip (~200ms typical); subsequent checks within 10 minutes are Redis-cache hits (~2ms). The cache TTL is intentionally short so revoked access takes at most 10 minutes to propagate.
What if GitHub is down?
Requests fail-closed — LGTM returns 403 for the affected repos until GitHub returns 200 again. This is a deliberate trade-off: better to break a settings page than to leak findings.
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.
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.
GitHub App permissions
GitHub App permissions are the granular scopes an installed GitHub App requests on a repository: contents (read source), pull requests (read+write), checks (write Check Runs), metadata (read repo info), etc. Each permission level (none / read / write / admin) controls what the App can do with that resource.