05 Incident / News Intelligence

English | 中文

This document supplements the Incident / News Watch that 01-Data-Sources-and-Processing does not expand separately. It handles security events that appear suddenly in the real world, evolve continuously and carry initially incomplete evidence: attacks, thefts, data breaches, supply-chain accidents, in-the-wild exploitation, fund transfers, service outages and the emergency response that follows.

Incident Intelligence uses the same source/evidence/provenance contract as Bug Stream and Insight Watch, but the data lifecycle differs. The value of News comes first from discovering events and tracking changes, and a technical fact can only be promoted after primary / forensic / authoritative evidence appears; repeated republication does not itself increase evidence strength.

Information role

Input to Incident Watch is managed by source role, rather than treating all media as knowledge sources of equal rank:

Source role	Problem solved	Typical content	Contribution to a claim
signal	what may be happening	news flashes, news, researcher disclosures, on-chain alerts	triggers discovery and follow-up
telemetry	whether the real-world state changed	transaction, address movement, IOC, status/telemetry	supports observations with a time boundary
primary	what the affected party actually confirmed	project/vendor announcements, security/status page, GitHub advisory/release	high-authority factual source
forensic	how the attack happened and how impact spread	IR, on-chain/off-chain analysis, technical postmortem	supports root cause, attack path, impact
authority	how the authorities define the threat and response	alerts/advisories from CISA/CERT/CC and others	supports threat/mitigation/known exploitation
reference	background, trends and secondary curation	industry media, monthly reports, features	discovery and context, does not raise technical authority on its own

Each SourceDefinition records source_role, source_family and upstream_source. For example, in "BlockBeats according to Lookonchain monitoring", BlockBeats is the publishing source and Lookonchain is the cited/upstream source; when two media outlets relay the same Lookonchain signal, the corroboration count is still one independent upstream source.

First-batch monitoring sources

All sources below serve the product incidents coverage category from 01. Table fields source_role and retention_mode align with executable SourceDefinition and are single-valued. When one provider produces breaking, forensic and reference material with different lifecycles, those are represented as different source streams or by promotion rather than compound values in one field. Access columns describe the stable access baseline; point-in-time provider reachability belongs to module README/local decision records.

Web3 breaking and timeline

Source	source_role	Access baseline	Value	retention_mode
BlockBeats newsflash	signal	public newsflash Web page	high-frequency Chinese Web3 newsflashes, relayed on-chain sleuthing and project announcements	incident_signal
Foresight News Timeline	signal	public Timeline page	continuously appended event nodes suited to timeline watch	incident_signal
The Block Exploits	signal	public tag/list page	global Web3 exploits, protocol/exchange security incidents and later fund/response developments	incident_signal

BlockBeats and Foresight News are suited to discovering Chinese Web3 events; The Block supplements English global coverage. All three are secondary signals, and technical conclusions continue to be traced back to the original project, on-chain data or security vendors.

On-chain and independent signals

Source	source_role	Access baseline	Value	retention_mode
Lookonchain	telemetry	public disclosure on social platforms	attacker / whale address, token movement, fund swaps and cross-chain transfers	incident_signal
PeckShieldAlert	telemetry	public disclosure on social platforms	exploit alerts, loss estimates, fund paths and monthly incident statistics	incident_signal
ZachXBT	signal	public disclosure on social platforms	independent investigations, address links and scam/attacker leads	incident_signal

This layer discovers events quickly, but platform access stability and automation permissions vary, so it remains one signal path rather than the sole monitoring chain. When an on-chain conclusion can be traced directly back to a transaction / address, the final evidence cites the on-chain object or a later forensic report with priority.

Web3 forensic and incident databases

Source	source_role	Access baseline	Value	retention_mode
CertiK Incident Analysis	forensic	public Incident Analysis page	independent incident postmortems, covering vulnerability mechanics, attack paths, losses and follow-up	durable_managed
CertiK Security Dashboard	reference	public dashboard	incident statistics, losses and major monthly incidents usable for discovery/benchmark sampling	durable_managed
SlowMist Hacked / SlowMist	forensic	public Hacked/incident material	Web3 attack incidents, emergency response, on-chain/off-chain analysis and fund tracing	incident_signal
SlowMist Reports	forensic	public reports / PDF	half-year and annual incident statistics, attack types and losses for long-term trends/case sampling	durable_managed
Cyvers	forensic	public security product/research content	Web3 security monitoring and incident/fund-flow analysis	durable_managed
Chainalysis	forensic	public research/blog	fund tracing, attack/criminal patterns, cross-incident correlation and post-incident analysis	durable_managed

General cybersecurity breaking news

Source	source_role	Access baseline	Value	retention_mode
BleepingComputer	signal	RSS / Web	data breaches, ransomware, zero-day, supply-chain and vendor security incidents	incident_signal
SecurityWeek	signal	public section/list pages	breach, ransomware, ICS/OT, supply-chain and enterprise security incidents	incident_signal

General cyber breaking coverage keeps a small heterogeneous set of sources; BleepingComputer is one stable RSS/Web signal source, while additional media are admitted by source diversity and coverage rather than adapter count.

Threat intelligence and incident response research

Source	source_role	Access baseline	Value	retention_mode
Google Threat Intelligence / Mandiant	forensic	public blog/index	incident investigation, campaign, TTP, supply chain and real-world AI-security attacks	durable_managed
Unit 42	forensic	public research index	high-profile threats, IR, active exploitation and AI/identity/supply-chain investigation	durable_managed
Cisco Talos Blog	forensic	public blog/newsletter	threat research, campaign, malware and vulnerability exploitation	durable_managed

This class of source usually updates more slowly than breaking news but has high technical density. It can both enrich an Incident from "it happened" to "how it happened" and enter the Insight Corpus after the event ends.

Primary and authoritative confirmation

Source	source_role	Access baseline	Value	retention_mode
Affected project/vendor security blog, status page, incident report	primary	dynamically discovered managed-content source stream	impact scope, response, recovery and official timeline	durable_managed
GitHub security advisory / issue / release / commit	primary	GitHub API/Git	fix, affected version, patch and public technical response	selective_index
CISA Cybersecurity Alerts & Advisories	authority	public advisory list	ongoing/high-impact threats, known exploitation, IOC/TTP, mitigation	durable_managed
CERT/CC and national/sector CERTs	authority	Web/feed probed per specific source	coordinated disclosure, alert, emergency response and mitigation	durable_managed

The URL of a primary source often has to be discovered dynamically after the event occurs, so it is both a long-term provider family in the source registry and a dynamic source target generated during M3/M5 follow-up.

Incident lifecycle

The data lifecycle of News/Incident is divided into three layers: signal, candidate and promoted incident:

breaking / telemetry / researcher signal
  -> SignalItem (short TTL)
  -> anchor extraction
  -> IncidentCandidate cluster
  -> source follow-up / timeline watch
  -> promotion decision
  -> SecurityIncident + durable evidence
  -> enrichment / investigation
  -> resolved / postmortem
  -> Insight + Experience

SignalItem

SignalItem is a short-lived monitoring object that retains:

source_id
source_role
source_family
upstream_source
published_at / observed_at
url
content_hash
title / summary
entity_hints
anchors
incident_candidate_id

Web3 anchors prioritize project, chain, token, address, tx hash, amount and time window; general cyber anchors prioritize organization, product, domain/IP, CVE/GHSA, threat actor, campaign and time window.

IncidentCandidate

IncidentCandidate means "multiple signals may belong to the same real-world event". It maintains:

cluster_id
candidate_type
anchor_set
source_diversity
independent_source_count
watch_priority
next_poll_at
last_material_change
unresolved_questions
promotion_state

Clustering uses deterministic anchors first, with semantic similarity supplementing weak identity. upstream_source is used to identify republication dependencies, preventing ten reports from the same origin being counted as ten independent confirmations.

Promotion

Any one of the following conditions allows entry into a durable SecurityIncident:

• confirmation by the affected project/vendor or an authority source;
• corroboration from two or more genuinely independent sources around the same verifiable anchor;
• direct evidence such as a transaction, IOC or GitHub advisory/patch;
• the event requires continuous M4/M5 investigation or user queries;
• analyst / benchmark pin.

Promotion fixes the source revisions that genuinely support the claim/timeline. After that, each piece of news still passes through SignalItem first; only nodes that produce a material change enter the durable timeline.

Incident timeline and enrichment

The timeline of a durable Incident uses append-only events:

incident_id
event_time
observed_at
event_type
summary
claim_refs
evidence_refs
source_role
supersedes / corrects

Later enrichment of an event focuses on:

• affected objects, products, repos, packages, versions;
• exploit / vulnerability / patch / fix commit;
• threat actor / campaign / IOC;
• Web3 address / transaction / fund flow;
• impact amount, user/asset scope and status revisions;
• mitigation, recovery, fund freeze/return;
• source conflict, unconfirmed root cause and attribution;
• postmortem and long-term security insight.

M4 organizes the timeline and evidence into confirmed / conflict / unknown; M5 can actively supplement sources for an unresolved question; the investigation trajectory after the event ends enters Experience Evolution.

Coverage composition and source acceptance

The Incident Watch source portfolio optimizes complementary roles rather than source count itself. Stable coverage now includes Chinese Web3 breaking/timeline, general cyber breaking, Web3 forensic material, authority/primary confirmation, independent threat-intelligence research, and on-demand telemetry/researcher signals. An event typically starts from signal evidence and gains factual strength through forensic/primary/authority/direct evidence.

Every Incident source admitted to the inventory must fix an access owner, one source_role, source_family / upstream_source semantics, one retention_mode, time/identity semantics, a fixture, dedup/source-independence tests, and a downstream consumer. A dynamic source family may resolve a concrete event-specific target later, but dynamic resolution does not increase source-category coverage by itself.

Source reachability changes with network conditions, anti-bot behavior, credentials and rate limits. Those point-in-time conditions are maintained through live probes/engineering records rather than inferred from the stable lifecycle contract in 05.

Runtime contract

Incident source onboarding follows the Source Definition / monitoring-runtime separation from 01. source_role expresses one primary role among signal/telemetry/primary/forensic/authority/reference, and retention_mode selects one processing path. When one provider emits both short-lived signals and long-lived forensic material, use separate source streams; Signal→durable Incident is a promotion transition rather than a compound retention mode.

The incident_signal path is fixed as SignalItem → deterministic anchor extraction → IncidentCandidate → promotion. Promotion creates a durable SecurityIncident; later material signals append incident revisions, timeline events, source links and evidence, while exact duplicate input remains replay. durable_managed forensic/authority/primary documents pass through Managed Content + EvidenceIngress before becoming Incident enrichment/evidence.

Republication dependency is retained through source_family / upstream_source, and independent corroboration is counted by independent upstream sources around the same strong anchor. Live reachability, anti-bot behavior, regional networks, credentials, rate limits and provider fallback are runtime/engineering state and do not change Incident taxonomy, source role or lifecycle contracts; historical probes/implementation decisions remain in local Wiki decision records.

Dynamic project/vendor/GitHub follow-up target discovery belongs to later M4/M5 investigation. Any new external content read still re-enters Acquisition + Evidence and cannot become an Incident fact directly from Agent/tool output.