Les moteurs Rust, les plugins Python et les packs de règles YAML ont chacun un rôle différent.

Principes partagés

1. L'artefact de rapport MarlinSpike portable reste la principale frontière de passage entre l'analyse de paquets et la revue en aval.
2. Les extensions optionnelles doivent s'exécuter en mode headless et ne doivent pas nécessiter Flask, un navigateur ou une connexion base de données.
3. Les sorties lisibles par machine doivent être déterministes et versionnées.
4. Le code face aux paquets ne doit pas prendre de décisions de politique locale.
5. Le code face aux rapports ne doit pas parser directement des captures de paquets brutes.
6. YAML doit rester déclaratif.

Contrat des moteurs Rust

Les moteurs Rust sont propriétaires du travail face aux paquets et fortement orienté événements : lire les captures, parser les protocoles, normaliser les transactions et émettre des observations ou artefacts structurés.

Ils ne sont pas propriétaires du scoring final de topologie, du texte de constats orienté intervenant, du mapping ATT&CK, de la politique spécifique au site, ni du comportement de l'interface.

marlinspike-dpi --input <pcap> --capture-id <id> --output <json> --pretty

Le contrat d'invocation minimal est simple : accepter un chemin de capture en entrée, accepter un identifiant de capture stable, écrire la sortie JSON vers un chemin spécifié par l'appelant, et retourner non-zéro en cas d'échec.

Contrat des plugins Python

Les plugins Python consomment un rapport JSON MarlinSpike fini et émettent un artefact sidecar pour l'enrichissement, la corrélation, le mapping ATT&CK, le mapping IEC 62443, la correspondance malware ou tout autre post-traitement.

python -m marlinspike_plugin_name \
  --input-report <report.json> \
  --output <artifact.json>

Le plugin ne doit pas muter le rapport d'entrée en place. L'artefact sidecar fait autorité, tandis qu'un rapport fusionné peut exister comme copie de commodité.

{
  "artifact_type": "plugin_output",
  "plugin_id": "marlinspike-plugin-name",
  "plugin_version": "0.1.0",
  "contract_version": 1,
  "summary": {},
  "data": {},
  "warnings": []
}

Contrat des packs de règles YAML

Les packs de règles YAML sont la couche déclarative. Ils sont destinés aux mappings, surcharges locales, contrôles d'activation et de désactivation, et contenu de politique que les analystes peuvent avoir besoin d'ajuster sans réécrire du code pendant un engagement.

Les docs sont explicites sur ce que YAML ne doit pas devenir : un langage de programmation général, une surface de parser cachée, ou un endroit pour enfouir une logique arbitraire qui appartient à un plugin.

Règle de pouce pour le nouveau travail

• Si ça consomme du pcap brut, des flux de paquets ou des événements de protocole en grand volume, ça appartient probablement à un moteur Rust.
• Si ça consomme l'artefact de rapport MarlinSpike fini, ça appartient probablement à un plugin Python.
• Si les analystes doivent pouvoir l'ajuster sans modification de code, ça appartient probablement à un pack de règles YAML.