Methodology & Reading Guide

Cyber Digest public site · how the per-story threat rating and the homepage threat index are computed, and how to read the visual vocabulary used across every digest.

Current (window ending 2026-10-14): Elevated · 67/100

164 stories in this window. Momentum: ▼ 10.3% (fall) vs the prior 14 days.

What this measures (and what it does not)

The threat rating reflects the severity and urgency of publicly reported security incidents in the Cyber Digest corpus. It is a measure of reported threat activity, derived from the same story database that powers the Story DB and monthly editions. It is not a prediction of future attacks, and it is only as current as the last published digest — a quiet score may mean incidents went undetected or unreported, not that none occurred.

It is an ordinal heuristic using banded words, not a probability and not a measurement of real-world danger. The scale is deliberately coarse, in line with how national threat levels (e.g. Australia’s terrorism threat levels, the UK’s MI5 levels) are presented — banded likelihood words rather than precise numbers.

Two layers

Layer 1 — per-story rating. Every story gets three independent labels, mirroring how CVSS separates intrinsic severity from exploitation status, and how ICD 203 separates likelihood from confidence:

Label	Values	What drives it
Severity	Guarded · Elevated · Severe · Critical	CVSS band if cited, kill-chain phase reached, impact class (operational disruption, data exposure volume, OT/physical impact), sector criticality
Urgency (exploitation)	Not yet observed · Possible · Probable · Observed	Observed exploitation (e.g. CISA KEV mentions, "exploited in the wild") overrides static severity, per CISA KEV doctrine
Confidence	Verified · Reported · Unverified	Source reliability tier (1 = official/first-party → Verified; 2 = established journalism → Reported; 3+ or single-source → Unverified)

Confidence is the gate: an Unverified story can never be rated Critical severity or Observed urgency — analysts never round up on an unattributed single-source claim.

Layer 2 — the homepage threat index

A rolling window — selectable on the homepage as 14, 30 or 90 days (default 14). Each story’s weight = severity_weight × urgency_weight × confidence_weight × (1 + 0.12 × ANZ relevance) × recency decay — recency decay is matched to the window (half-life = window length ÷ 2, so a story from the far edge of the window keeps about a quarter of its weight) — summed per day and averaged across the days covered. The result maps onto a coarse band:

Band	Meter /100	Meaning
Low	0–39	Little severe, actively-exploited reporting
Guarded	40–54	Elevated routine reporting, nothing exceptional
Elevated	55–69	Notable severe / active-incident reporting
Severe	70–84	Widespread critical or observed-exploitation activity
Critical	85–100	Sustained critical-incident reporting

Momentum compares the current window against the prior window of equal length (each window decayed relative to its own end, so it is a real trend, not a recency artefact).

Choosing a window. The homepage threat panel lets you switch between the 14-, 30- and 90-day views, changing both the index window and the trend chart's horizon. Recency decay is matched to each window (half-life = window ÷ 2), so a 90-day view uses a 45-day half-life and measures a full quarter of reported activity rather than collapsing to the most recent fortnight — and a longer window can legitimately read higher or lower than a shorter one depending on the reporting trend (a heavy quarter shows up in the 90-day score even while the latest fortnight is quiet). The 90-day view is labelled partial coverage while the archive is younger than the window (collection began 7 July 2026), and its momentum line is hidden until a full prior window exists to compare against.

How the labels are assigned (auditable rubric)

The rules live in threat_rating.py (Cyber Digest project). Signals are matched against headline + summary text; the highest-matching severity band wins, then confidence caps it. Examples: a KEV-listed bug “exploited in the wild” → Critical / Observed; a new zero-day with no exploitation reported → Severe–Elevated / Not yet observed; an unconfirmed single-source claim stays Elevated / Unverified.

Severity currently starts at Guarded for any reported story (everything in a cybersecurity digest is at least noteworthy). High-severity key signals include: CVSS ≥ 7, “exploited in the wild”, “millions of records”, ransomware, supply-chain compromise, nation-state/APT attribution, and OT/ICS physical impact.

Basis in assessment practice

• Threat / vulnerability / risk definitions and the capability × intent × targeting rating scales — NIST SP 800-30 Rev 1; opportunity per ITU-T X.1205
• Intrusion event framing with confidence per event — Diamond Model (Caltagirone et al., 2013)
• Severity vs exploitation separation — CVSS v4 (FIRST.org); observed-exploitation override — CISA KEV
• Band-based risk language and the warnings against false precision — OWASP Risk Rating Methodology
• Ability to estimate / confidence discipline and banded estimative language — ODNI ICD 203 Analytic Standards
• National threat-level presentation style — Australia’s threat advisory system; ASD/ACSC Cyber Threat Report
• Kill-chain phase as severity — Lockheed Martin, Cyber Kill Chain; TTP vocabulary — MITRE ATT&CK

How the site is produced (pipeline disclosure)

This is a largely automated, single-maintainer operation. The daily digests are assembled from publicly-reported sources, then rated and indexed by a Python pipeline backed by a SQLite database. The monthly editions and wiki are likewise generated from that database and from curated markdown. Some stages are AI-assisted — notably drafting, summarising and fact-checking support — but every story is tied to a deep-linked source, is rated for source reliability, and the monthly edition carries an explicit fact-check pass. Nothing on this site is fabricated or backdated to fill a quota; the Story DB and the digest archive are the same data you see everywhere else on the site.

You can audit the pipeline yourself: the build is reproducible from the vault, the database is the single source of truth, and every number on the homepage is computed from it at build time rather than hand-entered. Corrections and retractions are handled under the corrections policy.

Where the homepage numbers come from (provenance)

The threat index, story counts, sector and threat breakdowns, and the daily/monthly cards are all computed from the published digest archive in the SQLite database (the stories and digests tables) at every site build. They are not synthetic, hand-entered or backdated figures, and they are not a prediction. The rolling index described above is a real computation over the stories ingested in that window.

Why the globe count differs from the total. The homepage and full-page 3D globes plot a geolocatable subset of the story database — stories that resolve to a reliable country-level location. Stories that are global, regional, or lack a reliable country are excluded, so the globe's "N stories" is always lower than the total in the Story DB. The two numbers answer different questions: the total is "how many stories we hold", the globe is "how many we can place on a map".

Revision discipline

This index is recomputed from the database on every site build. As the corpus grows the calibrations (band thresholds, decay half-life, weights) may be re-tuned — when that happens the values on this page and the homepage will change together, and the change is disclosed here. If a rating looks wrong, the relevant story card links to its source for verification.

Changelog

• 2026-09-07 — Recency decay is now matched to the selected window (half-life = window ÷ 2). The 14-day view keeps its ≈7-day half-life; the 30- and 90-day views now weigh their full span instead of collapsing to the most recent fortnight, and are directly comparable with the 14-day view.
• 2026-09-02 — Added pipeline/AI disclosure, threat-index provenance and a globe-vs-total count explanation. Added the responsible-disclosure, privacy, corrections and licensing policy pages. Vendored the echarts + world-map assets locally (no more runtime CDN calls on the map pages). Added a monthly RSS feed. Added JSON-LD structured data to every page.
• 2026-08-31 — Site audit; methodology page rewritten to use the shared site chrome (previously a standalone document).

How to read a digest

Every daily and monthly edition uses the same small visual vocabulary. Two of the tokens are "pills" — an identifier replaced by a styled, linked chip — and they encode different kinds of claim. Confusing them is the single easiest mistake to make on this site, so it is worth stating plainly.

CVE pills colour severity — a measurement

A CVE identifier is coloured by its CVSS base band from the National Vulnerability Database: Critical 9.0 and above, High 7.0–8.9, Medium 4.0–6.9, Low below 4.0. Where a vendor's own label and the CVSS band disagree, the CVSS band wins. An identifier whose band cannot be resolved renders neutral and dashed rather than guessing — absence reads as absence, not as "low". Clicking one opens the CVE in the ATT&CK matrix tool, or its wiki page when the matrix does not hold it.

Threat-actor pills colour attribution confidence — a claim

An actor name is drawn from the MITRE ATT&CK intrusion-set registry (191 groups, 811 names and aliases). There is deliberately no severity colour here: unlike a vulnerability there is no measured number for how dangerous an actor is, and colouring by sponsor country would make a contested political claim on a public page. So the colour describes how well-corroborated the naming is.

Where ATT&CK states no attribution, the pill says so instead of guessing, and where ATT&CK hedges, or two sponsors are equally plausible, it renders contested. A pill links to this wiki's actor page, which carries the aliases, the ATT&CK identifier and the mapped techniques. Because the same actor carries several vendor names (ATT&CK, Microsoft, Google TAG, CrowdStrike), the pill shows the name as the source used it and the page reconciles the aliases.

Story signals

Reliability tier (1 = official primary, 4 = leads only) grades the source. Verification records whether a story is corroborated: Verified by a second source or the principal, Reported when a single outlet carries it or the claim is still in progress, Unverified where we could not corroborate it. Breach classification separates a breach the victim or a regulator has acknowledged (Confirmed) from one that is indicated but unacknowledged (Probable).

Indicators of compromise

Where a story names a malware family for which live abuse.ch indicators exist, the card carries an IOCs badge and a collapsed Indicators of compromise block of defanged values (hxxp://, evil[.]com). The defanging is deliberate: never click, resolve or fetch these values, and note that nothing on this site ever requests one. Indicators are third-party claims — they corroborate a report, they never prove one, and their presence does not mean a story's own hosts are listed.