MS MarlinSpike Passive OT/ICS Topology Workbench
Famille de dépôts

Un dépôt suite, plusieurs dépôts de composants ciblés, et une frontière d'artefact propre.

MarlinSpike passe d'un dépôt unique mixte vers une famille de dépôts où le dépôt suite vendore une combinaison connue pour fonctionner d'atelier, de moteur, de plugins et de moteurs Rust.

repo-family.md CONTRIBUTING.md COMPATIBILITY.md
Dépôt suite

Le dépôt marlinspike de niveau supérieur est la surface d'intégration pour les équipes qui veulent un seul clone.

Composants faisant autorité

Le moteur, l'atelier, les plugins et les moteurs Rust ont chacun vocation à devenir faisant autorité dans leur propre dépôt.

Modèle subtree

Le dépôt suite utilise git subtree, pas les sous-modules, pour vendorer les dépôts de composants.

Modèle de dépôts

Dépôt Rôle
marlinspike Le dépôt suite, foyer d'intégration et option clone unique.
marlinspike-msengine Le dépôt du moteur d'analyse principal. Nom de package interne et CLI : msengine.
marlinspike-workbench L'interface web et la surface de collaboration qui lit les artefacts de rapport et peut optionnellement invoquer le moteur.
marlinspike-plugins Le monorepo de plugins Python pour les extensions consommatrices de rapports.
marlinspike-engines L'espace de travail de moteurs Rust pour les composants face aux paquets et fortement orientés événements.

Un seul clone pour tout

Le dépôt suite vendore les dépôts de composants via git subtree. Les docs le présentent comme un compromis pratique :

  • Les utilisateurs gardent un comportement normal de git clone.
  • Les équipes évitent la charge de configuration des sous-modules git.
  • Les dépôts de composants peuvent garder leurs propres cycles de version.
  • Le dépôt suite peut épingler une combinaison connue pour fonctionner pour les opérateurs qui veulent toute la stack ensemble.

Frontière de contrat

L'artefact de rapport portable est la frontière de passage entre les composants :

  1. msengine produit un artefact de rapport depuis le trafic capturé.
  2. marlinspike-workbench consomme cet artefact pour la revue, le triage et la collaboration.
  3. Les plugins Python consomment le même rapport fini et émettent des artefacts sidecar.
  4. Les moteurs Rust peuvent produire des artefacts en amont ou des flux d'événements qui alimentent le moteur ou d'autres composants.

L'atelier est intentionnellement utilisable même quand le rapport a été généré ailleurs et qu'aucun binaire de moteur local n'est présent.

État de transition actuel

Les docs reconnaissent honnêtement que le dépôt actuel contient encore le code du moteur et de l'atelier pendant que la scission se prépare.

  • Le dépôt racine marlinspike porte encore le code opérationnel du moteur et de l'interface Flask aujourd'hui.
  • Le premier préfixe subtree bootstrap est msengine/.
  • Jusqu'à la fin de la bascule, le _ms_engine.py racine reste la source opérationnelle du moteur.
  • Le script helper scripts/sync-msengine-bootstrap.sh copie en miroir le moteur opérationnel vers la copie subtree.

Limites de propriété pour les contributeurs

Les docs de contribution encouragent déjà les développeurs à penser en termes de futures frontières de composants, même avant que l'extraction soit terminée :

  • L'analyse face aux paquets, les observables et le travail CLI du moteur appartiennent à la frontière msengine.
  • Les routes Flask, les templates, l'auth, les projets et l'UX de revue de rapport appartiennent à la frontière workbench.
  • ATT&CK, IEC 62443, PERA et autres superpositions consommatrices de rapports appartiennent à la future frontière plugins.
  • Les parseurs Rust fortement orientés paquets appartiennent à la future frontière engines.

Besoin des contrats d'extension concrets derrière cette scission ?

Les docs d'extensibilité définissent comment les moteurs Rust, les plugins Python et les packs de règles YAML sont censés interagir avec l'artefact de rapport et entre eux.

Extensibilité Contribution