Code review, CI/CD security & AI tooling — defined plainly.

Tree-sitter is an open-source incremental parser library (born at GitHub) that builds concrete syntax trees for source code in dozens of languages. AI code-review tools use it to extract symbols, calls, and dependencies for context-aware reasoning.

PageRank applied to code: rank symbols in a repo by how 'important' they are to a given change. Built on the same algorithm Google used for web pages — but the graph is the call/import structure of your codebase. Outperforms vector embeddings for code-context retrieval.

AI code review uses large language models (and increasingly multi-agent pipelines) to review pull requests for bugs, security issues, performance regressions, readability, and style — automatically, on every PR, in 30-90 seconds.

An LLM code review pipeline is the end-to-end system that ingests a GitHub PR webhook, fetches the diff, gathers repo context, runs one or more LLM agents in parallel, synthesizes their outputs, and posts the result back to GitHub as a review with inline comments.

An adversarial verifier is a second LLM pass whose job is to refute every finding produced by the primary review agents. Findings that survive refutation are kept; findings that don't are dropped before they reach the user.

evidenceQuote is a required field on every LGTM review finding: the LLM must quote the exact offending code verbatim. Findings whose quote can't be grep'd back into the diff or the surrounding file are dropped as hallucinations before the user sees them.

A GitHub suggestion block is a fenced code block (```suggestion) inside a PR comment that renders as a one-click "Commit suggestion" button. GitHub applies the suggestion as a new commit on the PR branch when the reviewer accepts. LGTM emits suggestion blocks for mechanical single-line fixes.

A finding tier is the priority tag LGTM stamps on every inline review comment: 🎯 Actionable (fix before merge), 💡 Suggestion (worth considering), 🔍 Nitpick (take it or leave it). Tiers let reviewers triage a wall of comments in seconds.

A convention file is a repo-level Markdown document (CLAUDE.md, AGENTS.md, .cursorrules, .github/copilot-instructions.md, .windsurfrules, CONTRIBUTING.md) that tells AI assistants and reviewers how the repo prefers code to be written. LGTM ingests these and drops findings that contradict them.

.lgtm.yml is the repo-level config file for LGTM. It lives at your repo root (or .github/lgtm.yml), is opt-in per repo, and lets maintainers override 9 pipeline behaviours: mute agents, skip paths, cap severity, auto-approve docs-only PRs, override severity by category, and more. The rules are enforced at the pipeline layer, not the prompt, so the LLM can't 'forget' them.

A pull_request_target attack abuses GitHub Actions workflows that combine the pull_request_target trigger (runs with base-repo secrets) with checking out fork-controlled code, giving an attacker's fork PR access to your secrets.

Self-hosted runner abuse: an attacker forks a public repo using a self-hosted GitHub Actions runner, opens a PR, and gets remote code execution on the runner's host — often the maintainer's own infrastructure.

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.

A software supply-chain attack compromises a software product by attacking something earlier in the build/distribute chain: a dependency, a build tool, a package registry, a CI/CD pipeline, or a maintainer account. The downstream consumer ships compromised code without knowing.

A pinned GitHub Action references a specific commit SHA rather than a mutable tag (like v3) or branch. Pinning to a SHA means the action's source code can't change underneath you — a key supply-chain defense.

Prompt injection defence for AI code review means treating every user-controlled input (diff, files, PR history, repo conventions) as data — never as instructions. LGTM wraps every such input in <untrusted_KIND>…</untrusted_KIND> XML tags the system prompt is trained to ignore as commands.

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.

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.

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.

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.

ciSystem is the field LGTM Security stamps on every finding to record which CI provider the file belongs to — github-actions, gitlab-ci, circleci, azure-pipelines, jenkins, bitbucket-pipelines, or generic. It's the multi-CI data-model foundation.

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.

BYOK (Bring Your Own Key) means you provide your own AI provider API key to a SaaS tool, so all LLM calls run on your account and your bill — not the vendor's. The vendor never sees or proxies your token.

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.

India's Digital Personal Data Protection Act 2023 — defines Data Principal + Data Fiduciary roles, mandates consent, enforces from May 14, 2027.