Deton Docs

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

  1. Candidate. src/core/deton/candidate-finder.ts parses 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.
  2. Proof plan. src/core/deton/proof-planner.ts derives 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.
  3. 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.
  4. Verdict. src/core/deton/verdict-engine.ts is the only domain function that can emit confirmed. It requires a matching record whose deterministic field is a schema enum value, respected safety and redaction gates, and a complete actionability checklist.
  5. Publication object. src/core/deton/security-issue-builder.ts can 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.

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

On this page