Corrélations SMART — relier les pipelines
Le hub fait tourner ~15 pipelines indépendants (alertes, CVE matching, tracker noyau, honeypot, integrity, detection rules, capacity, mTLS, …). Chaque pipeline est utile en soi ; les jointures entre eux sont là où la valeur se compose.
Livré (mig 106 + mig 107)
1. Priorisation CVE basée sur blast-radius
GET /api/v1/topology/exposure?map_id=...
BFS récursif sur topology_edges depuis chaque nœud internet-facing
(node_type in {isp_uplink, cdn, load_balancer, waf} ou tag
public-facing). Par nœud : distance en sauts vers l’entrée
Internet la plus proche. /recommendations re-classe les CVE en
fonction.
GET /api/v1/topology/node-impact/:node_id → liste des contrôles de
conformité dépendant de ce nœud, avec comptages de preuves live.
2. Capacité comme CVE
CapacityPredictorWorker (cadence 1 h) ajuste une régression
linéaire (Postgres regr_slope + regr_intercept + regr_r2) sur
les 30 derniers jours de métriques disque par (agent, point de
montage) ; expirations de certs sous 60 j ; dates EOL sous 180 j.
Émet predicted_capacity_findings consommé par /recommendations
sous capacity.disk_full / cert_expiry / eol_date.
3. Détection de mouvement latéral
LateralMovementWorker (cadence 60 s) JOINt honeypot_events × auth_events pour un honeypot déclenché + connexion SSH réussie
depuis IP privée dans ±5 min. Émet detected_events rule_kind=lateral_movement_suspected (MITRE T1021 + T1078) avec le
lien complet entre les deux événements.
4. Alertes d’érosion de conformité
ComplianceErosionWorker (quotidien) snapshot le compte d’evidence
de chaque contrôle dans compliance_evidence_history. Quand un
contrôle perd >50 % de ses preuves vs snapshot d’il y a 7 jours,
une alerte est levée en category='compliance.erosion'. Attrape
les workers silencieusement arrêtés, les régressions de rotation de
clés, les suppressions accidentelles.
5. Rapport “owner of the week”
GET /api/v1/reports/owner-workload?window=7d
Agrège par topology_nodes.owner_email — alertes / CVE / détections /
findings capacité ouverts. Utile pour MSPs et team leads pour
repérer qui plonge. window accepte 24h | 7d | 30d | 90d.
6. Apprentissage des faux positifs
GET /api/v1/detection/rules/flake-stats
Par règle de détection : fires_30d, quick_ack_30d (acknowledged en <5 min), flake_rate. Quand le taux est >50 % et qu’il y a ≥10 fires, une suggestion d’opinion est renvoyée (ex : “augmenter threshold de 10 à 25”). Piloté par l’opérateur, pas d’auto-tuning.
7. Trust Score pondéré par centralité
CentralityRefreshWorker (toutes les heures) parcourt le graphe
topologique de chaque tenant et calcule la centralité par
intermédiarité (algorithme de Brandes). Mis en cache dans
topology_node_centrality. Le Trust Score tenant-aggregate pondère
le score de chaque agent par (1 + centralité), donc un nœud
chokepoint compte jusqu’à 2× un nœud feuille. La pression SPOF est
maintenant dans un seul chiffre.
8. AI Explain → actions liées
Colonne JSONB ai_explain_grounding.action_hints. Par ligne de
grounding, l’opérateur obtient des boutons un-clic dans la modal
explain — ouvre la vue dashboard pertinente, ou saute dans la
console d’urgence pré-remplie avec le bon EAT-kind. Les placeholders
{agent_id} sont substitués côté client. Exemples seedés :
- CVE (application) → Open recommendations · Open application CVE list
- Kernel-CVE → Open kernel-CVE pipeline · Schedule kernel update batch
- Détection PinTheft → Trigger pintheft_mitigate EAT
- Détection brute-force → IsolateNetwork EAT
- mTLS CN mismatch → Roter le token agent · Reissue cert
9. Diff Time-machine
GET /api/v1/time-machine/diff?agent_id=&from=&to=
Diff par paires entre les deux inventory_snapshots les plus proches
des horodatages from / to. Renvoie packages ajoutés / retirés /
upgraded, services ajoutés / retirés, deltas kernel / hostname / os.
Un appel = la timeline forensique “qu’est-ce qui a changé entre Lun
et Ven”.
Notes opérationnelles
| Worker | Cadence | Idempotent ? |
|---|---|---|
CapacityPredictorWorker | 1 h | oui — UPSERT sur (tenant, agent, kind, subject) |
LateralMovementWorker | 60 s | fenêtre dedup 24 h par (hp_agent, ssh_agent) |
ComplianceErosionWorker | 24 h | snapshot append-only ; alert dedup 7 j |
CentralityRefreshWorker | 1 h | overwrite complète par tenant |
Tous les workers cold-startent avec 2-5 min de délai pour que le hub finisse de booter avant la première requête lourde.