This was one of those projects I had wanted to make for a long time, even before I had a very clear reason for it.
Over the years, if you spend enough time around security, you keep seeing threat maps. A lot of them are visually impressive. They pull you in immediately. Lines moving across a globe, attacks firing in real time, counters climbing, everything looking active.
But once I started learning more about how threat data actually works, I kept coming back to the same problem: a lot of those interfaces are more presentation than evidence.
That is not necessarily a criticism. Some are demos, some are educational, some are marketing surfaces, and some are useful at a high level. But visually convincing does not always mean analytically meaningful.
I wanted to build something that still had that same sense of observation and movement, but where the underlying data had to earn what the interface was showing.
That is where the badBANANA Threat Observatory came from.
It watches CISA KEV, ThreatFox, URLhaus, and MalwareBazaar, but the part I cared most about was not the dashboard itself. It was the evidence handling.
I did not want missing data to become zeroes. I did not want bounded feeds to look complete. I did not want invalid indicators to get silently reclassified, impossible dates to roll into different dates, or malformed hashes to get truncated into something that looked valid.
So the last stretch of the project was mostly audit work.
I went through the source repeatedly looking for places where the system could accidentally overstate what it knew. That led to stricter IOC and hash validation, safer exports, better release provenance, client/server credential isolation checks, production deployment gates, and a lot of work around making sure the public release actually matched the exact source that had been reviewed.
The current version keeps a clear separation between:
- what a source says now
- what changed between observations
- what the system actually retained
- what was rejected
- what is missing or unavailable
- what cannot be proven from the available data
That distinction matters more to me than making the interface look “complete.”
A bounded API should look bounded.
A failed source should look failed.
Missing confidence should stay missing.
An unsupported record should not silently become something else.
The Observatory is not meant to replace an analyst, and it is not trying to pretend that every event on screen is part of some live global cyberwar.
It is meant to make the state of the evidence easier to inspect without quietly filling in the gaps.
The public release went through multiple audit and remediation passes, including strict ThreatFox type handling, MalwareBazaar hash validation, spreadsheet safe exports, deployment hardening, metadata cleanup, and independent release provenance verification.
Everything is public now.
Live:
https://badbanana-threat-observatory.badbanana6969.workers.dev
Source:
https://github.com/GnomeMan4201/badBANANA-threat-observatory
Release:
https://github.com/GnomeMan4201/badBANANA-threat-observatory/releases/tag/v1.2.0
If anyone actually uses it and finds a concrete problem, I would rather hear about that than get praise for it.
Top comments (0)