Skip to main content
Every OpenSourceMalware threat record has a severity level. Severity describes how much harm a malicious asset can do to the people who install, run, or contact it. Use it to prioritize your response: which records to act on first, and how urgently. Severity appears on each threat record in the web UI and in API responses as severity_level.

​
What each severity level means

Records at every level, including Info, return "malicious": true from the check-malicious endpoint. Check severity_level to tell Info records apart from malware.

​
What severity doesn’t tell you

  • Your actual exposure. Severity describes the threat as if no defenses were in place. Your own controls, such as lockfiles, install-script restrictions, endpoint protection, or network blocks, may lower your real risk, but they don’t change the base severity.
  • The current state of the attack. Severity is set when a record is created or modified. It isn’t adjusted as the situation changes, for example when attacker infrastructure is later taken down.

​
How severity is determined

Severity reflects real-world impact. Each record starts from what the asset does, and is then adjusted for how many people it can reach and whether the attack still works at the time we ingest the record.

​
What the asset does

The asset’s capabilities set its starting level: When an asset is confirmed malicious but its full behavior isn’t yet known, we default to a High rating.

​
Adjustments

  • Reach. An asset used widely enough to affect a large number of people can be rated Critical even if its capabilities alone would put it lower. Download counts, the popularity of a compromised package, and use in CI pipelines all factor in.
  • Account takeovers. When a legitimate, previously trusted asset is compromised through a takeover of the maintainer’s or publisher’s account, the record is rated at least High, and Critical when the impact is widespread.
  • Disrupted attacker infrastructure. If part of the attacker’s infrastructure has been taken down, such as a seized command-and-control server or a removed payload host, the severity can be lowered by one or two levels, but never below Medium. This doesn’t apply when the attacker can easily replace the infrastructure, for example when command-and-control addresses are fetched from a source the attacker can update.

​
What doesn’t lower severity

  • Registry removal. A malicious package stays rated at its original severity after a registry removes it. Packages persist in mirrors, caches, and local copies, so removal from the registry doesn’t mean the threat is gone.
  • Research intent. A package that exfiltrates real credentials is rated at least Medium, even when it was published as a security research or bug bounty test.
  • Defensive controls. Severity always assumes no mitigations are in place.

​
How our analysis engine contributes

Submitted threat reports go through a review process before they’re published. As part of that review, our proprietary analysis engine examines the reported asset. It performs static analysis, decodes obfuscated payloads, extracts indicators, evaluates metadata signals such as typosquatting and suspicious publishers, and matches known malware signatures. The engine’s results inform the severity a reviewer assigns, alongside the evidence in the report and the reviewer’s own analysis. The final severity on a published record is always set through human review. It’s rare that we upgrade a severity; most submitters overestimate severity so it’s more likely that we downgrade it.

​
Choosing a severity when you submit a report

If you’re submitting a threat report, choose the level that matches the rules above. Reviewers may adjust it during verification. Exaggerated severity is one of the signs of a poor report (see reporting guidelines), so when you’re unsure between two levels, choose the lower one.