Skip to main content

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:

  1. Package analyzer — reads package.json metadata (publisher, repository, declared activation events, contributed commands).
  2. Code analyzer — scans extension JavaScript for known suspicious patterns.
  3. Dependency analyzer — collects declared dependencies and their versions.
  4. npm reputation — looks up download counts, publisher age, and ownership history for npm-published authors.
  5. OSV vulnerabilities — queries OSV.dev for known advisories on each dependency (when enabled).
  6. Risk aggregation — combines signals into a numeric score and a level bucket.
  7. Recommendation generator — selects a short human-readable message based on the dominant signals.
  8. 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:

LevelMeaning
LowNo notable signals
ModerateOne notable signal or weak combined evidence
HighMultiple signals or one known vulnerability
CriticalStrong 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