Atomdrift Scan for zero-day malware detection in software supply chains

Atomdrift Scan is an ML-based malware scanner that detects 0-day threats in binaries, source code, and scripts for defenders triaging supply-chain risk in authorized environments.

Tool	atomdrift-project/scan — ML-based 0-day malware scanner for binaries, source, scripts, archives, packages, and processes
Category	Defensive malware scanning and static analysis, written in Rust
Primary Use	Triaging files, archives, package URLs (purl), and URLs for 0-day supply-chain malware in CI pipelines and incident response workflows
Telemetry Note	Intended for authorized defensive work: security teams scanning their own codebases, incident responders triaging suspected artifacts, and researchers analyzing samples in controlled lab environments
Telemetry Note	The tool sends no telemetry; it contacts the Internet only for 24h rule updates (disable via --no-update or SCAN_NO_UPDATE_CHECK=1) and optional reference-following (--follow=none to disable). Optional --llm interpretation sends evidence, not files, to a configured endpoint
Safe Use	Explicitly a defensive scanner for authorized security assessment, CI/CD hygiene, and malware research in controlled environments

Atomdrift Scan, hosted at atomdrift-project/scan and written in Rust under an Apache-2.0 license, positions itself as a machine-learning-driven answer to the problem that plagues signature-based scanners: novel, 0-day malware embedded in the software supply chain. Rather than matching hashes against yesterday's threats, it converts every artifact — binary, source file, script, archive, or package — into a standardized feature vector and lets an ensemble of LightGBM models score it. The project claims a 98% 0-day detection rate as of September 2026, which is a marketing claim you should verify against your own corpus, but the architecture described in the README is genuinely more sophisticated than most open-source scanners.

The internal pipeline is the most interesting part of the design. Stage one uses stng, a sibling project, to extract content even when obfuscated. Stage two, cleave, unpacks containers and extracts capabilities from the artifact. The resulting report is normalized into a feature vector that is standardized across file types, meaning an ELF binary and a Python script end up comparable in the same feature space. Finally, azoth — the project's model weights, thresholds, and feature specification repository — applies LightGBM ensemble scoring to produce a verdict. This separation of extraction, capability analysis, and scoring into independently versioned components is a thoughtful engineering choice that makes each stage auditable.

Coverage is where the tool differentiates itself from simple YARA-style scanners. The README enumerates over 100 supported formats: binaries and bytecode including Mach-O, ELF, PE, WebAssembly, Android DEX, Java .class, and Python .pyc; source in more than two dozen languages from C to Zig; build and lock files such as package-lock.json, Cargo.lock, and pyproject.toml; and a long tail of packages, containers, and documents including OCI images, DMG, IPA, CRX, and even Python pickle files. The rule set reportedly spans 125,000+ rules and 15 million+ known-good and known-bad hashes, with platform-specific behaviors covering everything from AIX and z/OS to ESXi, FortiOS, and Junos appliance firmware.

Deeper static analysis is delegated to well-regarded external tooling. The README recommends installing 7-Zip, rizin for automated binary reverse engineering, upx for unpacking compressed executables, and innoextract for Windows installer teardown. A subtle operational note worth heeding: on Unix-like systems the authors recommend the upstream 7z rather than p7zip, because p7zip cannot read APFS, leaving .dmg contents silently unscanned. Details like that signal a team that actually tests its edge cases. Source-level analysis is integrated via tree-sitter AST parsing rather than naive regex matching, which is the right call for polyglot detection.

The CLI surface, exposed through the atomscan command, is deliberately simple. You can scan a file, directory, or archive recursively, fetch a package directly from its registry by PURL (atomscan purl npm/left-pad@1.3.0), pull and scan a URL, or — experimentally — scan running process executables with atomscan ps or triage the whole host with atomscan sys. JSON output via -f json makes programmatic consumption trivial, and the exit code scheme is thoughtfully designed for CI: 0 benign, 1 hostile, 2 suspicious, 3 analysis error, and — notably — 4 when the rule set was incomplete, meaning the scan ran with fewer rules than the trait set defines and the result proves nothing. That exit code alone shows unusual honesty about scanner limitations.

The false-positive tuning model deserves specific attention because it inverts the usual configuration problem. Instead of asking users to guess at raw score thresholds, the -l flag lets you specify an acceptable false-positive rate: -l0 is tight, with no observed false positives; -l25, the default, targets 25 false positives per 100 million files; -l1000 allows roughly one per 100,000. The README candidly warns that for formats without 100 million samples, the observed rate may be 5-6X the requested level. Raw --threshold-hostile and --threshold-suspicious overrides exist for micromanagers but cannot be combined with -l, and the values are not guaranteed stable across releases.

An optional LLM interpretation layer is one of the more unusual features. The --llm flag sends interpreted evidence — not the original file — to an OpenAI-compatible endpoint, by default http://localhost:8000/v1 for local services like Ollama or vLLM. The LLM provides a natural-language readout of findings and can steer edge cases, improving results by up to 33% per the README. No model is hardcoded: without --llm-model, the tool queries the endpoint for its model list and picks the largest, with Qwen/Qwen3.8-27B recommended. Failover chains are supported, so a local model can handle most requests and fall back to a billed API only when it cannot answer. Bearer tokens are read from ~/.tok/llm with mode 0600, which is correct key hygiene.

Networking behavior is explicitly documented, which matters for defenders running this in sensitive environments. The tool sends no telemetry whatsoever. It contacts the Internet for exactly two purposes: rule refreshes every 24 hours (disableable with --no-update or SCAN_NO_UPDATE_CHECK=1) and following discovered references — checking whether a benign package depends on or downloads a compromised payload — which can be constrained with --follow=none. Rules are reportedly refreshed daily, roughly 1000 updates per day, using reinforcement learning against new samples, blogs, and technical articles. That cadence is what keeps a rule-based system from going stale, though it also means the tool phones home to a vendor-controlled update channel, so verify the update transport fits your policy.

For deployment beyond a single workstation, the project documents a long-running HTTP server mode (docs/SERVER_API.md), distributed scanning via a work queue called hopper (docs/WORKERS.md), a JSON report schema (docs/JSON.md), and an integration guide covering CLI, server, and worker topologies. A Linux make deploy target installs a systemd unit with ProtectHome=true, which is a good hardening default, with a documented workaround for copying OpenRouter tokens into the service state directory. The default build matrix spans Linux, macOS, the BSDs, illumos, Solaris, and Windows across multiple architectures.

In an authorized workflow, the obvious fit is CI/CD gatekeeping: scanning release artifacts, dependency tarballs, and container images before promotion, with the exit-code contract driving pipeline decisions. Incident responders triaging a suspected supply-chain compromise will appreciate the breadth of container and package formats that get transparently unpacked, and the free Atomdrift Lab service offers a no-install path for one-off sample analysis. Things to watch: the detection-rate claims are vendor benchmarks and should be independently validated; the 51-star count means the project is young and the community small; and the daily rule-update channel creates a soft dependency on the vendor's infrastructure that air-gapped environments need to plan around.

As a defensive tool, atomscan leaves a clean footprint: no telemetry, documented and disableable network behavior, and deterministic local analysis. For blue teams, that also means its use is observable and controllable — egress to the rule-update endpoint and any configured --llm endpoint is the entirety of its network footprint, easily captured in proxy logs for organizations that want to audit what their scanners are doing. The combination of tree-sitter AST analysis, rizin-driven binary teardown, and ML scoring makes this one of the more credible recent entries in open-source supply-chain defense, and worth a look for any team building intake pipelines for third-party code.

Official project repository for atomdrift-project/scan.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.