Custom detector
A custom detector is a user-authored LGTM Security rule written in a small YAML DSL. It runs alongside the 36 built-in detectors on every scan, with the same block / warn / off actions, the same audit log, and the same enforced-rule org policy.
What a custom detector is
A custom detector is a YAML definition that declares which files to scan (up to 10 globs), a pattern to match on those files (substring, regex, or a one-level-deep allOf/anyOf/noneOf combinator over up to 5 leaves), and the finding shape (severity, action, message, optional docsUrl). The scanner evaluates it exactly like the 36 built-in detectors — same block/warn/off enforcement, same immutable audit-log row, same visibility on the dashboard.
Every regex is validated with safe-regex at authoring time to reject ReDoS-prone patterns (nested quantifiers, unbounded backtracking). Every field is capped: 500-char patterns, 1000-char messages, 5 leaves per combinator, 10 globs per detector. The caps stop a single actor from starving the shared scanner.
Personal vs organization scope
Custom detectors are owned by exactly one of two scopes. Personal (ownerType=user) detectors are authored by any signed-in LGTM user and only evaluated by that user's own enrolled monitors — perfect for indie devs and for staging a rule before rolling it out. Organization (ownerType=org) detectors are authored by any Policy Admin or Owner on the org, and every attached monitor evaluates them.
Caps: 20 detectors per personal user, 100 per org. Org-scoped detectors can be marked enforced=true so per-repo overrides are blocked — the same enforced-rule contract used by the 36 built-ins.
The pattern DSL
Five pattern shapes: (1) contains — plain substring match, safe by default. (2) regex — JavaScript regex compiled with gm flags, safe-regex-validated. (3) allOf — every leaf must match, with an optional sameLine: true modifier that requires leaves to match on the SAME line rather than anywhere in the file. (4) anyOf — file-level OR. (5) noneOf — fires when NO leaf matches anywhere; useful for 'this file MUST contain X' assertions like 'every workflow must declare a permissions: block'.
Combinators are one level deep — no nested allOf inside allOf. This keeps the DSL simple and prevents exponential-blowup evaluation, both for the scanner's CPU and for the author's brain.
Marketplace and sharing
Org-scoped detectors can be shared to specific other organizations (up to 200 targets). Sharing doesn't copy — it makes the detector discoverable on the target org's Marketplace tab. Policy Admins on the receiving org click Import, and LGTM creates a COPY in their scope with sourceDetectorId pointing at the original for provenance. Deleting the source doesn't break consumers.
Every import bumps the source's importCount, surfaced in marketplace listings as 'used by N teams' social proof. Broadly-useful detectors can be nominated for promotion to a first-class built-in via team@devsbazaar.in.
Read the Custom Detectors docs
DSL reference, 15 recipes, gotchas, marketplace
Go to the product pageFAQs
Can I use a custom detector without an organization?
Yes. Personal-scope detectors (ownerType=user) work with no org. They apply only to your own enrolled monitors. When you're ready to share the rule with a team, either invite them to an org and re-author the detector under org scope, or share it via the marketplace flow.
Are custom detectors evaluated at PR time too?
Yes. The scanner runs both the built-in 36 detectors and every applicable custom detector on the same files. Custom-detector findings post as inline PR comments, contribute to the merge-block Check Run, and land in the immutable audit log — identical to built-in behavior.
What happens if a regex is unsafe?
The Zod validator runs safe-regex on every regex leaf before saving. Patterns above star-height 1 (nested quantifiers like (a+)+, unbounded lookarounds) are rejected with a message that points at the DSL docs. Fix by anchoring the regex or bounding the quantifier.
Can I export or version-control my custom detectors?
Detectors are stored as structured documents in LGTM, not in your repo. There's a CLI export command that dumps a scope's detectors as YAML — commit that file to your repo for team review, and import it back with the CLI import command. The dashboard is the source of truth; the YAML export is a diff-friendly mirror.
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.