Every fork is a potential attacker.
LGTM reads every PR before you do.
Open-source maintainers have a problem no closed-source team has: every incoming PR is from a stranger, possibly adversarial. Supply-chain attacks against OSS repos — self-hosted runner abuse, pull_request_target exploits, dependency confusion — keep showing up in postmortems. LGTM reviews every PR with 6 AI agents and 16 deterministic security detectors so you catch the bad ones before they merge.
The OSS-specific threat model
Closed-source teams worry about bugs. OSS maintainers also worry about malicious contributors — and they've been burned. A non-exhaustive list of real attack patterns LGTM Security catches:
Self-hosted runner on a public repo
A maintainer adds runs-on: self-hosted for the CI to use a beefy build machine. An attacker forks, opens a PR that exfils AWS credentials via the runner. Several real-world incidents have happened this way. LGTM flags self-hosted runners on any workflow triggered by pull_request from forks.
pull_request_target + checkout PR code
The "pwnrequest" pattern: pull_request_target runs with base-repo secrets, but if combined with actions/checkout@v4 ref: ${{ github.event.pull_request.head.sha }} it checks out fork-controlled code. Fork code now has access to your secrets. LGTM Security flags this exact combination.
Mutable action refs
actions/checkout@v3 looks safe but v3 is a moving tag. If actions/checkout were ever compromised, the tag could be retagged to a malicious commit. LGTM flags any action pinned to a tag/branch instead of a full commit SHA — across all your workflows.
Secret echo in workflow run blocks
Subtle: a contributor's PR adds run: echo "$SECRET" | base64. GitHub's secret-masking pass doesn't catch base64'd values. The secret leaks in CI logs. LGTM flags echo + base64 + secret combos at PR time.
Untrusted input flowing into shell
PR title becomes shell: run: echo "PR: ${{ github.event.pull_request.title }}". A malicious title injects commands. LGTM Security catches the pattern across run blocks and script: blocks.
Permissions block missing
Without an explicit permissions: block, workflows inherit the repo-wide default — historically write-all. A compromised step can mint releases, push tags, or read every secret. LGTM Security flags missing permissions: at the top of every workflow.
See the full 16-detector list on the LGTM Security product page. Each rule has a severity, why-it-matters explanation, and a sample trigger.
What LGTM does on an incoming PR
From the maintainer's perspective: a stranger's PR opens. Three things happen automatically.
Security pre-screen
The 16 deterministic detectors run on the diff. If a PR adds a self-hosted runner workflow or pull_request_target + checkout-head-sha, the merge-block Check Run lights up red. You see it before you even open the PR.
Bug + readability review
The 6 AI agents read the diff and post inline comments. You get a synthesizer verdict + top findings. Even if you skim the PR, the agents have already flagged the obvious issues.
Style + convention feedback
The convention extractor knows your repo's patterns (HTTP client, error handling, naming). The reviewer flags when a contributor's PR uses moment.js in a date-fns repo — helpful nudges, not gatekeeping.
What contributors see
LGTM is opt-in to your repo, not your contributors'. They don't sign up. They don't add a key. From their side it looks identical to a maintainer review — just faster.
Example LGTM comment on a contributor PR
LGTM Review: request_changes · Confidence 82%
Thanks for the contribution! Two things to address before merge:
- · Line 24 of
workflow.yml:actions/checkout@v3pinned to a mutable ref — pin to a commit SHA. (workflow.action-pinned-to-mutable-ref) - · Line 88 of
cache.ts:getUser()can return null but the caller derefs.emailwithout a guard.
Contributor reads, makes the changes, pushes. The maintainer never had to type the explanation — and the contributor learned the pattern for next time.
Why deterministic checks beat LLM-only review for security
LLM-based reviewers will sometimes miss the supply-chain patterns above — model attention is finite, security signals are easy to miss in long diffs. LGTM Security runs separate deterministic detectors on top of the 6 AI agents:
Deterministic
Same diff, same finding. No LLM moodiness. A regulator can re-run the scan and reproduce the result.
Free + open
The detectors are part of LGTM Free read-only access. You can see every finding without paying. Pro adds enrollment + alerts + watchdog.
No source leaves your repo
Security detectors operate on the diff hunks LGTM already has. No additional source-code exposure beyond the standard review pipeline.
For maintainers of large / high-traffic OSS
If you maintain a repo with hundreds of incoming PRs per month, here's how we can help — and what's honestly out of scope.
Where LGTM helps
- Filters PRs into "obviously needs work" vs "ready for human review"
- Catches supply-chain attack patterns deterministically
- Provides consistent style/convention feedback so you don't have to repeat it
- Audit log keeps a record of every security finding (useful when a CVE post-mortem asks "was this flagged?")
What's out of scope
- ·Judgement calls about architecture / API design — LGTM doesn't know your project goals
- ·Whether a feature should be merged at all — that's your call
- ·Community / interpersonal dynamics — auto-comments can feel impersonal; you decide how to use them
- ·Replacing a CODEOWNERS workflow — LGTM augments, doesn't replace, your existing process
OSS-maintainer FAQ
Does LGTM cost money for OSS?
Do contributors need to sign up for LGTM?
Will LGTM auto-merge PRs?
Can LGTM close abandoned PRs / lock issues?
What about license-checking + DCO?
What if a contributor PR adds malicious code?
Can I see the source of LGTM Security's detector rules?
Does LGTM respect CODEOWNERS?
Free, automated, supply-chain-aware review for your OSS
Install the GitHub App. Connect the repo. The next incoming PR gets reviewed by 6 AI agents + scanned by 16 security detectors. The maintainer's side is unchanged.