Reviewer
Security review of your proprietary code, on your own hardware.
Your proprietary source code gets AI security review without ever leaving your network.
Repositories, pull requests, build artifacts, dependency manifests, API specifications, infrastructure-as-code and deployment configuration are analysed locally. Scanner findings are correlated and explained; vulnerabilities are prioritised by exploitability, reachability, exposure and data sensitivity.
- Approved repositories and pull requests
- Dependency manifests, API specifications, IaC and deployment configuration
- SAST, SCA, secret-scanning, IaC, container and API-scanner output
- Explicitly authorised test applications, within a declared scope
The complete web-application delivery surface
Reviewer is designed for customer-hosted Microsoft IIS and common Linux and Unix application stacks. It examines approved source, dependencies, server configuration, APIs, containers, infrastructure-as-code and build artefacts inside the customer network. Platform support means evidence from named scanners and parsers—not a claim that one model understands every stack equally.
First-wave stack for product evaluation and connector validation.
Coverage depends on the selected engine, language, framework and available artefacts.
A proprietary or less common stack requires an agreed parser, connector and test corpus.
Web servers, application servers and runtimes
Languages and machine-readable artefacts
- C# and VB.NET
- Java and Kotlin
- JavaScript and TypeScript
- PHP
- Python
- Ruby
- Go
- C and C++
- Rust
- Scala and Groovy
- Lua
- PowerShell and shell scripts
- HTML and server-side templates
- SQL and migrations
- OpenAPI and GraphQL
- XML, YAML and JSON
- Docker and Kubernetes
- Terraform and CI/CD pipelines
What “support” covers
- Source-code and pull-request analysis
- Dependency and software-composition analysis
- Web-server and framework configuration
- API specification and route analysis
- Build artefacts, containers and SBOMs
- Infrastructure-as-code and delivery pipelines
- Authorised, bounded and non-destructive API or DAST evidence
Current guidance is retrieved; findings still need authority
Signed, versioned public-security knowledge packs enter the isolated environment through the governed offline update path. Reviewer retrieves the relevant records when explaining a scanner result or candidate weakness, and cites the source and pack version used.
Top 10 classification, ASVS requirements, Web Security Testing Guide cases, Code Review Guide and defensive cheat sheets.
A stable taxonomy for the software weakness, its relationships and remediation context.
Public vulnerability identity, affected-product metadata and severity context.
Package-aware advisories and affected version ranges across open-source ecosystems.
A strong prioritisation signal when a vulnerability is known to be exploited in the wild.
Exploit-likelihood context; a probability signal, never proof that exploitation occurred.
Product-specific fixes and mitigations from the relevant server, framework and package publisher.
Normalised SAST, SCA, secret, IaC, container and API findings, preferably with SARIF or another declared format.
Retrieval comes before training. Optional LoRA adapters may learn stable security-review behaviour from evaluated, appropriately licensed public material. An advisory can therefore become usable with the next knowledge pack without a new training cycle. Customer repositories, diffs and secrets are not training data by default, and model output alone never confirms a vulnerability.
How effectiveness must be demonstrated
- Recall on known vulnerable applications
- False-positive rate by language and framework
- File-and-line localisation accuracy
- Dependency version and reachability accuracy
- Reproducibility of confirmed findings
- Time saved in triage and remediation
- Percentage of model candidates confirmed by a scanner, test or person
- Explicit gaps for generated code, missing build metadata and binary-only inputs
From authorised scope to a reproducible finding
Scanners supply authoritative signals, offline security intelligence supplies current context, and the local model explains intent and ranks risk. Only a scanner, a reproducible test, or a person can confirm a vulnerability.
Read the accessible text walkthrough
1 · Establish authorised scope
2 · Authoritative scanners run in parallel
3 · Normalise and correlate
Signed offline knowledge packs
4 · Local model assists judgement
5 · Authority gate
6 · Remediate, rescan and record
The mechanism, not the marketing. If a step below would not survive an engineer's scrutiny, it should not be on this page.
Operating path
From signal to auditable evidence
01Observed inputs
- Approved repositories and pull requests
- Dependency manifests, API specifications, IaC and deployment configuration
- SAST, SCA, secret-scanning, IaC, container and API-scanner output
02Deterministic workflow
- 1 Scanners run first, and stay authoritative SAST, software composition analysis, secret scanning, IaC and container scanning all execute on the appliance. Their output — not the model's opinion — is what makes a finding a finding.
- 2 The vulnerability corpus arrives on removable media CVE and NVD records, the CWE taxonomy, OSV, vendor advisories and known-exploited and exploit-likelihood data are imported as signed offline knowledge packs, verified before install and versioned like every other pack. Public data, no customer content, and no internet path into your network.
- 3 Retrieval before training, always The model retrieves from that corpus at query time, so an advisory published last month is usable after the next bundle without retraining anything — and every claim cites the advisory and the pack version it came from. This is why RAG sits above LoRA in the tuning hierarchy: currency without a training cycle.
- 4 Adapters carry stable behaviour, never your code Where evaluation justifies it, a LoRA adapter trains stable domain behaviour — security-review style, language-specific vulnerability patterns — on the public corpus. Your repository is not training data, by default and by design. The corpus is public; your code is not.
- 5 Reachability, not merely presence A vulnerable dependency nothing calls ranks differently from one sitting on a request path. Exploitability, reachability, asset exposure, data sensitivity and compensating controls fold into one ranking, so the list is short enough for a developer to act on.
- 6 Intent analysis on the diff The change is reviewed against what it claims to do: undocumented privileged paths, debug functionality, suspicious dependency additions, and changes to authentication, authorization, cryptography, input handling and logging.
- 7 Any active testing is scoped in writing first Declared scope, credentials, rate limits, allowed techniques, time window, full audit trail. Non-destructive only. No exploitation, no persistence, no production scanning outside the window.
03Evidence outputs
- Findings with file and line evidence, provenance, and reviewer disposition
- Correlation between scanner output and the explanation given
- Full audit trail for any authorised, scoped application test
The pull request titled “chore: bump lodash”
Two findings in one diff, produced by two different kinds of authority.
Neither your source code nor the diff left the network at any point. The advisory data that made the first finding possible arrived on a USB stick last month, signed, and was verified before it was installed.
The authority ladder. Green rungs are authoritative — a rule, a scanner, a sandbox, or a person. Blue is where the model contributes. Amber is where a human decides.
What the model adds
Intent analysis — the suspicious dependency addition, the undocumented privileged path, the debug functionality that should not have shipped, the change that does not match its own commit message.
What it cannot claim
It is not the source of truth for a vulnerability, and its prioritisation is a recommendation rather than a risk decision.
- Never exploits, never persists, never denial-of-service tests, and never scans outside an explicitly declared authorised scope.
- Never treats its own assertion as a confirmed vulnerability — a scanner, a reproduction, or a person confirms it.
- Never accesses repositories unrelated to the request.
- Never runs a controlled DAST or API test without declared credentials, rate limits, allowed techniques, a time window and a complete audit trail.
- Findings with file and line evidence, provenance, and reviewer disposition
- Correlation between scanner output and the explanation given
- Full audit trail for any authorised, scoped application test
A specification, not a simulation
We will not show you a scripted demonstration of something that does not exist. What we publish instead is the workflow specification, held to the same standard as shipped work: actor, trigger, happy path, exceptions, terminal state, and the audit evidence it must leave. When it is built, this section becomes a demonstration.
Status and what promotion requires
Roadmap discovery. Promotion requires a named Git host and scanner formats, plus reproducibility and false-positive-rate targets.