Un SOC qui se souvient.
Warlog transforme les alertes en actions approuvées. Le contexte reste attaché. Le jugement reste humain. La preuve reste signée. La mémoire se capitalise en privé.
Les signaux atterrissent dans un seul modèle.
Les décisions passées remontent avant l'action.
Un écran. Des arbitrages clairs.
Le cas suivant démarre en avance.
Moins de dérive. Moins de risque. Plus de mémoire.
La détection ne suffit pas.
La stack voit l'événement. La mauvaise action reste à un clic.
crm-sync appelle Graph depuis un ASN inconnu.crm-sync fait tourner la facturation de fin de mois. Coupez-le, et le revenu s'arrête.Votre analyste connaissait l'exception. Le système, non. Les champs manquants sont simples : propriétaire du service, dépendance, rollback, approbateur.
Automatisation rapide. Contexte mince.
Ça sonne juste. Ça agit quand même à l'aveugle.
Pour l'analyste, l'écart c'est le contexte. Pour le DevSecOps, c'est la gestion du changement. Dans les deux cas, la vitesse sans conscience du service transforme une alerte en panne.
Des outils partout. De la mémoire nulle part.
La détection vit à un endroit. Les décisions meurent ailleurs.
Sans mémoire, l'automatisation répète les vieilles erreurs.
Chaque décision approuvée rend la suivante plus sûre.
Warlog corrèle les signaux, rappelle la dernière exception validée, adapte la réponse au service à risque, et garde l'approbation explicite.
crm-sync depuis un ASN inconnucrm-sync.
La mémoire approuvée rend la réponse adaptative.
Warlog ne se contente pas de stocker le cas. Il réutilise les décisions validées, garde l'exécution bornée, et s'affûte à mesure que des incidents similaires reviennent.
Ce qu'on publie. Ce qu'on déploie.
Deux choses. Nettement séparées. Le contrat est ouvert. Le runtime est auto-hébergé.
warlog-spec
Le contrat ouvert. Apache 2.0.
Warlog OS
Le runtime auto-hébergé. Dans votre périmètre.
Le problème, ce ne sont pas les standards manquants. C'est qu'ils s'arrêtent aux frontières des outils. Warlog les relie.
from warlog_spec import ( AlertCanonical, # enregistrement d'alerte partagé ResponseActionSpec, # contrat d'action revu Outbox, # couche de livraison sûre AuditChain, # piste de preuve signée Connector, # frontière d'intégration outil )
pip install warlog-spec
·
Schémas ouverts. Un seul enregistrement opérationnel.
·
n'importe quel langage, la même piste de preuve
Pas de SaaS partagé. Pas de télémétrie mutualisée.
Gardez votre SIEM, vos modèles et votre intel.
Données, clés et workflows cantonnés à votre organisation.
Seule votre équipe voit les motifs qu'elle crée.
Réponses claires.
Warlog est-il auto-hébergé ?
Warlog est-il open source ?
Warlog prend-il des actions autonomes ou destructrices ?
Avec quels outils Warlog fonctionne-t-il ?
En quoi est-ce différent d’un SOAR ou d’un SOC autonome ?
Comment démarrer avec Warlog ?
Trois équipes. Une fenêtre.
On déploie dans votre environnement. Vous façonnez le produit. Les design partners gardent leur tarif à vie.
SOC internes, MSSP et équipes auto-hébergées avec un responsable sécurité et un responsable plateforme.
Si vous voulez un essai SaaS de 15 minutes ou des actions destructrices sans approbation, ce n'est pas le produit.
Déploiement mené par le fondateur, trois intégrations en prod, socle tenant-safe, influence sur la roadmap, tarif préférentiel à vie.
Un prépaiement de 12 mois, deux responsables qui peuvent décider et agir, l'accès aux endpoints pendant la mise en place, et la vérité quand quelque chose casse.
Tôt. Réel.
Rejoignez maintenant pour le levier. Attendez pour le vernis.
Demandez un appel.
Appel de fit de 30 minutes. Décision en 7 jours. Puis on ferme.
Le modèle est ouvert.
Utilisez warlog-spec dans n'importe quel langage, n'importe quel runtime, le même contrat.