The Threat Dashboard Exists Because Security News Gets Noisy Fast
Why I built Threat Intelligence Dashboard, how the pipeline collects CVEs and research, and why the dashboard is read-only and source-constrained.
Threat Intelligence Dashboard started because my first daily briefing idea was too loose. It could collect public security links and summarize them, but the result felt like a prettier news pile.
Security news gets noisy fast. The same story appears from several sources. A vendor post can sit beside an actively exploited CVE. Some items need patch triage. Others are just interesting reading with a serious face.
I rebuilt the project as a dashboard with stricter boundaries. The pipeline fetches from sources such as CISA KEV, NVD, FIRST EPSS, Microsoft Security, Unit 42, Cisco Talos, The DFIR Report, Mandiant, CrowdStrike, Elastic, Rapid7, and Huntress. It does not accept every story. It normalizes items into a small set of allowed types: CVE radar, threat research, and defender actions.
The part I like most is the local relevance layer. The watchlist has weighted groups for things like Windows and Identity, Network Edge, Linux and self-hosted services, Developer and CI/CD, and Detection and Response. That lets the dashboard raise the priority of items that match the kind of environment I care about instead of treating every headline equally.
The dashboard itself is read-only. That was deliberate. The server exposes system data, discoveries, pipeline health, run history, and a Markdown briefing, but the merge pipeline owns the data. If a source fails or the pipeline goes stale, the dashboard should show that instead of quietly pretending everything is current.
The development thinking is simple:
- collect only from named sources
- filter research with security keywords
- attach source diagnostics and item counts
- score CVEs with exploit signals and local relevance
- export a daily briefing only after data is validated and merged
Next I want the dashboard to be less dependent on me reading every tab. Better pipeline history, clearer failure states, and stronger duplicate handling would make it feel more like a work surface and less like a personal script that happens to have a UI.