Osservatorio di threat intelligence che aggrega i feed di CISA KEV, ThreatFox, URLhaus e MalwareBazaar con ricerca, tracciamento delle modifiche ed esportazione in STIX/CSV/JSONL.
Un sistema di osservazione delle minacce incentrato sulle evidenze che mantiene semanticamente separati lo stato corrente della fonte, gli eventi di modifica sostanziale e la telemetria operativa di recupero. I dati mancanti, obsoleti, disabilitati o non disponibili restano visibilmente mancanti. L'interfaccia non sostituisce mai record dimostrativi o attribuzioni inferite.
La release attuale irrobustisce le date delle evidenze e lo stato di acknowledgement locale del dispositivo, rende tutti i fallimenti di lettura importanti visibilmente distinti dagli stati di successo con zero risultati, stabilizza le richieste di correlazione e rafforza il cassetto delle evidenze, i filtri di indagine limitati, l'interpretazione delle fonti, i controlli mobili e la contabilità dell'export. Ogni indicatore di replay animato corrisponde ancora a un evento NEW, UPDATED o REMOVED conservato; non è traffico di rete decorativo.
Pulse — relazioni tra fonti, salute delle fonti e analisi dello stato corrente.
Replay — ricostruzione limitata alla pagina delle transizioni NEW, UPDATED e REMOVED conservate.
Le superfici live aggiuntive includono la geografia approssimativa dell'infrastruttura a IP pubblico e le viste di evidenza di prima parte URLhaus / MalwareBazaar. Quelle superfici non sono rappresentate intenzionalmente da screenshot segnaposto o duplicati in questo README.
Le catture di produzione sono screenshot fedeli alla fonte dell'Osservatorio v1.2.0 live. Sono ritagliati e ridimensionati/compressi per la presentazione; le evidenze visualizzate, i timestamp, i conteggi, i valori IOC e gli stati dell'interfaccia non vengono rigenerati né sostituiti.
Il Worker di produzione è supportato da Cloudflare D1. Le credenziali dei feed restano segreti Cloudflare Worker solo lato server e non sono mai richieste nel browser.
1.2.022.13.0 o versioni successiveQuesta distribuzione opera in modalità demand-driven. Il repository ora punta direttamente ai Cloudflare Workers standard; i trigger schedulati non sono intenzionalmente abilitati in v1.2.0, quindi l'applicazione non dichiara una raccolta continua. Un futuro scheduler potrà chiamare la stessa operazione runIngestionCycle() dopo una verifica separata di correttezza e operatività.
Il browser effettua una richiesta di manutenzione esplicita e limitata al primo utilizzo e ogni cinque minuti finché è aperto:
POST /api/ingest
↓
runIngestionCycle()
↓
configuration → TTL → backoff → D1 lease → fetch → normalize → validate
↓
snapshot cache + current observations + material events + cycle statistics
Le letture ordinarie sono separate e locali:
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
Nessuna di quelle route GET chiama un adapter di fonte. Se in futuro questo progetto otterrà uno scheduler realmente supportato, potrà chiamare la stessa operazione runIngestionCycle() senza creare una seconda implementazione di aggiornamento.
La copertura è visualizzata per fonte. Le API con limiti non sono mai presentate come cataloghi completi.
Il binding DB possiede dataset distinti:
threat_source_cache e threat_source_cache_chunks: l'ultimo snapshot validato per fonte, archiviato in chunk con chiave di generazione.observations: ultimo stato corrente normalizzato per identità di fonte stabile. Conserva la prima ingestion, l'ultimo avvistamento della fonte, l'ultima modifica sostanziale, l'hash corrente, il conteggio delle revisioni e l'ultimo risultato di ingest.observation_events: eventi di evidenza significativi NEW, UPDATED e REMOVED difendibili. I payload normalizzati precedenti e correnti, gli hash e i diff deterministici dei campi rendono ricostruibili gli stati precedenti.source_fetch_log: telemetria limitata dei tentativi di fetch senza body di risposta o credenziali.source_ingest_cycles: conteggi limitati per aggiornamento di record recuperati, validi, rifiutati, nuovi, aggiornati, invariati e rimossi.source_refresh_lease: lease brevi supportati da D1 per fonte che impediscono a isolate simultanei di duplicare gli aggiornamenti upstream.ingestion_runtime: l'ultimo stato di salute complessivo del ciclo di ingestion.Le definizioni dello schema runtime si trovano in db/schema.ts. L'inizializzazione aggiunge le nuove colonne dello stato corrente a una tabella observations esistente prima di creare gli indici dipendenti.
Queste domande sono intenzionalmente diverse:
observations e lo snapshot di fonte validato rispondono a questa domanda./api/observations?window=... filtra le osservazioni correnti in base all'observedAt upstream.observation_events e /api/revisions rispondono a questa domanda.Lo stato corrente non viene descritto in modo inaccurato come una tabella di cronologia di sette giorni. Il registro degli eventi sostanziali viene conservato per sette giorni. La telemetria di fetch e ciclo viene conservata per due giorni e limitata a 200 righe per fonte. Le osservazioni correnti non di catalogo che non sono ricomparse per sette giorni vengono eliminate. CISA rimane corrente perché ogni risposta riuscita è un catalogo completo; le righe rimosse da quel catalogo restano disponibili per 30 giorni prima dell'eliminazione.
Solo l'assenza da CISA può attualmente creare un evento REMOVED, perché il suo adapter recupera un catalogo corrente completo. L'assenza dai risultati limitati di ThreatFox, URLhaus o MalwareBazaar non viene trattata come cancellazione.
Un avvistamento invariato aggiorna gli attuali lastObservedInSnapshotAt/lastIngestedAt ma non crea un evento né incrementa revisionCount. lastChangedAt sopravvive agli avvistamenti invariati successivi.
La vista Exploited separa:
dateAdded CISA con granularità giornaliera rientra in un intervallo esplicito TODAY, 7D o 30D. Le finestre dell'Osservatorio inferiori al giorno non sono mai presentate come precisione CISA.Il catalogo corrente supporta ricerca lato server, filtri per vendor, prodotto, aggiunta recente, associazione ransomware, data di aggiunta e paginazione a cursore opaca. Mostra CVE, vendor, prodotto, nome della vulnerabilità, data di aggiunta, data di scadenza, associazione ransomware e azione richiesta. Non inventa punteggi CVSS.
Gli hash dei contenuti coprono i campi di evidenza normalizzati, non la contabilità dell'Osservatorio. Un hash modificato produce un evento UPDATED con il payload normalizzato precedente, il nuovo payload normalizzato, gli hash precedente/nuovo e un diff deterministico su:
Il cassetto della provenienza interroga /api/revisions?id=... ed espone hash corrente, ultima modifica sostanziale, conteggio delle revisioni, eventi conservati e diff a livello di campo. I timestamp volatili di ingestion non compaiono nei diff dei contenuti.
Il cassetto espone anche una traccia di evidenza versionata per ogni record accettato: campi normalizzati accettati, campi opzionali rimasti assenti, trasformazioni solo di visualizzazione, la base di classificazione e la base di identità stabile. Questa traccia descrive solo le evidenze conservate. I valori upstream rifiutati non vengono conservati e non ricevono mai identità sintetiche dell'Osservatorio. I rifiuti sono rappresentati separatamente come conteggi aggregati per ciclo con codici di campo e motivo limitati; i vecchi cicli raccolti prima di quello schema sono etichettati come privi di un dettaglio anziché ricostruiti.
Recent Events mostra solo le modifiche sostanziali. Non emette centinaia di righe SEEN invariate dopo un aggiornamento CISA completo. Quegli avvistamenti sono riepilogati nelle statistiche dei cicli di fonte.
La vista Briefing predefinita confronta il registro degli eventi sostanziali conservato con un cursore di acknowledgement versionato archiviato solo nel browser corrente. Il primo utilizzo e l'archiviazione cancellata sono etichettati come baseline iniziale anziché nuova attività. Se un cursore salvato precede il registro conservato, l'interfaccia dichiara che un delta completo non può essere dimostrato.
L'acknowledgement non muta né elimina mai gli eventi del server. Il cursore può essere esportato e importato come JSON per un trasferimento deliberato tra dispositivi; non è presentato come stato sincronizzato con un account e l'identificatore di dispositivo generato non viene mai inviato al server.
I totali di Briefing descrivono la pagina del registro attualmente restituita e sono etichettati come mostrati/limitati alla pagina. Non sono presentati come totali dell'intero registro conservato.
I timestamp di acknowledgement importati sono validati rigorosamente e canonizzati in UTC ISO-8601 prima dell'archiviazione o del confronto. L'archiviazione nel browser è trattata come opzionale: un local storage bloccato o non funzionante produce un errore inline compatto e non causa mai il crash di Briefing.
Il workbench Export formatta la pagina visibile validata già caricata come CSV, JSONL, STIX 2.1, testo defangato o manifest di evidenze contenente la policy applicata e gli hash dei record disponibili. La ricerca locale attiva e lo scope delle fonti vengono trasferiti in Export. Una allow-list di fonti vuota esporta zero record. STIX rappresenta le CVE CISA come oggetti Vulnerability e gli hash di file validati—inclusi i valori SHA-256 di MalwareBazaar—come oggetti Indicator. I conteggi selezionati, emessi e non supportati sono distinti; i record non supportati sono dichiarati nei metadati del bundle anziché scartati silenziosamente. Export non esegue alcuna raccolta upstream. La confidenza mancante rimane mancante, i disaccordi tra fonti restano record separati e gli eventi rimossi dal registro non entrano mai silenziosamente negli export dello stato corrente. Questi artefatti sono trasporti di evidenze, non raccomandazioni di blocco firewall.
Le fonti scadute utilizzano ritardi di retry limitati di 1, 2, 5, 15 e 30 minuti. Un Retry-After valido maggiore è rispettato fino a un'ora. Durante il backoff, uno snapshot precedente valido viene servito come stale; una fonte vuota e fallita rimane offline.
Prima del fetch, una fonte idonea acquisisce un breve lease D1 condizionale. Un altro isolate non può sostituire un detentore non scaduto, quindi procede un solo aggiornamento. Se D1 non è disponibile, il sistema segnala esplicitamente la modalità degradata solo-snapshot e un lease in memoria dell'isolate; quel fallback non è descritto come distribuito.
Le osservazioni correnti, i workspace specifici per fonte, la ricerca locale, il catalogo CISA, gli eventi sostanziali e le revisioni dei record utilizzano query a cursore lato server con limiti. I vincoli di fonte e tipo sono applicati prima dell'ordinamento e della paginazione. I cursori codificano la tupla di ordinamento stabile, sono validati per lunghezza/caratteri/schema e falliscono in modalità fail-closed con HTTP 400 se malformati. Il browser non riceve mai il dataset completo di sette giorni solo per paginare localmente.
Il limiter API è un contatore in memoria a finestra fissa con scope limitato a un isolate Worker. È riportato accuratamente come protezione best-effort locale all'isolate, non come un rate limit Cloudflare globalmente autorevole. Le letture ordinarie sono limitate a 120 richieste al minuto per IP client riportato; l'ingestion ha un bucket separato di sei richieste al minuto e la geografia un bucket separato di dodici richieste al minuto. Le scritture D1 non vengono aggiunte a ogni lettura solo per sopravvalutare questo controllo.
POST /api/ingest — ciclo di manutenzione esplicito demand-driven; rispetta TTL, backoff e lease D1.GET /api/observations?window=24h&scope=urlhaus&limit=100&cursor=... — finestra paginata locale dello stato corrente; gli scope validati sono all, urlhaus, malwarebazaar e infrastructure.GET /api/search?q=indicator&window=24h&scope=urlhaus&limit=100&cursor=... — ricerca locale paginata con scope; zero chiamate upstream.GET /api/kev?limit=50&q=...&vendor=...&product=...&ransomware=known&addedSince=YYYY-MM-DD&cursor=... — catalogo CISA corrente completo.GET /api/events?limit=50&cursor=... — registro degli eventi sostanziali.GET /api/revisions?id=...&limit=50&cursor=... — record corrente più revisioni conservate.GET /api/correlations?id=... — peer con indicatore esatto nello stato corrente a livello di dataset.Lo sviluppo Cloudflare locale legge le credenziali solo-server da .dev.vars. Copia .dev.vars.example in .dev.vars e compila solo i feed che sei autorizzato a utilizzare:
THREATFOX_AUTH_KEY=
URLHAUS_AUTH_KEY=
MALWAREBAZAAR_AUTH_KEY=
Le credenziali di produzione devono essere archiviate come segreti Cloudflare Worker, mai sorgenti committate o variabili GitHub esposte al client. L'applicazione vi accede solo tramite la superficie di binding del runtime Workers. Non devono mai comparire in NEXT_PUBLIC_*, componenti client, HTML, log, fixture o file committati.
Il repository punta direttamente ai Cloudflare Workers standard. wrangler.jsonc è la fonte di verità della configurazione del Worker e dichiara un binding D1 di draft chiamato DB. Wrangler 4 provisiona automaticamente quella risorsa D1 al primo deployment autenticato e mantiene il binding collegato nei deployment successivi. Nessun identificatore D1 specifico dell'account viene committato.
Comandi di sviluppo e produzione:
npm ci
npm run dev
npm run build
npm run preview
# authenticated Cloudflare session / CI only
npm run deploy
La verifica GitHub Actions viene eseguita su ogni pull request e push su main. Il deployment di produzione è deliberatamente manuale tramite il workflow deploy production e richiede segreti del repository denominati CLOUDFLARE_API_TOKEN e CLOUDFLARE_ACCOUNT_ID. Questo impedisce a un branch non revisionato o a una configurazione di credenziali incompleta di pubblicare automaticamente.
npm ci
npm audit --omit=dev --audit-level=high
npm audit --audit-level=high
npm test
npm run lint
npm test è il punto di ingresso dei test supportato: esegue una build di produzione completa prima della suite deterministica, così l'isolamento dei segreti client a livello di artefatto può ispezionare dist/client. Eseguire node --test direttamente su un checkout pulito omette intenzionalmente quell'artefatto di build richiesto. I test coprono il parsing rigoroso di date di calendario e timestamp di acknowledgement, l'archiviazione opzionale nel dispositivo, le dipendenze di correlazione stabili, l'evidenza normalizzata, l'hashing canonico dei tag, la creazione di eventi sostanziali, la re-ingestion invariata, la conservazione dei payload precedenti, la durabilità dell'ultima modifica, i diff dei campi, la conservazione degli eventi e le lacune del registro, le tracce di evidenza, la policy di export con fonte vuota, l'integrità di rappresentazione/conteggio STIX, l'idoneità TTL/backoff, i lease di aggiornamento, il cablaggio lato server scope-prima-della-paginazione, le query dedicate GEO/Recent-KEV, la validazione dei cursori, l'isolamento del percorso di lettura, la copertura delle fonti, la policy dei riferimenti esterni, l'accuratezza della limitazione della frequenza, l'isolamento dei guasti delle fonti e l'isolamento dei segreti client.
La modalità GEO traccia solo osservazioni IPv4/IPv6 pubbliche validate. Una query D1 dedicata seleziona i record IP idonei nell'intera finestra dello stato corrente richiesta invece di riutilizzare la pagina generica delle osservazioni. La risposta riporta i totali dei record candidati e se è stato raggiunto il suo limite di sicurezza di 2.000 record. I chiamanti non possono fornire destinazioni upstream arbitrarie o elenchi di IP. GeoJS è il provider primario fisso e FreeIPAPI è il fallback fisso; gli URL upstream arbitrari sono impossibili. L'applicazione limita il lavoro esterno tramite un tetto di 12 indirizzi per richiesta, una cache di successo D1 di 30 giorni, una cache di retry di cinque minuti e un limiter di route dedicato. Ogni punto tracciato conserva la provenienza effettiva del provider e può aprire il suo record locale sottostante.
Rilasciato sotto la licenza MIT. Vedi LICENSE.
La selezione della modalità GEO comporta l'invio da parte del server di ogni candidato a IP pubblico validato, insieme ai normali metadati delle richieste HTTPS, a GeoJS e poi a FreeIPAPI quando è richiesto il fallback. Quei provider possono quindi osservare quali indirizzi pubblici vengono interrogati. Gli indirizzi privati, riservati, di documentazione e forniti dal client non vengono mai inviati; la modalità relationship non esegue richieste di geolocalizzazione.
Il workspace Replay ricostruisce la pagina corrente delle transizioni del registro sostanziale nell'ordine dei tempi di rilevamento dell'Osservatorio. Il movimento NEW, UPDATED e REMOVED è guidato esclusivamente dagli eventi archiviati. È esplicitamente limitato alla pagina e non pretende di ricostruire uno snapshot storico completo o il volume del traffico di rete.
Il pacchetto world-atlas, derivato da Natural Earth, fornisce la mappa di base locale. La mappa aggrega gli IP collocati, supporta i dettagli al passaggio del mouse e il click-through verso la provenienza e riporta i conteggi geolocalizzati, esclusi, non disponibili e in attesa. Gli intervalli privati, riservati, di documentazione, multicast e comunque non pubblici vengono esclusi prima di qualsiasi chiamata al provider.
La geolocalizzazione IP è esplicitamente presentata come posizione approssimativa dell'infrastruttura. Non è una posizione dell'attore, un'origine dell'evento, una nazionalità, un risultato di proprietà o una rivendicazione di attribuzione. L'arricchimento fallito resta assente; l'applicazione non genera mai coordinate sostitutive.
La visualizzazione predefinita rimane un campo interattivo force-directed di singole osservazioni collegate alla loro fonte e alla famiglia di malware fornita esplicitamente. La canvas supporta il trascinamento dei nodi, la panoramica del campo, lo zoom, il traffico animato dei collegamenti e l'ispezione diretta della provenienza. GEO è una superficie di evidenza separata con la propria semantica di provenienza e di fallimento.
| Fonte | Credenziale | TTL | Copertura effettiva |
|---|
| CISA KEV | Nessuna | 30 minuti | Catalogo completo validato corrente |
| ThreatFox | THREATFOX_AUTH_KEY | 15 minuti | Finestra IOC di 24 ore richiesta |
| URLhaus | URLHAUS_AUTH_KEY | 15 minuti | Ultimi 500 record restituiti dall'endpoint recent |
| MalwareBazaar | MALWAREBAZAAR_AUTH_KEY | 15 minuti | Ultimi 100 record di metadati restituiti dall'endpoint |
geo_ip_cache: risultati di geolocalizzazione IP approssimata validati e voci di cache negativa con limiti. I risultati riusciti scadono dopo 30 giorni; le ricerche fallite vengono ritentate dopo cinque minuti. Le righe D1 scadute vengono rimosse opportunisticamente durante le richieste GEO e il fallback dell'isolate è limitato a 2.000 voci.GET /api/geo?window=24h — deriva i candidati solo dalle osservazioni locali validate di IP pubblici, recupera al massimo 12 risultati di provider non in cache per richiesta e restituisce punti WGS84 approssimati in cache con provenienza.GET /api/status — semantica di fonti, stato corrente, freschezza, modalità di ingestion, ciclo, lease e limitazione della frequenza.