Observatoire de renseignement sur les menaces agrégeant les flux CISA KEV, ThreatFox, URLhaus et MalwareBazaar avec recherche, suivi des modifications et export STIX/CSV/JSONL.
Un système d'observation des menaces centré sur les preuves qui maintient séparés sur le plan sémantique l'état actuel des sources, les événements de changement matériel et la télémétrie opérationnelle de collecte. Les données manquantes, obsolètes, désactivées ou indisponibles restent visiblement manquantes. L'interface ne substitue jamais d'enregistrements de démonstration ni d'attribution déduite.
La version actuelle renforce les dates de preuve et l'état d'accusé de réception local à l'appareil, rend toutes les erreurs de lecture importantes visuellement distinctes des états de résultat zéro réussis, stabilise les requêtes de corrélation et améliore le panneau de preuves, les filtres d'investigation bornés, l'interprétation des sources, les commandes mobiles et la comptabilité des exportations. Chaque marque de relecture animée correspond toujours à un événement NEW, UPDATED ou REMOVED conservé ; il ne s'agit pas d'un trafic réseau décoratif.
Pulse — relations inter-sources, santé des sources et analyse de l'état actuel.
Replay — reconstruction bornée par page des transitions conservées NEW, UPDATED et REMOVED.
D'autres surfaces en direct incluent la géographie approximative de l'infrastructure d'adresses IP publiques et des vues de preuves URLhaus / MalwareBazaar de première partie. Ces surfaces ne sont volontairement pas représentées par des captures d'écran factices ou dupliquées dans ce README.
Les captures de production sont des captures d'écran préservant les sources, issues de l'Observatoire v1.2.0 en direct. Elles sont recadrées et redimensionnées/compressées pour la présentation ; les preuves affichées, les horodatages, les comptes, les valeurs d'IOC et les états d'interface ne sont pas régénérés ni remplacés.
Le Worker de production s'appuie sur Cloudflare D1. Les identifiants des flux restent des secrets Cloudflare Worker côté serveur et ne sont jamais requis dans le navigateur.
1.2.022.13.0 ou plus récentCe déploiement fonctionne en mode piloté par la demande. Le dépôt cible désormais directement les Cloudflare Workers standard ; les déclencheurs planifiés ne sont volontairement pas activés dans v1.2.0, de sorte que l'application ne revendique pas une collecte continue. Un planificateur futur pourra appeler la même opération runIngestionCycle() après une vérification séparée de l'exactitude et du fonctionnement.
Le navigateur effectue une requête de maintenance bornée explicite à la première utilisation puis toutes les cinq minutes lorsqu'il est ouvert :
POST /api/ingest
↓
runIngestionCycle()
↓
configuration → TTL → backoff → D1 lease → fetch → normalize → validate
↓
snapshot cache + current observations + material events + cycle statistics
Les lectures ordinaires sont séparées et locales :
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
Aucune de ces routes GET n'appelle d'adaptateur de source. Si ce projet obtient plus tard un planificateur réellement pris en charge, il pourra appeler la même opération runIngestionCycle() sans créer une seconde implémentation d'actualisation.
La couverture est affichée par source. Les API bornées ne sont jamais présentées comme des catalogues complets.
La liaison DB possède des ensembles de données distincts :
threat_source_cache et threat_source_cache_chunks : la dernière capture validée par source, stockée en morceaux indexés par génération.observations : dernier état normalisé actuel par identité de source stable. Il préserve la première ingestion, la dernière observation de source, le dernier changement matériel, le hachage actuel, le nombre de révisions et le dernier résultat d'ingestion.observation_events : événements de preuve significatifs NEW, UPDATED et REMOVED justifiables. Les charges utiles normalisées précédentes et actuelles, les hachages et les différences de champs déterministes rendent les états antérieurs reconstructibles.source_fetch_log : télémétrie bornée des tentatives de collecte sans corps de réponse ni identifiants.source_ingest_cycles : comptes bornés par actualisation pour les enregistrements collectés, valides, rejetés, nouveaux, mis à jour, inchangés et supprimés.source_refresh_lease : baux de courte durée adossés à D1 par source empêchant des isolates simultanés de dupliquer les actualisations en amont.Les définitions de schéma d'exécution se trouvent dans db/schema.ts. L'initialisation ajoute les nouvelles colonnes d'état actuel à une table observations existante avant de créer les index dépendants.
Ces questions sont volontairement différentes :
observations et la capture de source validée y répondent./api/observations?window=... filtre les observations actuelles par observedAt en amont.observation_events et /api/revisions y répondent.L'état actuel n'est pas décrit de manière inexacte comme une table d'historique de sept jours. Le registre des événements matériels est conservé pendant sept jours. La télémétrie de collecte et de cycle est conservée pendant deux jours et plafonnée à 200 lignes par source. Les observations actuelles hors catalogue qui ne sont pas réapparues depuis sept jours sont élaguées. CISA reste actuel parce que chaque réponse réussie est un catalogue complet ; les lignes supprimées de ce catalogue restent disponibles pendant 30 jours avant élagage.
Seule l'absence côté CISA peut actuellement créer un événement REMOVED, car son adaptateur récupère un catalogue actuel complet. L'absence dans les résultats bornés de ThreatFox, URLhaus ou MalwareBazaar n'est pas traitée comme une suppression.
Une observation inchangée fait avancer lastObservedInSnapshotAt/lastIngestedAt actuels mais ne crée pas d'événement ni n'incrémente revisionCount. lastChangedAt survit aux observations inchangées ultérieures.
La vue Exploited sépare :
dateAdded CISA à granularité journalière tombe dans une plage explicite TODAY, 7D ou 30D. Les fenêtres de l'Observatoire inférieures à une journée ne sont jamais présentées comme une précision CISA.Le catalogue actuel prend en charge la recherche côté serveur, les filtres par fournisseur, produit, ajout récent, association à un rançongiciel et date d'ajout, ainsi qu'une pagination par curseur opaque. Il affiche le CVE, le fournisseur, le produit, le nom de la vulnérabilité, la date d'ajout, la date limite, l'association à un rançongiciel et l'action requise. Il n'invente pas de scores CVSS.
Les hachages de contenu couvrent les champs de preuve normalisés, et non la comptabilité de l'Observatoire. Un hachage modifié produit un événement UPDATED avec la charge utile normalisée antérieure, la nouvelle charge utile normalisée, les hachages antérieur/nouveau et une différence déterministe sur :
Le panneau de provenance interroge /api/revisions?id=... et expose le hachage actuel, le dernier changement matériel, le nombre de révisions, les événements conservés et les différences au niveau des champs. Les horodatages d'ingestion volatils n'apparaissent pas dans les différences de contenu.
Le panneau expose également une trace de preuve versionnée pour chaque enregistrement accepté : champs normalisés acceptés, champs facultatifs restés absents, transformations d'affichage uniquement, base de classification et base d'identité stable. Cette trace ne décrit que les preuves conservées. Les valeurs amont rejetées ne sont pas conservées et ne reçoivent jamais d'identités synthétiques de l'Observatoire. Les rejets sont représentés séparément sous forme de comptes agrégés par cycle avec des codes de champ et de raison bornés ; les anciens cycles collectés avant ce schéma sont étiquetés comme dépourvus de ventilation plutôt que reconstruits.
Recent Events n'affiche que les changements matériels. Il n'émet pas des centaines de lignes SEEN inchangées après une actualisation complète de CISA. Ces observations sont résumées dans les statistiques de cycle de source.
La vue Briefing par défaut compare le registre des événements matériels conservés avec un curseur d'accusé de réception versionné stocké uniquement dans le navigateur actuel. La première utilisation et le stockage effacé sont étiquetés comme une référence initiale plutôt que comme une nouvelle activité. Si un curseur enregistré est antérieur au registre conservé, l'interface indique qu'un delta complet ne peut pas être prouvé.
L'accusé de réception ne modifie ni ne supprime jamais d'événements serveur. Le curseur peut être exporté et importé en JSON pour un transfert délibéré entre appareils ; il n'est pas présenté comme un état synchronisé par compte et l'identifiant d'appareil généré n'est jamais envoyé au serveur.
Les totaux de Briefing décrivent la page du registre actuellement renvoyée et sont étiquetés comme visibles/limités à la page. Ils ne sont pas présentés comme des totaux pour l'ensemble du registre conservé.
Les horodatages d'accusé de réception importés sont strictement validés et canonisés en UTC ISO-8601 avant stockage ou comparaison. Le stockage navigateur est traité comme facultatif : un stockage local bloqué ou défaillant produit une erreur compacte en ligne et ne fait jamais planter Briefing.
L'atelier d'exportation formate la page visible validée déjà chargée en CSV, JSONL, STIX 2.1, texte désamorcé ou manifeste de preuves contenant la politique appliquée et les hachages d'enregistrement disponibles. La recherche locale active et le périmètre de source sont repris dans l'exportation. Une liste d'autorisation de sources vide exporte zéro enregistrement. STIX représente les CVE CISA comme objets Vulnerability et les hachages de fichiers validés—y compris les valeurs SHA-256 de MalwareBazaar—comme objets Indicator. Les comptes sélectionnés, émis et non pris en charge sont distincts ; les enregistrements non pris en charge sont divulgués dans les métadonnées du lot plutôt que silencieusement supprimés. L'exportation n'effectue aucune collecte en amont. La confiance manquante reste manquante, les désaccords inter-sources restent des enregistrements séparés et les événements de registre supprimés n'entrent jamais silencieusement dans les exportations d'état actuel. Ces artefacts sont des transports de preuves, pas des recommandations de blocage de pare-feu.
Les sources expirées utilisent des délais de nouvelle tentative bornés de 1, 2, 5, 15 et 30 minutes. Un Retry-After valide plus grand est respecté jusqu'à une heure. Pendant le backoff, une capture antérieure valide est servie comme périmée ; une source vide en échec reste hors ligne.
Avant la collecte, une source éligible acquiert un bail conditionnel D1 de courte durée. Un autre isolate ne peut pas remplacer un titulaire non expiré, donc une seule actualisation se déroule. Si D1 est indisponible, le système signale explicitement un mode dégradé limité aux captures et un bail en mémoire d'isolate ; ce repli n'est pas décrit comme distribué.
Les observations actuelles, les espaces de travail spécifiques aux sources, la recherche locale, le catalogue CISA, les événements matériels et les révisions d'enregistrements utilisent des requêtes par curseur côté serveur bornées. Les contraintes de source et de type sont appliquées avant le tri et la pagination. Les curseurs encodent le tuple de tri stable, sont validés en longueur/caractères/schéma et échouent en sécurité avec un HTTP 400 en cas de malformation. Le navigateur ne reçoit jamais l'ensemble complet des données de sept jours uniquement pour paginer en local.
Le limiteur d'API est un compteur en mémoire à fenêtre fixe limité à un isolate Worker. Il est décrit avec précision comme une protection de type best-effort locale à l'isolate, et non comme une limite de débit Cloudflare globalement autoritaire. Les lectures ordinaires sont bornées à 120 requêtes par minute par IP client déclarée ; l'ingestion dispose d'un compartiment séparé de six requêtes par minute et la géographie d'un compartiment séparé de douze requêtes par minute. Les écritures D1 ne sont pas ajoutées à chaque lecture uniquement pour surestimer ce contrôle.
POST /api/ingest — cycle de maintenance explicite piloté par la demande ; respecte les TTL, les backoffs et les baux D1.GET /api/observations?window=24h&scope=urlhaus&limit=100&cursor=... — fenêtre locale paginée de l'état actuel ; les périmètres validés sont all, urlhaus, malwarebazaar et infrastructure.GET /api/search?q=indicator&window=24h&scope=urlhaus&limit=100&cursor=... — recherche locale paginée et filtrée ; zéro appel en amont.GET /api/kev?limit=50&q=...&vendor=...&product=...&ransomware=known&addedSince=YYYY-MM-DD&cursor=... — catalogue CISA actuel complet.GET /api/events?limit=50&cursor=... — registre des événements matériels.GET /api/revisions?id=...&limit=50&cursor=... — enregistrement actuel plus révisions conservées.GET /api/correlations?id=... — pairs d'indicateurs exacts de l'état actuel au niveau de l'ensemble de données.Le développement Cloudflare local lit les identifiants réservés au serveur depuis .dev.vars. Copiez .dev.vars.example vers .dev.vars et renseignez uniquement les flux que vous êtes autorisé à utiliser :
THREATFOX_AUTH_KEY=
URLHAUS_AUTH_KEY=
MALWAREBAZAAR_AUTH_KEY=
Les identifiants de production doivent être stockés comme secrets Cloudflare Worker, jamais dans le code source validé ni dans des variables GitHub exposées au client. L'application n'y accède que via la surface de liaison du runtime Workers. Ils ne doivent jamais apparaître dans NEXT_PUBLIC_*, les composants client, le HTML, les journaux, les fixtures ou les fichiers validés.
Le dépôt cible directement les Cloudflare Workers standard. wrangler.jsonc est la source de vérité de la configuration Worker et déclare une liaison D1 provisoire nommée DB. Wrangler 4 provisionne automatiquement cette ressource D1 lors du premier déploiement authentifié et maintient la liaison lors des déploiements ultérieurs. Aucun identifiant D1 spécifique au compte n'est validé.
Commandes de développement et de production :
npm ci
npm run dev
npm run build
npm run preview
# authenticated Cloudflare session / CI only
npm run deploy
La vérification GitHub Actions s'exécute à chaque pull request et poussée vers main. Le déploiement de production est volontairement manuel via le workflow deploy production et requiert des secrets de dépôt nommés CLOUDFLARE_API_TOKEN et CLOUDFLARE_ACCOUNT_ID. Cela empêche une branche non revue ou une configuration d'identifiants incomplète de publier automatiquement.
npm ci
npm audit --omit=dev --audit-level=high
npm audit --audit-level=high
npm test
npm run lint
npm test est le point d'entrée de test pris en charge : il effectue une build de production complète avant la suite déterministe afin que l'isolation des secrets client au niveau des artefacts puisse inspecter dist/client. Exécuter node --test directement sur un checkout propre omet volontairement cet artefact de build requis. Les tests couvrent l'analyse syntaxique stricte des horodatages de calendrier et d'accusé de réception, le stockage d'appareil facultatif, les dépendances de corrélation stables, les preuves normalisées, le hachage canonique des étiquettes, la création d'événements matériels, la ré-ingestion inchangée, la préservation des charges utiles précédentes, la durabilité du dernier changement, les différences de champs, la conservation des événements et les lacunes du registre, les traces de preuves, la politique d'exportation des sources vides, l'intégrité de représentation/comptage STIX, l'éligibilité TTL/backoff, les baux d'actualisation, le câblage côté serveur du périmètre avant pagination, les requêtes dédiées GEO/KEV récent, la validation des curseurs, l'isolation du chemin de lecture, la couverture des sources, la politique de références externes, la précision de la limitation de débit, l'isolation des pannes de source et l'isolation des secrets client.
Le mode GEO trace uniquement les observations validées d'adresses IPv4/IPv6 publiques. Une requête D1 dédiée sélectionne les enregistrements IP éligibles dans la fenêtre d'état actuel demandée au lieu de réutiliser la page d'observations générique. La réponse rapporte les totaux d'enregistrements candidats et indique si sa limite de sécurité de 2 000 enregistrements a été atteinte. Les appelants ne peuvent pas fournir de destinations amont arbitraires ni de listes d'adresses IP. GeoJS est le fournisseur principal fixe et FreeIPAPI le repli fixe ; des URL amont arbitraires sont impossibles. L'application borne le travail externe via un plafond de 12 adresses par requête, un cache D1 de succès de 30 jours, un cache de nouvelle tentative de cinq minutes et un limiteur de route dédié. Chaque point tracé conserve sa provenance réelle de fournisseur et peut ouvrir son enregistrement local sous-jacent.
Publié sous la licence MIT. Voir LICENSE.
La sélection du mode GEO amène le serveur à envoyer chaque candidat d'adresse IP publique validé, avec les métadonnées de requête HTTPS ordinaires, à GeoJS puis à FreeIPAPI lorsqu'un repli est nécessaire. Ces fournisseurs peuvent donc observer quelles adresses publiques sont interrogées. Les adresses privées, réservées, de documentation et fournies par le client ne sont jamais envoyées ; le mode relation n'effectue aucune requête de géolocalisation.
L'espace de travail Replay reconstruit la page actuelle des transitions du registre matériel dans l'ordre du temps de détection de l'Observatoire. Les mouvements NEW, UPDATED et REMOVED sont pilotés exclusivement par les événements stockés. Il est explicitement borné à la page et ne prétend pas reconstruire un instantané historique complet ni un volume de trafic réseau.
Le paquet world-atlas dérivé de Natural Earth fournit le fond de carte local. La carte regroupe les adresses IP colocalisées, prend en charge les détails au survol et le clic vers la provenance, et rapporte les comptes géolocalisés, exclus, indisponibles et en attente. Les plages privées, réservées, de documentation, multicast et autrement non publiques sont exclues avant tout appel fournisseur.
La géolocalisation IP est explicitement présentée comme une localisation approximative d'infrastructure. Ce n'est ni une localisation d'acteur, ni une origine d'événement, ni une nationalité, ni une constatation de propriété, ni une revendication d'attribution. Un enrichissement échoué reste absent ; l'application ne génère jamais de coordonnées de substitution.
La visualisation par défaut reste un champ interactif dirigé par forces d'observations individuelles liées à leur source et à la famille de logiciels malveillants explicitement fournie. Le canevas prend en charge le déplacement des nœuds, le panoramique du champ, le zoom, le trafic de liens animé et l'inspection directe de la provenance. GEO est une surface de preuves distincte avec sa propre provenance et ses propres sémantiques d'échec.
| Source | Identifiant | TTL | Couverture réelle |
|---|
| CISA KEV | Aucun | 30 minutes | Catalogue complet validé et actuel |
| ThreatFox | THREATFOX_AUTH_KEY | 15 minutes | Fenêtre IOC de 24 heures demandée |
| URLhaus | URLHAUS_AUTH_KEY | 15 minutes | 500 derniers enregistrements renvoyés par le point de terminaison recent |
| MalwareBazaar | MALWAREBAZAAR_AUTH_KEY | 15 minutes | 100 derniers enregistrements de métadonnées renvoyés par le point de terminaison |
ingestion_runtime : la santé globale la plus récente du cycle d'ingestion.geo_ip_cache : résultats validés de géolocalisation approximative d'adresses IP et entrées bornées de cache négatif. Les résultats réussis expirent après 30 jours ; les recherches échouées sont retentées après cinq minutes. Les lignes D1 expirées sont supprimées de manière opportuniste lors des requêtes GEO, et le repli d'isolate est plafonné à 2 000 entrées.GET /api/geo?window=24h — ne dérive les candidats qu'à partir des observations locales validées d'adresses IP publiques, récupère au plus 12 résultats fournisseur non mis en cache par requête et renvoie des points WGS84 approximatifs mis en cache avec provenance.GET /api/status — sémantique de source, d'état actuel, de fraîcheur, de mode d'ingestion, de cycle, de bail et de limitation de débit.