Architecture

Ogma est conçu comme une application de bureau locale, avec un backend Rust, un frontend Vue, une couche Electron, un stockage local des projets, un environnement d'exécution des plugins et une intégration MCP facultative.

Principaux composants

Composant	Emplacement	Responsabilité
Backend Rust du proxy et de l'API	crates/proxy	Proxy d'interception MITM, API REST, stockage, scanners, Rejeu, Automatisation, plugins, MCP, OAST et points d'accès de contrôle du navigateur.
Frontend Vue	frontend/src	Interface de l'espace de travail, stores, routes, éditeurs, scanners, iframes des plugins, espace de travail IA et utilitaires.
Couche Electron	desktop	Application de bureau distribuée, intégration des fenêtres du navigateur, passerelle de paramètres et cycle de vie de l'application.
Documentation	docs	Site de documentation VitePress.
Répertoire de données	ogma-data ou répertoire des données d'application de la plateforme	Base de données SQLite, éléments de l'autorité de certification, plugins, exports, sauvegardes et fichiers.

Backend

Le backend expose une API REST et un point d'écoute du proxy. Ses principaux modules sont les suivants :

• proxy_server.rs : interception et transmission du trafic HTTP.
• intercept.rs et intercept_rules.rs : file d'attente des interceptions et correspondance avec les règles.
• store.rs et store_actor.rs : accès à la base de données du projet et interface asynchrone de stockage.
• api.rs : routage de l'API et gestionnaires.
• replay.rs, automate.rs et workflows.rs : exécution reproductible des requêtes.
• passive_scanner.rs et active_scanner.rs : moteurs d'analyse.
• plugins.rs et plugin_runtime.rs : métadonnées des plugins, environnement d'exécution en bac à sable, permissions et événements.
• mcp.rs : ressources et outils MCP.
• ca.rs, tls_cert.rs, client_cert.rs : prise en charge des certificats et de TLS.
• ws_history.rs, ws_replay.rs et sse.rs : prise en charge du trafic en continu.
• oast.rs : services de rappel hors bande.

Frontend

Le frontend est une application Vue qui utilise le chargement différé au niveau des routes pour la plupart des vues de l'espace de travail.

Principales parties :

• router/index.ts : routes de l'espace de travail et des paramètres.
• components/NavSidebar.vue : navigation principale du produit.
• stores/* : stores Pinia pour l'historique, Rejeu, Automatisation, les constats, les workflows, les plugins, le périmètre, le shell, l'IA et les autres états.
• api/client.ts et api/types.ts : interface typée du client API.
• views/* : pages des fonctionnalités de l'espace de travail.
• components/WorkspacePanel.vue : panneau de l'espace de travail pour l'IA et les shells inversés.
• views/PluginsView.vue et views/PluginPageView.vue : installation et gestion des plugins, et hébergement des iframes frontend.

Couche Electron

La couche Electron prend en charge l'application de bureau distribuée et les fonctions de la passerelle native :

• Lancement et contrôle de la fenêtre de l'application.
• Enregistrement des paramètres de l'application de bureau dans le stockage local du frontend.
• Ouverture des fenêtres Ogma Browser et des vues de navigateur intégrées.
• Regroupement des ressources et des binaires pour la distribution de l'application de bureau.

Modèle de stockage

Ogma conserve localement les données des évaluations de sécurité. Les migrations du backend définissent des tables propres à chaque projet pour :

• L'historique HTTP et les corps des messages.
• Le trafic WebSocket et SSE.
• Les sessions et les tentatives de Rejeu.
• Les sessions, les exécutions et les résultats d'Automatisation.
• Les constats et les liens vers les éléments de preuve.
• Les workflows et leurs exécutions.
• Les préréglages de périmètre.
• Les plugins et leurs permissions.
• Les fichiers, les exports, les sauvegardes et les paramètres.

Environnement d'exécution des plugins

Les plugins peuvent inclure des composants backend, des composants frontend ou les deux.

Les plugins backend s'exécutent dans un bac à sable JavaScript et reçoivent un objet sdk. Les plugins frontend s'exécutent dans des iframes isolées et communiquent par une passerelle contrôlée par Ogma.

Limites importantes :

• Les plugins frontend ne peuvent pas accéder au DOM parent.
• Les commandes de la passerelle sont validées côté serveur.
• Les actions backend protégées nécessitent des permissions déclarées et accordées.
• Les paquets installés sont copiés dans le répertoire de plugins géré par Ogma pour assurer un comportement stable à l'exécution.

Voir le système de plugins.

Intégration MCP

Le serveur MCP expose le contexte du projet Ogma à des assistants externes. Il démarre par défaut en lecture seule. Les capacités d'écriture, d'export, d'envoi de requêtes, d'exécution de workflows et de contrôle des interceptions nécessitent des permissions explicites.

Voir la configuration MCP.

Principes de conception

• Priorité au fonctionnement local par défaut.
• Constats associés à des éléments de preuve.
• Définition du périmètre avant l'automatisation.
• Contrôles de permission explicites pour l'IA, les plugins, l'envoi de requêtes et les exports.
• Navigation rapide pour les tâches répétées des testeurs.
• Compatibilité avec les méthodes de travail établies des proxys, tout en maintenant l'extensibilité d'Ogma.