Current availability
Verified source, runtime, vulnerability-family, and delivery boundaries for Deton.
Verified 2026-09-26. This page distinguishes checked-in contracts and controlled fixtures from capabilities available on the running deployment. It is not a promise of future delivery.
Production availability update. Production has a configured GitHub App, exact-revision source transport, signed R2 staging, and an isolated Cloudflare sandbox worker. Configuration, source, recipe, stale-head, runner, and delivery failures remain visible failures; they never become confirmed findings.
What is available now
The public site presents Deton's proof model and a synthetic product demonstration. An authenticated organization can install the configured GitHub App for repositories it authorizes. Pull-request events can create idempotent runs that fetch the exact PR head and diff, stage a hash-bound archive in signed storage, and submit supported recipes to the isolated runner.
The source tree contains:
- a universal attack-family registry with explicit publication states;
- candidate, proof-plan, oracle-result, verdict, and security-issue contracts;
- bounded detectors for selected changed-line source-to-sink shapes;
- first-pack proof contracts for SQL injection and OS command injection;
- a zero-dependency Node ESM fixture with synthetic, in-memory data;
- a sandbox runner that accepts a short-lived source reference only from the
configured archive host or a canonical Cloudflare R2 account host, checks the
archive hash and size, extracts it defensively, and resolves
deton.json.
The deployed components and configuration were verified during this release. No live customer-repository scan was performed as part of that verification, so this page does not claim a captured customer result or broad rollout evidence.
The public walkthrough still uses synthetic data. A stored or illustrative record is not proof that a new scan executed. Formatter eligibility alone also does not establish delivery or publication success.
Operational boundaries
The configured path fails closed. In particular:
- a missing GitHub, storage, or runner setting exposes execution as unavailable;
- an unsupported or invalid
deton.jsonrecipe stops before proof evaluation; - a changed PR head stops stale analysis before execution or publication;
- archive, runner, and GitHub delivery failures remain failed runs;
- the current Vercel deployment uses the synchronous local job provider, so a long request has less durability than the supported remote-worker path;
- the checked-in GitHub App manifest is private, so installation availability is limited by the App's GitHub visibility settings;
- the public demo is synthetic and must not be presented as a captured customer result.
Creating an account alone does not install the GitHub App, authorize a repository, or start a security scan.
Source boundary
The Next.js control plane fetches an authorized exact-commit archive and stores immutable bytes in S3-compatible storage. It sends the runner a short-lived reference bound to the archive SHA-256, not a GitHub credential. The runner restricts the download host, verifies the compressed-size limit and hash, and extracts the archive defensively before recipe resolution.
The Next.js control plane must not execute untrusted customer code. A runner must not receive GitHub installation tokens, billing secrets, production database credentials, or cloud instance-profile access.
Vulnerability-family status
| Status | Meaning | Current examples |
|---|---|---|
| Proof-enabled and first-pack publishable | The registry permits an illustrative contract whose deterministic field is a schema enum value to reach formatter eligibility. Confirmation still requires every safety, redaction, identity, sample, and actionability check. | SQL injection; OS command injection |
| Internal canary or informational | Used to exercise a bounded pipeline behavior, not marketed as a public proof pack. | Open redirect canary |
| Modelled or candidate-only | The family may have registry or candidate semantics but is not eligible for a confirmed finding without its own approved proof contract. | Selected path traversal, XSS, JWT, and authorization families |
| Deferred or excluded | The MVP does not provide a publishable proof path. | Cloud/CI, supply-chain, business/payment logic, and other registry-defined deferred families |
Registration is not coverage. The registry models a broad vulnerability universe while publication remains intentionally narrow.
Detection boundary
The current candidate finder examines added lines in .ts, .tsx, .js,
.jsx, .mjs, and .cjs files. It skips deleted files, binary files, and test
or specification files. Its active detectors recognize selected source-to-sink
shapes; they are not a whole-program parser or a completeness guarantee.
No candidate means only that the enabled heuristics did not raise one in the analyzed diff. It does not mean “no vulnerabilities.”
Evaluator and builder eligibility boundary
A candidate is not a finding. The pure evaluator may accept a supplied record
as confirmed, and the builder may construct an in-memory security-issue value,
only when:
- a supported, proof-enabled family;
- a matching bounded proof plan;
- a supplied oracle-result record tied to the candidate and plan;
- the exact marker, the
deterministicschema enum value, and the required sample count; - no forbidden observation;
- accepted noise, safety, and redaction gates;
- complete reproduction, impact, remediation, bad-fix, and prospective retest instructions;
- a registry state that permits in-memory issue construction.
This is evaluator and builder eligibility only. It does not establish live execution, record authenticity, independent custody, persisted evidence, GitHub delivery, or canonical publication.
Unsupported, inconclusive, out-of-scope, stale, error, and empty outcomes are not confirmed vulnerabilities and are not evidence of safety.
Evidence locations
The configured execution boundary can be inspected in:
src/libs/deton/execution-availability.ts;src/jobs/deton-scan-dispatch.ts;src/libs/deton/runner/cloudflare-sandbox-runner.ts.
The following remain implementation, fixture, or planning evidence rather than evidence of a successful customer run:
docs/operations/ACTIVATE-DETON-ENGINE.md;docs/product/deton-mvp/05-sandbox-runner-contract.md;docs/product/deton-mvp/14-core-universal-vulnerability-engine.md;src/core/contracts/deton-attack-family-registry.ts;src/core/deton/verdict-engine.ts;src/libs/deton/runner/types.ts;sandbox/deton-sandbox-runner/src/recipes.mjs;tests/fixtures/deton-vulnerable-target/README.md.
Read Interpret results before translating a Deton state into a merge, remediation, or review decision.
Freshness and corrections
This page must be rechecked whenever source transport, runner deployment, proof-family publication state, or GitHub delivery changes. A checked-in feature must not be relabeled “available” until its running deployment behavior has been verified.