ThreatWatch

Problem

Threat intel for a small SOC team has two failure modes. Either everyone reads the same handful of blogs and quietly misses the rest, or everyone subscribes to fifty feeds and drowns. The middle path — curated, deduplicated, delivered on a schedule — usually means a paid platform that isn’t proportional to a five-person rotation.

Approach

ThreatWatch polls a curated RSS feed list every 30 minutes, deduplicates articles through a three-layer fingerprinting engine, scores each item by severity and source weight, and posts a formatted digest to Slack at a configured time. High-severity breaking items skip the digest queue and fire immediately.

The dedup engine is the part that matters:

Layer 1: URL canonicalization        — strips tracking params, resolves redirects
Layer 2: Entity overlap              — extracts named entities (CVEs, threat actors, malware families)
                                       and compares pairwise across the rolling 7-day window
Layer 3: Jaccard similarity on lede  — shingle the first 300 chars, threshold 0.75

A single-file HTML admin dashboard handles feed sources, the delivery log, and per-profile config. FastAPI backend, SQLite for state, no external services beyond the feeds themselves.

Outcome

One curated digest at a predictable time, with high-severity items still surfacing in real time. Tuning the source list or severity weights is a 30-second config edit, not a vendor support ticket — which matters when a feed’s signal goes sideways on a Friday.

What’s next

Per-tenant context filters are the next priority: items mentioning a specific vendor or sector get tagged when they match a tenant in the digest. Source weights also need an evaluation harness — I want to catch when a feed’s signal-to-noise shifts before it pollutes a week of digests.