CodeSight

189

Vulnerability classes checked

16

Review phases, P0 through P15

LIVE

Findings replayed against a real running instance

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.

It reviews the AI and LLM code itself, not only the application around it. When it finds a model SDK, prompt files or agent and tool definitions, it runs a dedicated phase against the OWASP Top 10 for LLM Applications and MITRE ATLAS: prompt injection, including through retrieved documents, excessive agency, insecure output handling, secrets in prompts and retrieval isolation. Sending us just an agent or a prompt library? We can run the AI review on its own.

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

When the application can be run, we switch on live validation. CodeSightAI stands up a sealed, network-isolated instance of your own application for the review and replays each finding against it, saving the screenshot and the full request and response as proof. The instance is built when the run starts and torn down the moment it stops.

Where a sealed sandbox is not the right place to prove a finding, the same validation can run against an environment you have authorised us to test - your own staging or production-like target. That path is gated: your written attestation is stored first, then every request is checked against an allowlist of hosts and paths, rate-limited per minute, non-destructive unless you say otherwise, credentialled from encrypted storage and logged in full. It drives a real browser session, so single-page applications, WebSockets and data loaded by POST behave as they do for a real user, and a live feed shows what was allowed and what was blocked.

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 - then reproduces the exploit against a live, sealed instance to prove it is real.

What you walk away with

Findings with the vulnerable code, a proof of concept and a suggested fix
Proof, not just a claim: findings replayed against a live, sealed instance, with screenshot and transcript
Validation against your own authorised environment where the sandbox is not the right place, every request scope-checked, rate-limited and logged
Logic, authorization and AI-specific flaws scanners cannot see
CWE, OWASP (including the LLM Top 10), CVSS and ATT&CK or ATLAS on every finding
An audit-ready report in PDF, Word, HTML, JSON or SARIF, with a full action trail
Send the code however suits you: an archive, a public GitHub repository, or a project package from an earlier review
Honest coverage: cleared areas recorded, anything unresolved reported plainly
Your code, the sandbox and the report stay on our machines throughout

Interested in licensing it?

CodeSightAI is in-house tooling today. We are weighing up whether to license it - if you would want to run it yourself, say so.

Register your interest

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 much of it falls away - and the flaws that matter most were never on the list, because they match no pattern. The code is tidy. Its logic is wrong.

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

Pattern scanner

7 findings

High String concatenation in a database query A one-off migration script. Never deployed, never reachable. False positive
High Hard-coded secret detected An example value copied from the documentation. False positive
Medium Outdated dependency with a known issue Real, but the vulnerable function is never called. Upgrade during routine maintenance. Confirmed, lower risk
Medium Weak hash algorithm in use Used for a cache key, not for anything security-relevant. False positive
Medium Missing security response headers Real. Two headers are missing on every page. A quick fix. Confirmed
Low Debug logging enabled Worse than reported: the debug log writes session tokens in production. Confirmed, higher risk
Low Session cookie without SameSite attribute Real, though browsers already default to Lax. Set it explicitly. Confirmed

Not on this list: the settings endpoint resolves a share scope of ".." for an anonymous caller - a full read above the intended directory. No signature fires, because nothing is syntactically wrong.

CodeSightAI

6 findings, 0 false positives, 1 reproduced live

Critical No login required Confirmed Reproduced in sandbox F-028

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

An anonymous request resolves a share scope of "..", so the handler joins it onto the share root and lists files above the intended directory - no authentication, no containment check.

handlers/share.go

86func (h *ShareHandler) List(w http.ResponseWriter, r *http.Request) {87    scope := r.URL.Query().Get("scope")      // from query88    path := filepath.Join(h.shareRoot, scope) // ".." escapes root89    files, _ := os.ReadDir(path)              // no auth, no check90    writeJSON(w, files)91}

Request and response

GET /api/settings?scope=..%2f..%2f HTTP/1.1Host: portal.exampleHTTP/1.1 200 OK{"files": ["config/", "tenants/", "uploads/", "secrets.env"]}reproduced in sandbox · screenshot and transcript saved

handlers/share.go

     scope := r.URL.Query().Get("scope")-    path := filepath.Join(h.shareRoot, scope)+    path := filepath.Join(h.shareRoot, filepath.Clean("/"+scope))+    if !strings.HasPrefix(path, h.shareRoot+string(os.PathSeparator)) {+        http.Error(w, "forbidden", http.StatusForbidden)+        return+    }+    // and require an authorized session before listing     files, _ := os.ReadDir(path)

Reproduced against a live, sealed instance, with screenshot and transcript
Remote and pre-auth: CVSS 9.1, scope changed
Mapped to CWE-639, OWASP A01 and ATT&CK T1190

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

Also found by CodeSightAI

5 more, 1 missed by the scanner

High Report download skips the ownership check A second handler serves any team's reports to any signed-in user. Missed by the scanner
High Debug logging leaks a session token Tokens written to the production log can be replayed to sign in. Also flagged by the scanner
Low Missing security response headers Two headers, set once in the middleware. Also flagged by the scanner
Low Session cookie without SameSite attribute Defence in depth: set it explicitly instead of relying on browser defaults. Also flagged by the scanner
Low Outdated dependency with a known issue The advisory's vulnerable function is never called. Upgrade during routine maintenance. Also flagged by the scanner

Pattern scanner

7 findings

High SQL injection in the report builder The query goes through the ORM's parameterised API. The flagged string is a column label. False positive
High Hard-coded cloud access key The example key from the provider's documentation. False positive
Medium Missing CSRF protection The API authenticates with bearer tokens, not cookies. There is nothing to forge. False positive
Medium Open redirect after checkout Real. The allow-list check only looks at how the address starts, so shop.example.attacker.test passes. Confirmed
Medium Detailed error messages returned Real on staging only, where stack traces reach the client. Confirmed, lower risk
Low Outdated test framework A development dependency. Never shipped. False positive
Low Timing-unsafe string comparison Real. It compares webhook signatures, and the fix is one line. Confirmed

Not on this list: the refund endpoint that never adds up earlier refunds, so one order can be refunded again and again. It is valid code doing the wrong thing.

CodeSightAI

6 findings, 0 false positives, 1 reproduced live

Critical Any signed-in customer Confirmed Reproduced in sandbox F-014

Refunds can exceed the original payment

Each refund is compared with the order total on its own. Earlier refunds are never subtracted and the amount's sign is never checked, so repeated refunds send out far more than the customer paid.

refunds/service.ts

140async refund(orderId: string, amount: number) {141  const order = await this.orders.get(orderId);142  if (amount > order.total) throw new RefundError("exceeds order");143  await this.provider.refund(order.paymentId, amount);144}

Request and response

POST /v1/orders/ord_7Q2/refunds   {"amount": 4000}201 Created   refunded 40.00POST /v1/orders/ord_7Q2/refunds   {"amount": 4000}201 Created   refunded 40.00POST /v1/orders/ord_7Q2/refunds   {"amount": 4000}201 Created   refunded 40.00order total 50.00 · refunded 120.00

refunds/service.ts

   const order = await this.orders.get(orderId);-  if (amount > order.total) throw new RefundError("exceeds order");-  await this.provider.refund(order.paymentId, amount);+  if (!Number.isInteger(amount) || amount <= 0) throw new RefundError("invalid amount");+  await this.ledger.withLock(orderId, async (tx) => {+    const refunded = await tx.refundedTotal(orderId);+    if (refunded + amount > order.total) throw new RefundError("exceeds order");+    await tx.recordRefund(orderId, amount);+    await this.provider.refund(order.paymentId, amount);+  });

Traced from the public API to the payment provider call
Reproduced against the staging ledger, evidence attached
Mapped to CWE-840 and OWASP API6

refunds/service.ts:142

Also found by CodeSightAI

5 more, 2 missed by the scanner

High Any customer can read any order The order lookup never checks who owns the order: names, addresses and card details. Missed by the scanner
Medium A coupon can be used twice at the same moment Two checkouts in parallel both pass the single-use check. Missed by the scanner
Medium Open redirect after checkout The allow-list only checks how the address starts. Also flagged by the scanner
Low Timing-unsafe string comparison Webhook signatures. A one-line fix. Also flagged by the scanner
Low Detailed error messages returned Staging only. Also flagged by the scanner

Pattern scanner

7 findings

High Cross-site scripting sink The HTML comes from a translation file built into the app, never from a user. False positive
High TLS certificate checks disabled Only in the integration-test HTTP client. False positive
Medium MD5 in use Builds cache tags. Nothing secret is hashed. False positive
Medium No rate limit on sign-in Real: it allows password guessing. Partly covered by the firewall. Confirmed
Medium Debug endpoint exposed Worse than reported: the management endpoint that lists environment settings is reachable in production. Confirmed, higher risk
Low Predictable random numbers Seeds a loading animation. False positive
Low Weak password policy Real. Six-character passwords are accepted. Confirmed

Not on this list: the reset link that is not tied to the account it was issued for. A token requested for your own account resets anyone else's password.

CodeSightAI

6 findings, 0 false positives, 1 reproduced live

Critical Any registered user Confirmed Reproduced in sandbox F-003

Password reset tokens work for any account

The reset handler checks that the token is genuine and unexpired, then takes the account from the request instead of from the token. Request a reset for yourself, then use it on someone else.

auth/ResetController.kt

94@PostMapping("/password/reset")95fun reset(@RequestBody req: ResetRequest): ResponseEntity<Unit> {96    val token = tokens.findValid(req.token) ?: return badRequest()97    val user = users.findByEmail(req.email) ?: return badRequest()98    user.password = encoder.encode(req.newPassword)99    users.save(user)100    return ok()101}

Request and response

POST /password/forgot   {"email": "me@attacker.test"}200 OK   reset link emailed to me@attacker.testPOST /password/reset{"token": "8f3c…e19a", "email": "ceo@victim.example", "newPassword": "••••••••"}200 OKsigned in as ceo@victim.example

auth/ResetController.kt

     val token = tokens.findValid(req.token) ?: return badRequest()-    val user = users.findByEmail(req.email) ?: return badRequest()+    val user = users.findById(token.userId) ?: return badRequest()+    tokens.consume(token)  // one use, own account only     user.password = encoder.encode(req.newPassword)

Account takeover shown end to end, without access to the victim's email
Reproduced, with request and response evidence
Mapped to CWE-640 and OWASP A07

auth/ResetController.kt:97

Also found by CodeSightAI

5 more, 2 missed by the scanner

High Sessions survive a password reset Whoever was signed in stays signed in after the owner resets the password. Missed by the scanner
High Debug endpoint exposed The management endpoint lists environment settings in production. Also flagged by the scanner
Medium Reset responses reveal which emails have accounts Known and unknown addresses get different answers. Missed by the scanner
Medium No rate limit on sign-in Password guessing is possible. Partly covered by the firewall. Also flagged by the scanner
Low Weak password policy Six-character passwords are accepted. Also flagged by the scanner

Under the hood

What the engine does

Reproduced in a live sandbox

Optionally stands up a sealed, network-isolated instance of the target and replays each finding against it, capturing real screenshots and request and response transcripts. It is torn down the moment the run stops, finishes or is killed, and isolation is hardened with a gVisor or Kata runtime.

Beyond the sandbox: an authorised live target

The same replay can run against an environment you have authorised, gated by a stored written attestation, an allowlist of hosts and paths, a per-minute rate limit, non-destructive-by-default mutation control, encrypted credentials and a full audit trail - with a live feed of allowed and blocked requests and one-click evidence capture onto the finding.

189 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.

Sixteen review phases

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

Reviews AI code, not just app code

A dedicated AI/LLM phase covers the full OWASP Top 10 for LLM Applications (2025) and MITRE ATLAS whenever it finds model SDKs, prompts, or agent and tool definitions.

Full review, or AI only

For an agent or a prompt library, the review can run just the AI assessment, so you get exactly the testing that applies to the code you sent.

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 and ATLAS

Application findings map to the ATT&CK technique they would most likely enable, and AI findings to MITRE ATLAS, so the report speaks the language your detection and threat teams use.

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.

An auditable record

One database is the authoritative record of the review, written only through its helper tool and integrity-checked on every resume, so results cannot quietly drift.

Reports in five formats

A print-ready PDF, an editable Word document, a self-contained HTML page, structured JSON, or SARIF for GitHub code scanning and your SAST dashboard - all from the same evidence, and only once the audit gates pass.

The review pipeline

Sixteen phases, run in order

Each phase runs a full coverage matrix rather than a single check - 189 vulnerability classes in all. The early phases build the map - inventory, framework, entry points - that the vulnerability phases depend on. The AI/LLM phase runs after the core review whenever AI code is present, and a completion gate blocks the final phase while any finding is still unvalidated or missing evidence.

P0
Workspace init the database, schema and audit log the review is recorded in
P1
Repository inventory files, tech stack, AI artifacts, dead code
P2
Framework review pack sources, sinks and sanitizers for the frameworks in use
P3
Attack surface & routes entry points, GraphQL, WebSocket, webhooks, jobs
P4
Authentication JWT, OAuth/OIDC, SAML, MFA, sessions, resets
P5
Authorization IDOR/BOLA, function-level access, privilege escalation, tenant isolation, mass assignment
P6
Injection 36 classes: SQL, command, NoSQL, LDAP, XPath, SSTI, XXE, SSRF, deserialization, prototype pollution
P7
File handling upload, arbitrary read/write, Zip-Slip, path traversal
P8
Client-side & XSS reflected, stored and DOM XSS, CSP, clickjacking, client-side token storage
P9
Secrets, crypto & config hardcoded secrets, CSRF, CORS, TLS, security headers, weak crypto
P10
Dependencies & supply chain CVEs, typosquatting, lockfile integrity, install-time scripts
P11
Sensitive data & logging data exposure, log injection, audit trail, privacy
P12
Rate limiting & DoS brute force, race/TOCTOU, request smuggling, resource exhaustion
P13 · AI
AI / LLM application security 15 classes: OWASP LLM Top 10 and ATLAS - prompt injection (direct and through retrieved content), excessive agency, tool-call SSRF, output handling, secrets in prompts, retrieval isolation
P14
Variant analysis & quality gate attack chains, deduplication, evidence completeness
P15
Report export readiness export integrity, evidence recovery

An authorised live target. Where a sealed sandbox is not the right place to prove a finding, the same replay can run against an environment you have authorised us to test. Your written attestation is stored first; then every request is checked against an allowlist of hosts and paths, rate-limited per minute, non-destructive unless you say otherwise, credentialled from encrypted storage and logged in full - with a live feed of what was allowed and what was blocked, and one-click evidence capture onto the finding. It drives a real browser session, so single-page applications, WebSockets and data loaded by POST behave as they do for a real user.

Live validation. When it is switched on, a sealed, network-isolated instance of the target runs for the whole review: findings are replayed against it as they are raised, and the captured screenshots and transcripts feed the P14 quality gate. The sandbox is built when the run starts and torn down the instant it stops, finishes or is killed - nothing is left running.

Output

What a finding looks like

One record, fully populated.

Critical · 9.1 Remote · Unauth Confirmed Reproduced in sandbox Confidence: High F-028

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

An anonymous request resolves a share scope of "..", so the handler joins it onto the share root and lists files above the intended directory - no authentication, no containment check.

Class: Path traversal to broken access control
CWE: CWE-639 · Authorization Bypass Through User-Controlled Key
OWASP: A01:2021 Broken Access Control
CVSS: 9.1 · Critical
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
ATT&CK: T1190 Exploit Public-Facing Application
Found in: P5 · Authorization
Status: Confirmed, validated live in sandbox

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

Vulnerable code

handlers/share.go:88

scope := r.URL.Query().Get("scope")   // from querypath  := filepath.Join(shareRoot, scope) // ".." escapes rootfiles, _ := os.ReadDir(path)             // no auth / check

Attack chain

unauthenticated request
scope=..
Join escapes the root
ReadDir lists the parent
files disclosed

Why it matters

Any unauthenticated caller can walk out of the share root and read arbitrary directories the process can see - configuration, other tenants' uploads, secrets on disk. It is remote, pre-auth, and needs no special conditions, which is why it scores 9.1 with a changed scope.

Suggested fix

handlers/share.go

-path := filepath.Join(shareRoot, scope)+clean := filepath.Join(shareRoot, filepath.Clean("/"+scope))+if !strings.HasPrefix(clean, shareRoot+string(os.PathSeparator)) {+    http.Error(w, "forbidden", http.StatusForbidden); return+}+// and require an authorized session before listing

Live evidence captured in sandbox

Proof of concept: GET /api/settings?scope=..%2f..%2f returned 200 OK, listing files above the share root
Screenshot of the traversed listing and the full request and response transcript saved to the finding
Read-only exploit - no state changed, so no snapshot revert was needed

How it runs

Why teams keep it

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. When a review finishes with items it could not close, it says so plainly - never disguised as failed, or as done.
A control panel, not a black box

We import the code as an archive, a public GitHub repository or a project package, set the run options, and watch live status, findings by severity, per-phase timing and token accounting, live sandbox status, a source browser, and a full audit trail. When a live target is in use, the same panel shows every request as it is allowed or blocked.
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. It also runs on fully local models, so if your code must not leave our network, it does not.
It reports complete only when it is

Findings-audit and evidence-audit gates must both be clean before a review can be called finished. Only then is the report exported - as PDF, Word, HTML, JSON or SARIF - and anything blocked is listed as blocked.

Most of what a scanner reports is noise

Pattern scanner

CodeSightAI

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

Also found by CodeSightAI

Pattern scanner

CodeSightAI

Refunds can exceed the original payment

Also found by CodeSightAI

Pattern scanner

CodeSightAI

Password reset tokens work for any account

Also found by CodeSightAI

What the engine does

Sixteen phases, run in order

What a finding looks like

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

Vulnerable code

Attack chain

Why it matters

Suggested fix

Live evidence captured in sandbox

Why teams keep it

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

A control panel, not a black box

Your code stays put

It reports complete only when it is

Point it at the code that worries you