Scoring

How the risk score and band are computed

Extuno assigns every scan a 0-100 risk score and a band from clean to critical. The score is not a black box: each point traces back to a specific check with a severity, a weight, and an evidence-carrying finding.

In shortThe risk score is the weighted sum of every finding's severity contribution, mapped onto a 0-100 scale and a band (clean, low, review, high, critical). Each contribution is traceable to one finding with a file, a line, and the reason it is dangerous.

What are the bands and what does each mean?

Every scan resolves to one of five bands. Clean means no findings of consequence. Low means minor or informational findings only. Review means dual-use or capability signals that a human should look at before trusting the package. High and critical mean strong evidence of dangerous behavior, such as confirmed exfiltration, install-time code execution, or a credential leak.

The band is the primary verdict an operator reads first. The 0-100 score sits beside it as a finer-grained number for sorting and triage. Both are derived from the same set of findings, so the band and the score never disagree about the same scan.

How is the 0-100 score computed?

Each detection rule carries a category, a severity on the scale info, low, medium, high, critical, and a weight. When a rule fires it produces a finding. The scorer multiplies the finding's severity factor by the rule's weight to get that finding's contribution, sums the contributions, and passes the total through a saturating curve so a package with many findings cannot run past 100.

Weights live in a registry outside the scoring engine, so adding or tuning a check never changes the engine itself. The result is a single number where a higher score means more, or more severe, evidence-backed findings. See the methodology for how checks are built and validated.

Why does a leaked secret not always score critical?

A secret's score depends on its provenance, not just its rule severity. A directly usable credential, such as a private key or a cloud secret paired with a service account, bands critical. A secret confirmed at runtime in captured sandbox traffic, or surfaced by AI code analysis, bands high. Any other static secret match is capped at the review band, because a string that matches a token shape is not always a live, exploitable credential.

This provenance weighting keeps the broad secret detector catalog of 1000-plus patterns useful without flooding operators with critical alarms for low-confidence matches. The category and confidence of every secret finding are recorded on the result.

How does Extuno avoid flagging popular, legitimate extensions?

Hugely popular store extensions legitimately do things that look dangerous in isolation: they read storage and send it to a server, handle credentials, and update filter lists. To prevent a constant false critical on these, Extuno applies an install-trust floor. A store extension above a high install-count threshold, with no confirmed-malicious signal present, is floored to the clean band.

The floor never hides real attacks. A confirmed-malicious signal, such as the supply-chain compromise that version diffing catches, overrides the floor and the package bands critical regardless of install count. Popularity buys the benefit of the doubt, not immunity.

Is the score explainable and traceable?

Yes. Every point in the score maps to a finding, and every finding carries the file, the line, the masked or full evidence snippet, why the behavior is dangerous, and the recommended action. There is no bare risk number with nothing behind it. An operator can open any scan, sort by contribution, and read the exact code that produced each part of the verdict.

The same data drives the CI gate: you set fail_on to specific severities or categories, and a build blocks on the underlying findings rather than on an opaque threshold. The sample report shows the full structure end to end.

A scored finding (Extuno JSON)
{
  "rule_id": "det.taint.auth_storage_to_network",
  "category": "taint",
  "severity": "high",
  "weight": 14,
  "contribution": 21.0,
  "confidence": "high",
  "file": "background.js",
  "line": 412,
  "why": "auth token read from storage flows to a remote endpoint",
  "recommended_action": "remove the exfiltration path; rotate the token"
}

Frequently asked questions

What is the difference between the score and the band?

The score is a 0-100 number for sorting and triage. The band is a five-level verdict from clean to critical. Both are computed from the same findings, so they always agree about a given scan. Operators usually read the band first and use the score to rank scans within a band.

Can the score exceed 100?

No. Contributions are summed and then passed through a saturating curve, so a package with very many or very severe findings stays bounded at 100. This keeps the scale stable and comparable across scans of different sizes.

Why did a confirmed secret only land in the review band?

Secret scoring is provenance-weighted. A static pattern match that is not confirmed as a live, directly usable credential is capped at review. If the same value is confirmed at runtime in captured sandbox traffic, or is a directly usable key type, it bands high or critical instead.

Does the install-trust floor let malware through?

No. The floor only applies when no confirmed-malicious signal is present. A confirmed signal, such as a benign-to-dangerous escalation across an update, overrides the floor and the package bands critical regardless of how many installs it has.

Can I see why a scan got its score?

Yes. Open the scan and every finding lists its file, line, evidence, reason, and recommended action, along with its contribution to the total. Nothing in the score is hidden behind an unexplained number.

Related