Skip to content
Start a conversation
  1. Home
  2. Services
  3. AI-Led Code Review
Application security

AI-Led Code Review

Powered by CodeSightAI · evidence-first · runs on our machines

Review that reads intent and data flow, not just syntax - and has to show its evidence for every finding.

174

Vulnerability classes checked

15

Review phases, P0 through P14

100%

Findings backed by written evidence

0

Source code that leaves our machines

A scanner matches patterns. It has no idea what your code is trying to do, which is why it misses the broken authorization check and flags the string concatenation that was never reachable. Reading intent is the whole job, and until recently it was the part only a person could do.

CodeSightAI is the engine we built to do that work at scale. It uses a language model's reasoning to understand how data moves through your codebase - what a function intends, where the trust boundaries actually sit, which entry points reach which sinks - and then holds that reasoning to account.

Every finding has to carry written evidence: source location, CWE, OWASP category, a CVSS vector, the MITRE ATT&CK technique it would enable, and a narrative explaining how it would actually be exploited. No finding is marked complete until that evidence exists and passes an audit gate.

It runs entirely on our own machines, on a model backend we control, and your source never leaves that boundary. Everything the tool reads from a repository is treated as data rather than instruction, so a file that tries to steer the reviewer gets flagged instead of obeyed.

Today we run CodeSightAI as part of our own engagements rather than selling it. We are weighing up licensing it to teams who want to run it in-house - if that would be useful to you, tell us and it will inform where this goes.

A pattern scanner

Sees syntax.

CodeSightAI

Sees intent - the flow, the function, and what the author meant the code to do.

Same repository, two reports

Most of what a scanner reports is noise

A pattern scanner produces a long list that looks thorough. Apply a real review and most of it falls away - and the one flaw that mattered was never on the list, because it matches no pattern. The code is tidy. Its logic is wrong.

An illustration of a typical result, not a client report.

Pattern scanner

7 findings
  • HighString concatenation in a database queryA one-off migration script. Never deployed, never reachable.
  • HighHard-coded secret detectedA dummy value in a unit-test fixture.
  • MediumOutdated dependency with a known issueThe affected function is never imported.
  • MediumWeak hash algorithm in useUsed for a cache key, not for anything security-relevant.
  • MediumMissing security response headersReal and worth fixing. Low impact.
  • LowDebug logging enabledThe development settings file only.
  • LowInsecure random number generatorPicks a colour for a user avatar.

Not on this list: the settings endpoint that lets anyone read files outside the folder it is meant to serve. There is no bad pattern to match.

CodeSightAI

1 confirmed, 1 minor
Critical No login required Confirmed F-028

Settings endpoint serves files outside its intended folder

The folder check trusts a value the visitor supplies, so an anonymous request can read files the application never meant to share.

  • Reachable from the public internet, traced end to end
  • Reproduced, with written evidence attached
  • Fix suggested and re-checked after the change
  • Mapped to CWE-639 and OWASP A01

settings.go:471 · handlers/share.go:88

Under the hood

What the engine does

174 vulnerability classes

Inventories the repository, maps every entry point and walks each file for real data flow - injection, authentication, access control, SSRF, XXE, CSRF and more.

Fifteen review phases

P0 to P14, run in order: the early phases build the map that the vulnerability phases depend on.

Evidence for every finding

Each one writes a Markdown evidence file and a database snapshot with source location, CVSS vector, CWE, OWASP category and an exploit narrative.

MITRE ATT&CK mapping

Findings map to the technique they would most likely enable, so the report speaks the language your detection team already uses.

Nothing quietly dropped

The moment something looks exploitable it is captured and pinned to that file until fully reviewed, so no half-checked lead is lost to a context reset.

Prompt-injection aware

Repository contents are data, never instruction. A file that tries to influence the reviewer is reported as a finding.

An auditable record

One database is the authoritative record of the review, integrity-checked on every resume so results cannot quietly drift.

Honest about what it could not do

Work that is blocked is reported plainly as blocked. Nothing incomplete is dressed up as finished.

The review pipeline

Fifteen phases, run in order

Each phase runs a full coverage matrix rather than a single check. The early phases build the map - inventory, framework, entry points - that the vulnerability phases depend on, and a completion gate blocks the final phase while any finding is still unvalidated or missing evidence.

  1. P0
    Workspace init
  2. P1
    Repository inventory files, tech stack, dead code
  3. P2
    Framework review pack framework-specific risks
  4. P3
    Attack surface & routes entry points, GraphQL, WebSocket, webhooks
  5. P4
    Authentication JWT, OAuth/OIDC, SAML, MFA, sessions, resets
  6. P5
    Authorization IDOR/BOLA, BFLA, privilege escalation, tenant isolation
  7. P6
    Injection SQL, command, NoSQL, LDAP, XPath, SSTI, XXE, SSRF, deserialization
  8. P7
    File handling upload, arbitrary read/write, Zip-Slip, path traversal
  9. P8
    Client-side & XSS reflected, stored and DOM XSS, CSP, clickjacking
  10. P9
    Secrets, crypto & config hardcoded secrets, CSRF, CORS, TLS, weak crypto
  11. P10
    Dependencies & supply chain CVEs, typosquatting, lockfile integrity
  12. P11
    Sensitive data & logging data exposure, log injection, audit trail, privacy
  13. P12
    Rate limiting & DoS brute force, race/TOCTOU, request smuggling
  14. P13
    Variant analysis & quality gate attack chains, dedup, evidence completeness
  15. P14
    Report export readiness export integrity, evidence recovery
Output

What a finding actually looks like

Not a severity label and a line number. Every finding carries the evidence needed to confirm it, fix it, and prove it was fixed.

Critical Remote · Unauth Confirmed F-028

Broken access control on the settings endpoint via parent-directory scope

An anonymous request resolves a share scope of "..", exposing files above the intended directory.

CWE
CWE-639 · Authorization Bypass
OWASP
A01 Broken Access Control
CVSS
9.1 · AV:N/AC:L/PR:N/UI:N
ATT&CK
T1190 Exploit Public-Facing Application

settings.go:471 · handlers/share.go:88

  1. It stops when it's stuck, not when the budget runs out

    A no-progress guard ends a run that keeps re-examining blocked work instead of burning tokens in a loop. Parked work is reported plainly, never disguised as done.

  2. A control panel, not a black box

    We watch live status, findings filtered by severity and reachability, per-phase timing, and a full audit trail of every action the reviewer took.

  3. Your code stays put

    The engine runs on our own hardware against a model backend we control. Nothing is uploaded to a third-party review service, and the boundary is written into the engagement agreement.

  4. It reports complete only when it is

    Findings-audit and evidence-audit gates must both be clean before a review can be called finished. Anything blocked is listed as blocked.

Point it at the code that worries you

Tell us what the application does and what it protects, and we will tell you what a review would take.