badBANANA // THREAT OBSERVATORY

Inspect exploited vulnerabilities and threat indicators, check their source evidence, and review retained changes.

Open the live Observatory · Try the KEV walkthrough · Source coverage · Run it yourself

The Observatory brings CISA KEV, ThreatFox, URLhaus, and MalwareBazaar into one analyst workspace. Use it to inspect source records, distinguish source dates from collection times, and export bounded current-state results. Missing, stale, disabled, or unavailable data stays visibly labeled.

Try it: inspect one exploited vulnerability

1. Open the live Observatory and select Sources to check CISA's availability and freshness.
2. Select Exploited, then RECENT KEV / DAY-GRANULAR and 7D. This scope uses CISA's date added, at day precision.
3. Open a returned CVE row. Inspect the source-specific vendor, product, required action, and ransomware-use fields alongside the record's provenance.
4. Compare OBSERVATION TIME, FIRST INGESTED, and LAST MATERIAL CHANGE. They answer different questions; a fresh fetch does not prove a new exploit.
5. Use OPEN VALIDATED UPSTREAM SOURCE PAGE when available to inspect the original reference.

If the seven-day view returns no matches, use CURRENT KEV CATALOG to inspect an existing entry. A successful empty result, a stale source, and an unavailable read have different meanings. None establishes that your systems are unaffected.

Result: a source-backed CVE record you can inspect and reference, with the date basis and collection limits visible. This workflow does not determine whether your own assets are vulnerable.

Export a scoped current-state page

Export is a separate workflow. Start in Pulse, Infrastructure, URLs, or Malware, choose a time window, and apply the available search or filters. Then select Export, review the source selection and visible-page counts, choose JSONL, CSV, STIX 2.1, defanged text, or a manifest, and download the result.

Exports cover the loaded page after the selected policy is applied. Review emitted and unsupported counts. The dedicated Exploited workspace's KEV filters do not carry directly into Export.

What the evidence means

Current source state, material-change events, and fetch telemetry remain separate. The interface never substitutes demo records or inferred attribution. Collection is demand-driven; this deployment does not claim continuous monitoring.

The implementation and limitations are documented below, including source coverage, retention, provenance, and export semantics.

Production views

Pulse — cross-source relationships, source health, and current-state analysis.

Replay — page-bounded reconstruction of retained NEW, UPDATED, and REMOVED transitions.

Additional live surfaces include approximate public-IP infrastructure geography and first-party URLhaus / MalwareBazaar evidence views. Those surfaces are intentionally not represented by placeholder or duplicated screenshots in this README.

Production captures are source-preserving screenshots from the live v1.2.0 Observatory. They are cropped and resized/compressed for presentation; displayed evidence, timestamps, counts, IOC values, and interface states are not regenerated or substituted.

Live deployment

• Production: https://badbanana-threat-observatory.badbanana6969.workers.dev
• Current source: https://github.com/GnomeMan4201/badBANANA-threat-observatory/tree/main
• Frozen v1.2.2 source: https://github.com/GnomeMan4201/badBANANA-threat-observatory/tree/release/v1.2.2

The production Worker is backed by Cloudflare D1. Feed credentials remain server-only Cloudflare Worker secrets and are never required in the browser.

Release status

• Version: 1.2.2
• Runtime: Node.js 22.13.0 or newer
• Deployment: Next.js on Cloudflare Workers through vinext and the Cloudflare Vite plugin
• Persistence: Cloudflare D1 with explicitly labeled isolate-memory degradation
• Production dependency audit: enforced in CI at high severity

Ingestion mode

This deployment runs in demand-driven mode. The repository now targets standard Cloudflare Workers directly; scheduled triggers are intentionally not enabled in v1.2.2, so the application does not claim continuous collection. A future scheduler can call the same runIngestionCycle() operation after separate correctness and operational verification.

The browser makes an explicit bounded maintenance request on initial use and every five minutes while open:

POST /api/ingest
        ↓
runIngestionCycle()
        ↓
configuration → TTL → backoff → D1 lease → fetch → normalize → validate
        ↓
snapshot cache + current observations + material events + cycle statistics

Ordinary reads are separate and local:

GET /api/observations → D1 current state, scoped before pagination
GET /api/search       → D1 current state, scoped before pagination
GET /api/kev          → D1 current CISA catalog
GET /api/events       → D1 material change ledger
GET /api/geo          → local observations + bounded cached IP enrichment

None of those GET routes calls a source adapter. If this project later gains a genuinely supported scheduler, it can call the same runIngestionCycle() operation without creating a second refresh implementation.

Source coverage

Source	Credential	TTL	Actual coverage
CISA KEV	None	30 minutes	Full current validated catalog
ThreatFox	THREATFOX_AUTH_KEY	15 minutes	Requested 24-hour IOC window
URLhaus	URLHAUS_AUTH_KEY	15 minutes	Latest 500 records returned by the recent endpoint
MalwareBazaar	MALWAREBAZAAR_AUTH_KEY	15 minutes	Latest 100 metadata records returned by the endpoint

Coverage is displayed per source. Bounded APIs are never presented as complete catalogs.

Storage model

The DB binding owns distinct datasets: