Detection · live

Backdoor scanner

The backdoor scanner audits the resources actually running on your server. It runs off-path on a schedule, so it never blocks gameplay; findings land in the dashboard for operator review.

What it protects against

The realistic threat is a malicious resource: dropped via a compromised dependency, included as a copy of a paid resource from a leak, or shipped by a member of the team who shouldn't have commit access. The scanner doesn't try to perfectly classify every resource as good or bad — it surfaces ones that look statistically off, and lets the operator decide.

Modes

The scanner is alert-only today: it never disables or removes a resource. Verdicts land in the dashboard and (if configured) post to a Discord webhook. The mode column therefore describes how strongly an alert is surfaced, not what gets executed.

Mode	Behavior
`observe`	Findings are written to the audit log and the dashboard's Resource hygiene tab. No notifications.
`score`	Same as observe, plus a Discord-webhook notification if a webhook is configured. Useful for operators who want to be paged on findings.
`enforce`	Reserved. The scanner does not yet take automatic action against a resource — that will require explicit opt-in and a review queue.

Verdicts

Verdict	What it means
`cleared`	Resource passed the scan. Either it's on the curated framework whitelist, or its content didn't match anything suspicious.
`high_risk`	The scan surfaced a combination of signals strong enough to warrant operator review. Action stays manual — we don't auto-disable resources.
`whitelisted`	Operator (or hoaxeye) marked this resource trusted. Whitelist entries are visible in the audit log with the reason.

Cadence & scope

03:00 – 05:00 UTC

Scan window

Daily slot inside which a server's scan can fire. Picked to land outside peak hours for the EU/NA player base.

3 days

Per-server cooldown

A server is not re-scanned until ~72 hours have passed since its last completed scan, so we don't pile up redundant work.

started resources

Scope

Only resources currently in a started state at scan time. Stopped resources are skipped — they can't backdoor anything that isn't running.

0 findings on n=59

Recent clean run

Smoke run on a representative test pilot server (59 started resources). Zero findings — the expected outcome for clean servers under the current whitelist-first design.

False-positive history

The first iteration matched plain Lua patterns: things like raw HTTP fetches, dynamic command registration, or runtime config writes. On a modern framework server (ESX, QBCore and friends), those patterns hit framework internals dozens of times — the scanner produced essentially 100% false positives on clean servers.

The current iteration flips the approach. We maintain a curated whitelist of known-clean framework resources and addons, plus URL allowlists for the common HTTP destinations frameworks legitimately call. Pattern checks only run on resources outside the whitelist, and even then they require multiple corroborating signals before we surface a finding. The clean-run number above is from a real test pilot, not a synthetic benchmark.

If a custom resource you ship is repeatedly flagged, the right answer is to whitelist it explicitly via the dashboard — not to disable the scanner. Whitelist entries are audited; they don't go missing on you.

Operator recommendation

All server types: leave the scanner running on the default cadence. Subscribe its Discord webhook to a private operator channel — not a public channel — so findings are visible to the team without leaking which signals fired.
Custom-resource-heavy stacks: on the first run, expect to whitelist a handful of internal resources. Use the audit-log entries as your changelog — they tell future you why a given resource was trusted.
See Server setup for the whitelist workflow in the dashboard.