GuardDog 3.2.0 can return different risk scores for identical JavaScript solely because of its location.
These rules contain hardcoded directory exclusions:
threat-runtime-obfuscation-dynamic-evalthreat-runtime-obfuscation-js-mangling
path_exclude = "dist/*,build/*,vendor/*,node_modules/*"
The original implementation in PR #713 introduced a broader exclusion list:
path_exclude = "*.min.js,*.bundle.js,dist/*,build/*,vendor/*,node_modules/*"
The reproduction below concerns the directory exclusions still present in 3.2.0.
Reproduction
Scan a directory containing a single JavaScript file with this harmless suspicious-pattern fixture:
eval(String.fromCharCode(118,111,105,100,32,48));
The encoded string is void 0. The file only needs to be scanned, not executed.
Using native guarddog npm scan <directory> --output-format=json --sandbox, identical contents produce:
| Relative filename |
Risk score |
plain.js |
8.2 |
dist/plain.js |
0 |
main.js |
8.2 |
build/main.js |
0 |
vendor/anything.js |
0 |
node_modules/plain.js |
0 |
The dynamic-eval threat match disappears under the excluded directories. A capability match remains, but the resulting risk score is zero.
Impact
An attacker controls filenames and directories and can place executable payloads in locations that suppress these detections.
This does not bypass every GuardDog rule: payloads matching additional, unaffected rules may still be detected.
Request
Could GuardDog provide a supported way to disable or override rule-level path_exclude filters?
We understand that these exclusions reduce false positives. However, security-review workflows need an option to inspect these files regardless of attacker-controlled names, while preserving their original paths in results.
GuardDog 3.2.0 can return different risk scores for identical JavaScript solely because of its location.
These rules contain hardcoded directory exclusions:
threat-runtime-obfuscation-dynamic-evalthreat-runtime-obfuscation-js-manglingThe original implementation in PR #713 introduced a broader exclusion list:
The reproduction below concerns the directory exclusions still present in 3.2.0.
Reproduction
Scan a directory containing a single JavaScript file with this harmless suspicious-pattern fixture:
The encoded string is
void 0. The file only needs to be scanned, not executed.Using native
guarddog npm scan <directory> --output-format=json --sandbox, identical contents produce:plain.jsdist/plain.jsmain.jsbuild/main.jsvendor/anything.jsnode_modules/plain.jsThe dynamic-eval threat match disappears under the excluded directories. A capability match remains, but the resulting risk score is zero.
Impact
An attacker controls filenames and directories and can place executable payloads in locations that suppress these detections.
This does not bypass every GuardDog rule: payloads matching additional, unaffected rules may still be detected.
Request
Could GuardDog provide a supported way to disable or override rule-level
path_excludefilters?We understand that these exclusions reduce false positives. However, security-review workflows need an option to inspect these files regardless of attacker-controlled names, while preserving their original paths in results.