How it works
Threat Scoring Methodology
How scores combine indexed data, configured source weights and live enrichment, and what they do not prove.
Pipeline
How the scoring pipeline works
- 01
Multi-source ingestion
Scheduled jobs ingest feeds into the indexed dataset; lookups read it and can request live enrichment. Feeds, contributing sources and enrichment providers are counted separately.
- 02
Configured source weights
Weights are configured scoring rules, not measured accuracy: Google Safe Browsing 0.95, StopForumSpam 0.70. A URL listing counts half when scoring its host.
- 03
Cross-provider correlation
Cross-provider signals add a separate factor when present. Shared upstream data means several listings are not always independent evidence.
- 04
Confidence calculation
Base weights below, renormalized over the factors present; scanner and cross-provider factors are conditional. Confidence is a score, not a probability of maliciousness.
- 05
Enrichment and context
Geolocation, ASN, WHOIS, DNS, certificates or OTX, depending on indicator type, upstream response and cache. Missing enrichment does not mean safe.
Scoring
Confidence score factorsThe weighted sum is divided by the sum of included weights. If an already flagged malicious input has sources and scores below 30, the score is raised to at least 35. This score does not define the malicious verdict.
| Factor | Base weight | Description |
|---|---|---|
| Source agreement | 33 % | Distinct publishers among threat listings; duplicate listings and tracker-only entries do not add independent votes |
| Source quality | 22 % | Configured weights of the flagging sources, not measured accuracy |
| Scanner consensus | 18 % | Included only when scanner engines returned verdicts |
| Cross-provider agreement | 12 % | Included when cross-correlation data is available |
| Data completeness | 10 % | Presence of expected facets for the indicator type |
| Data freshness | 5 % | Age from available observation or update dates; dates can be missing |
Sources
Examples of configured source weightsBands A (at least 0.90), B (at least 0.75) and C are display groups, not benchmark grades. A configured weight does not confirm that the source is active or contributes to a particular result.
Read from the scoring configuration on 2026-10-08. Not a list of active feeds or of providers queried per request.
| Source | Category | Configured weight |
|---|---|---|
| Google Safe Browsing | Phishing & malware | 0.95A |
| PhishTank | Phishing | 0.90A |
| OpenPhish | Phishing | 0.90A |
| URLhaus (abuse.ch) | Malware distribution | 0.90A |
| Abuse.ch | C2 & malware | 0.90A |
| Spamhaus | Spam & abuse | 0.85B |
| SURBL | Spam URL blocklist | 0.85B |
| Feodo Tracker | Banking trojan C2 | 0.85B |
| AlienVault OTX | Threat intelligence | 0.80B |
| Malware Domains | Malware hosting | 0.80B |
| Tor Project | Anonymization network | 0.80B |
| Malware Domain List | Malware hosting | 0.75B |
| Blocklist.de | Brute-force & abuse | 0.75B |
| ThreatCrowd | Threat intelligence | 0.75B |
| AbuseIPDB | IP abuse reporting | 0.70C |
| StopForumSpam | Forum spam | 0.70C |
Freshness
Data freshness
- Feed ingestion, collection rebuilds, client polling and upstream publication run on separate clocks: hourly polling is not hourly observation.
- Use firstSeen, lastSeen, lastUpdated and dataTrust when present. An update time is not the first upstream observation.
- Schedules, caches and upstream failures can delay updates. There is no universal 24-hour freshness guarantee.
Interpretation
False positive handling
- Contradictory signals and source details, when returned, help an analyst review a verdict. They are not a measured false-positive rate.
- Shared infrastructure and repeated upstream listings need context: check your own logs before blocking on a score.
- Report a suspected false positive through the contact form, with the indicator and the evidence that the result is wrong.
Inspect a real API response
Compare the returned fields, timestamps and gaps with the sources you already use.