Skip to main content
Every pull request is a potential security event. New endpoints, modified authentication flows, updated dependencies, and changed business logic all introduce risk. Most teams either review PRs manually (slow, inconsistent, and dependent on who’s available) or skip security review entirely and hope the next pentest catches what slipped through. Static analysis tools flag patterns, but they produce noise — alerts that require a human to determine whether they’re exploitable. By the time a security engineer triages the backlog, the code has already shipped.

How Neo Solves This

When a developer opens a pull request on a connected repository, Neo automatically:
  1. Analyzes the code changes — reads the diff, understands what was modified, and identifies security-relevant changes: new endpoints, authentication logic, input handling, data flows, and dependency updates.
  2. Correlates with the running application — connects the code changes to your staging or QA environment and tests whether the changes introduce exploitable vulnerabilities in the context of the full running application.
  3. Validates exploitability — attempts to exploit any potential vulnerabilities it identifies, capturing payloads, execution traces, and reproduction steps. Only validated findings are reported.
  4. Posts findings on the PR — comments directly on the pull request with full evidence: what was found, how it was exploited, the specific lines of code involved, and exactly how to fix it. The developer sees the findings in their normal review flow without switching tools.
  5. Retests when the fix is pushed — if the developer pushes a fix to the same PR, Neo automatically retests to confirm the vulnerability is resolved before the PR merges.

What This Looks Like in Practice

A developer opens a PR that adds a new search endpoint to your API. Neo detects the new endpoint, identifies that user input flows into a database query without parameterization, tests the running application to confirm the injection is exploitable, and posts a comment on the PR:
🔴 Critical: SQL Injection in /api/v2/search

The `query` parameter is concatenated directly into a SQL statement 
in src/api/handlers/search.go:87. Neo confirmed exploitation against 
staging with the following payload:

  POST /api/v2/search
  {"query": "' OR 1=1; --"}

  Response: 200 OK (returned 4,217 records)

Fix: Use parameterized queries with db.Query() placeholders 
instead of string concatenation on line 87.

Full evidence and reproduction steps →
The developer fixes the query, pushes the update, and Neo retests — confirming the injection is resolved before the PR merges.

What You Get

  • Every PR reviewed for security — consistently, automatically, without depending on a security engineer’s availability
  • Validated findings only — no static analysis noise, no theoretical alerts, only issues Neo confirmed are exploitable
  • Findings in the developer’s workflow — posted directly on the PR where the developer is already working
  • Automatic retesting — fixes are verified before merge, so resolved issues stay resolved
  • Full evidence trail — every finding includes payloads, traces, and reproduction steps for audit and compliance

Setup

To enable PR security reviews:
  1. Connect your GitHub repositories in Settings → Integrations → GitHub
  2. Add at least one application environment in Settings → Environments and link it to the relevant repository
  3. Enable automatic PR reviews in Settings → Automation → PR Reviews and select which repositories should trigger reviews
Once enabled, every new PR on the selected repositories triggers an automatic security assessment.