Scanning engine
How ShieldX turns "list of installed extensions" into a risk-scored report. Read this before tuning thresholds or filing a "false positive" issue.
Pipeline order
For every installed extension, ShieldX runs the analyzers in this order:
- Package analyzer — reads
package.jsonmetadata (publisher, repository, declared activation events, contributed commands). - Code analyzer — scans extension JavaScript for known suspicious patterns.
- Dependency analyzer — collects declared dependencies and their versions.
- npm reputation — looks up download counts, publisher age, and ownership history for npm-published authors.
- OSV vulnerabilities — queries OSV.dev for known advisories on each dependency (when enabled).
- Risk aggregation — combines signals into a numeric score and a level bucket.
- Recommendation generator — selects a short human-readable message based on the dominant signals.
- Diff vs. previous scan — labels each extension as new, unchanged, upgraded, or downgraded.
Package analyzer
Looks for absent or suspicious metadata: missing repository URL, mismatched publisher and author, unusually broad activation events, requested commands that overlap with sensitive built-ins.
Code analyzer
Matches patterns from src/rules/suspicious-patterns.ts against bundled JS. Examples include dynamic eval of remote content, raw child_process spawns with user input, and obvious obfuscation markers. The analyzer does not execute extension code.
Dependency analyzer
Resolves declared dependencies and peerDependencies. With shieldx.scanNodeModules enabled, it also walks installed packages on disk.
npm reputation
For npm-published authors the scanner pulls:
- Lifetime download counts
- Recent (last 30 days) download counts
- Publisher creation date
- Ownership change events
Low counts and recently created accounts increase risk weight; they do not by themselves trigger a High level.
Verified Repositories & Publishers: To prevent spoofing where a malicious extension specifies a popular repository/npm package in its metadata, reputation lookups are restricted. ShieldX only queries external reputation endpoints if the extension is in a verified repository list or is published under a well-known publisher namespace (e.g., microsoft, github) where the repository owner matches the publisher.
OSV vulnerability lookup
When shieldx.enableOsvScan is true, each dependency is queried against OSV.dev. Matching advisories contribute weighted risk based on severity and whether a fixed version is available.
Risk aggregation
The aggregator sums weighted signals and maps the total to a level:
| Level | Meaning |
|---|---|
| Low | No notable signals |
| Moderate | One notable signal or weak combined evidence |
| High | Multiple signals or one known vulnerability |
| Critical | Strong combined evidence; manual review required |
Cutoffs live in the scanner module and may shift between versions. Do not hard-code them in external tooling — use the level string.
Diffing
Each completed scan is compared to the previous cached scan. Per extension, ShieldX records: added, removed, version-changed, risk-changed. The diff drives the What changed strip on the dashboard.
Limitations
- ShieldX cannot prove an extension is safe — only that visible signals are clean
- It cannot detect runtime payloads fetched after install
- It cannot inspect extensions that the editor refuses to enumerate (corrupt installs, partial uninstalls)
- npm signals are unavailable for extensions whose publisher is not on npm
- OSV coverage is limited to ecosystems OSV indexes