Risk scoring

How ShieldX turns observations about an extension into a number and a level.

The four levels

Level cutoffs are an implementation detail and may shift between releases. Always compare extensions by level string, not by numeric score.

Signal categories

Trust signals (positive)

• Verified publisher
• Long publisher history
• High install count
• Public repository
• Signed releases

Risk factors (negative)

• Suspicious code patterns (eval of remote content, raw child_process with user input, obfuscation markers)
• Missing repository URL
• Mismatched publisher/author
• Unusually broad activation events
• Recently created npm publisher
• Known vulnerabilities in declared dependencies (OSV)

How signals combine

Each signal carries a weight. The aggregator sums weighted signals and maps the total to a level. Important rules:

• A trust signal does not cancel a risk factor — they are reported independently.
• A single Critical-severity rule match can push an extension to Critical on its own.
• Vulnerability severity scales with CVSS where available, and with whether a fix exists.

Why a popular extension can still register as High

Popularity is one signal in many. ShieldX deliberately does not down-weight risk factors just because an extension is widely installed — supply-chain compromises of popular packages are exactly the case ShieldX is designed to catch.

Tuning what you see

• shieldx.minimumWarningLevel — hides notifications below this level
• shieldx.warnOnHighRisk — disables modal warnings entirely
• maxRiskLevel in policy — turns the level into a workspace-enforced rule

These only affect what is surfaced, never what is scored.

When the score feels wrong

• Read the Risk factors list in the detail panel — the headline level is always backed by visible signals
• If a factor is incorrect, the underlying analyzer (package, code, dependency, npm, OSV) is the right place to investigate
• File a report with the extension ID, version, and the signals that look wrong