Deployment hygiene
Published
You protect a bundle, ship it, and a customer’s antivirus or corporate EDR quarantines it as “suspicious.” Nothing is wrong with your code — the scanner is matching on shape, not intent. Real malware has leaned on obfuscation for years to hide its payloads, so heuristic engines learned to treat the techniques as a signal. Legitimate protection and malware use some of the same moves, so the same alarm can fire on both. The good news: the specific shapes that draw the most heat are avoidable, and a few deployment habits make protected code sail through.
Why the alarm fires
Antivirus and EDR products score files with heuristics — statistical and pattern rules, not proof of malice. The patterns that overlap between obfuscation and malware:
eval / new Function on a decoded string. The classic “unpack a blob and execute it” loader is the single strongest malware tell. Old eval-based packers do exactly this — and so does a lot of malware.- Long, high-entropy string arrays and hex/base64 blobs. Big walls of encoded data look like a hidden payload to an entropy heuristic, whether it’s a decryptor table or a smuggled executable.
- Heavy control-flow flattening and dead code. Deliberately confusing structure is what sandbox-evasion malware also does to dodge analysis.
- Inline scripts inside HTML. Obfuscated JavaScript embedded directly in a page is a common drive-by-download shape, so inline blobs get extra scrutiny versus external files.
- Known-signature collisions. Occasionally a byte sequence in your output coincidentally matches a signature for a specific known-bad sample.
None of these prove anything — that’s why it’s a false positive — but the scanner errs toward blocking.
How to ship protected code that doesn’t get quarantined
- Avoid
eval and new Function. This is the biggest single win. Modern obfuscation — string-array decoding, control-flow flattening, VM bytecode — is ordinary code that runs without runtime code-generation. That’s also why it’s compatible with strict CSP. If your tool’s output contains a decrypt-then-eval loader, that’s the first thing to drop.
- Serve as external
.js files, not inline. External bundles delivered over HTTPS with correct Content-Type are treated far more calmly than obfuscated blobs pasted inline in HTML. It also keeps your CSP strict.
- Don’t over-protect. Maxing every transform on the whole bundle raises entropy and structural weirdness — exactly the heuristic triggers — while also hurting performance. Target strong protection at the sensitive functions and keep the rest light. Less blanket obfuscation means fewer alarms.
- Sign and version your builds. For desktop/Electron or extension contexts, code-signing certificates and a consistent publisher reputation dramatically reduce false positives — reputation systems trust signed, established publishers. Build provenance and signed attestations help here too.
- Keep behavior transparent where it’s reviewed. Don’t obfuscate in ways that hide what the code does from a reviewer who’s allowed to see it — that’s the exact thing store review and EDR are trying to catch. Protect proprietary logic, not the fact that your app makes network calls.
If it still gets flagged
False positives happen even to clean, signed builds. When one does: capture which engine flagged it and the detection name, scan the file on a multi-engine service to see if it’s one vendor or many, and submit a false-positive report to that vendor — every major AV company has a form, and legitimate signed software is usually cleared quickly. If a single engine is an outlier, it’s almost always a heuristic misfire rather than a real signature. Keep a record of your build provenance so you can show the file is yours.
The short version
Obfuscated JavaScript gets flagged because malware pioneered the same techniques, so scanners react to the shape. The fix is to avoid the shapes that scream “malware” — no eval-based loaders, no giant inline blobs, no blanket max-everything — serve external signed files, and report the occasional false positive. Do that and strong protection and clean AV scans stop being a trade-off.
Frequently asked questions
Why does protected JavaScript set off security scanners?
Because it resembles what scanners were trained to catch. Malicious script is very often obfuscated, so heuristics learned to treat dense generated names, packed strings, dynamic code reconstruction and unusual control flow as signals. Your build produces those same surface features for entirely legitimate reasons. The detector is not identifying malice; it is identifying a shape, and your output shares the shape. Understanding that is what makes the problem tractable, because it points at which settings to change.
Which settings are most likely to trip a scanner?
The ones that involve reconstructing code at run time. A self-extracting wrapper that rebuilds a program from a packed string is the single strongest trigger, because building and executing code from data is close to a definition of what heuristics look for. The eval-based transposition variant sits in the same category. String encoding and heavy control-flow restructuring contribute, while name mangling on its own rarely causes trouble.
How do we reduce the chance of being quarantined?
Start from the lightest configuration that meets your actual requirement rather than the strongest available. Avoid the options that reconstruct code from strings unless you specifically need them, since they are both the biggest trigger and the ones with a content-policy requirement anyway. Serve files over a properly configured connection with correct content types, keep filenames and paths conventional, and avoid patterns that look like evasion, such as pointless indirection around network calls.
What do we do when one specific vendor flags us?
Submit it, because the false-positive reporting path is the mechanism that actually resolves this. Every major vendor operates one, submissions from a software publisher are usually processed quickly, and a resolved submission fixes the problem for every customer of that product rather than only for the one who reported it. Keep the sample, the detection name and the build that produced it, since that is what a submission asks for. In the meantime, a lighter configuration for that release is a reasonable stopgap.
Does signing our code help?
It helps with reputation-based systems rather than with content heuristics. A consistently signed artifact from a publisher with history accumulates trust, which reduces the chance that a new release is treated as unknown and therefore suspicious. It does not change what a content scanner sees inside the file. For distributed desktop or packaged applications signing is worth doing for several reasons and this is one of them; for a script served from a web page it is largely beside the point.
Is a detection ever a sign of something genuinely wrong?
Occasionally, and it deserves five minutes before being dismissed. If a detection appears on a release where nothing about your protection configuration changed, the more likely explanation is a change in what went into the bundle rather than in how it was transformed, and a compromised or typosquatted dependency is exactly the kind of change that produces one. Confirm the input before assuming the transform. That check is cheap and the failure mode it catches is expensive.
Related reading