Detonation Chamber

Created by team Builders Nepal on November 04, 2026

Most supply-chain and phishing scanners read code or check reputation lists. Detonation Chamber takes a behavioural approach: it runs the artifact under containment, plants fake credentials to bait it, and reports what it actually did. How it works. You submit an npm or PyPI package, a GitHub repo, or a URL. The app downloads it on the host without running it there. It then runs it inside a one-off Docker container that is deleted afterwards. That container uses gVisor, has no network access (--network none), a read-only filesystem, all Linux capabilities removed, and caps on processes, memory and CPU. Inside, the app plants decoy credentials (AWS keys, SSH key, .env, git credentials, wallet file) and traces the artifact with strace. Every file read, process launch and network connection becomes a typed event. If the artifact reads a decoy credential or tries to connect out, the event is marked critical and shown in red. The connection fails anyway, because there is no network route out. The verdict is based on evidence. A deterministic scorer computes the risk score, and every point of it comes from an observed event. An agent running on Vultr Serverless Inference writes the analysis plan and a plain-English summary, but it can never overturn the score. Each run can be exported as JSON with a SHA-256 hash over the evidence, so anyone can check that the record wasn't changed. What it contains: secret theft, data exfiltration, phishing pages (credential forms posting to another site are flagged and never submitted), destructive commands, fork bombs, privilege escalation, SSRF and cloud-metadata theft (169.254.169.254 is blocked on every redirect), and prompt injection (fetched content is treated as plain data, never as instructions).

Category tags: