Deton
Product boundaries, proof semantics, and current availability for Deton.
Deton is an application-security system under development for AppSec and engineering teams reviewing changed JavaScript and TypeScript code. Its current pure evaluator separates a candidate from a supplied oracle-result record accepted by configured gates. Acceptance does not establish live execution, record authenticity, independent custody, persistence, delivery, or canonical publication.
Current availability
Deployment status, verified 2026-09-26: Production includes the configured GitHub App, exact-revision archive transport, signed R2 staging, and the isolated Cloudflare sandbox runner. Missing configuration, unsupported recipes, stale PR heads, runner failures, and delivery failures stop visibly; they never become confirmed findings.
Start with the current quickstart. The public walkthrough is synthetic; repository runs begin only after an authorized GitHub App installation and a pull-request event.
The public preview can show a supplied oracle-result record and formatter output. That record does not authenticate its origin or execution. Formatter eligibility can prepare a payload for attempted GitHub delivery; it does not show delivery or publication success.
The source tree contains an offline proof path against a controlled target. That
is test evidence, not evidence that customer repositories can be scanned in the
running service. The bundled target is a zero-dependency Node ESM application
using node:http and an in-memory synthetic store; it is not an Express,
Postgres, or TypeScript application. See
tests/fixtures/deton-vulnerable-target/README.md and
sandbox/deton-sandbox-runner/src/recipes.mjs.
Candidate → proof → verdict
- Candidate.
src/core/deton/candidate-finder.tsparses added lines in a unified diff and records a source, sink, changed range, rule, confidence, and missing context when a detector matches. A candidate is a hypothesis, not a vulnerability. - Proof plan.
src/core/deton/proof-planner.tsderives a bounded plan only for a proof-enabled family. The plan fixes the oracle, marker, prospective replay/sample limits, forbidden observations, egress policy, and safety ceiling. - Observation. For an eligible candidate, the isolated runner boots an authorized exact-revision source using a supported recipe and returns an oracle-result record. The runner cannot decide the verdict or invent an observation.
- Verdict.
src/core/deton/verdict-engine.tsis the only domain function that can emitconfirmed. It requires a matching record whosedeterministicfield is a schema enum value, respected safety and redaction gates, and a complete actionability checklist. - Publication object.
src/core/deton/security-issue-builder.tscan build an in-memory security-issue value only when the verdict is confirmed, publishable, and linked to the matching candidate, proof plan, and oracle result. The current production path does not persist that value as an evidence artifact. Builder eligibility does not establish GitHub delivery or canonical publication.
Only SQL injection and command injection are proof-enabled and publishable in
src/core/contracts/deton-attack-family-registry.ts. Other registered families
are contract-modelled, candidate-only, informational, deferred, or excluded.
These are registry labels, not execution or delivery evidence. Registration is
not coverage.
Detection boundary
The current diff candidate finder examines added lines in .ts, .tsx, .js,
.jsx, .mjs, and .cjs files. It skips deleted files, binary files, and
*.test.* / *.spec.* files. Its active line detectors recognize selected SQL
injection and command-injection source-to-sink shapes plus an internal
open-redirect canary. They are bounded heuristics, not a whole-program parser.
An unrecognized pattern produces no candidate; it does not establish safety.
Read next
- Quickstart — the path that works on this deployment.
- Core concepts — candidate, finding, proof, and verdict states.
- GitHub access — exact requested permissions and the current provisioning boundary.
- Service-control evidence — implementation references and claims those controls do not establish.