ablx-triage

A small, static, read-only helper for taking a first look at an Ableton Live extension before you trust it. It tries to answer one narrow question:

Does this extension reach the network, or load/execute code at runtime that wasn't shipped in the bundle?

That's it. It does not run the extension, and it is not a safety check — just an early triage signal. It's an experiment and a starting point, offered in the hope it's useful to others poking at extension safety; there's lots of room for better tooling around it.

Why that question

The Extensions SDK currently has no trust model: a .ablx is an unsigned zip whose activate() runs Node.js code when Live loads it, with broad Node APIs and no enforced sandbox. You also can't easily restrict it at runtime, since Live launches the Extension Host itself.

So a useful (if partial) thing to know up front is whether an extension can talk to the network or load code later:

• A local-only extension is fixed: what you read is what runs, and a new version means a manual re-install — another chance to look.
• A network-capable (or runtime-code-loading) extension is more of a moving target: it can fetch and run code later, so no single scan settles it.

This tool just makes that distinction quick to see. It doesn't replace reading the source.

Install / use

# no install:
npx ablx-triage path/to/extension.ablx

# or install globally:
npm i -g ablx-triage
ablx-triage path/to/extension.ablx

It also accepts an unpacked extension directory (containing manifest.json), a raw bundle, and a --json flag:

ablx-triage path/to/extension-dir/
ablx-triage path/to/dist/extension.js
ablx-triage path/to/extension.ablx --json

From a source checkout instead of npm: npm install then node bin/triage.mjs <path>.

Verifying this tool

It's published with npm provenance, so npm audit signatures (or the provenance note on npmjs.com) links the package to the public commit and CI build that produced it.

Verdicts (and exit codes)

| Verdict | Exit | Meaning | |---|---|---| | LOCAL-ONLY | 0 | No network or runtime code-loading detected in this scan. | | CHANNEL | 2 | Network and/or dynamic code execution detected. Means capable of, not malicious — look closer. | | UNSCANNABLE | 1 | Couldn't parse/unpack the input. Worth treating as unknown. |

The report splits the result into the axes that differ in risk:

VERDICT: CHANNEL / ELEVATED   (exit 2)
  Network:         no
  Runtime code:    YES
  Child process:   no

What it looks for

• Network: require/import of http(s), http2, net, tls, dgram, dns, inspector; global fetch / new WebSocket / EventSource; createServer / createConnection. Hardcoded URLs and IPs are reported as indicators (suggestive only — a docs URL in a string shouldn't flip the verdict).
• Dynamic code: eval, new Function, vm (runInNewContext / compileFunction / new vm.Script), process.binding/dlopen, module._compile, and computed require()/import() (which also surfaces obfuscation like require([...].join(""))).
• Child process: require("child_process").
• Informational only: fs use, suspicious path fragments (~, /Users, .ssh, …), and WebAssembly.instantiate/compile.

Detection is AST-based (acorn), which holds up against the esbuild minification used to build .ablx files: Node built-ins stay as literal require("net")-style calls even when minified.

A known rough edge

Running it on the SDK's own examples/strip-silence returns CHANNEL — Network: no, Runtime code: YES, because its bundled WASM audio-codec library uses vm.runInThisContext + computed require/import to load decoders. That's a genuine dynamic-code capability, but a benign one. So expect heavy legitimate dependencies to land in CHANNEL too — the network axis is usually the more telling one, and the result is a prompt to look, not a verdict on intent.

Limitations

• Not a safety guarantee. Static analysis can't prove safety. Deliberate obfuscation or a payload fetched/decoded at runtime can slip past it — though hiding an import tends to show up as a dynamic-require finding, which is itself worth noticing.
• CHANNEL means "capable of", not "malicious." Read the axes and the evidence, then read the code.
• No dependency list. A production .ablx flattens its npm tree into one bundle, so there's no CVE/supply-chain analysis here. Scan the source repo + lockfile when you have it.

Out of scope

Dependency/CVE scanning, dynamic/sandbox execution, OS-level egress blocking, and signature/authorship verification. This is intentionally one small piece; it pairs well with the obvious basics — preferring extensions from people you trust, favouring local-only ones, and restricting network access at the OS level when in doubt.

Contributing

Early days — rules, detections, and ideas are very welcome.

Tests run with npm test (no framework, just node test/run.mjs). They cover the verdict paths, the individual detection rules, the error/UNSCANNABLE branches, and the .ablx zip handling. They're enforced in two places: CI runs them on every push/PR (.github/workflows/test.yml), and npm publish won't proceed if they fail (prepublishOnly). To run them before every commit locally:

git config core.hooksPath .githooks

Coverage is decent but not exhaustive — there's no minified-bundle case in the automated suite yet (it's been checked by hand), and obfuscation cases are only lightly covered. Additions welcome.