Projet stratégique de Haingo Core Logic

SATORI Engine, comprendre une application Laravel avant de la faire évoluer.

SATORI Engine est un moteur local d’aide à l’analyse des applications Laravel. Il aide à repérer des points à examiner et à organiser les résultats pour comprendre une application avant de décider comment la faire évoluer.

Des situations concrètes

Quand faut-il comprendre une application avant de la faire évoluer ?

Reprendre une application existante

Identifier ses points d’entrée et les vérifications disponibles avant de choisir une évolution.

Préparer une modification sensible

Repérer les parcours et les contrôles à examiner lorsqu’une évolution touche des accès, des actions ou des échanges de fichiers.

Comprendre un résultat de test

Distinguer un échec exploitable, un contrôle ignoré et un résultat qui ne permet pas encore de conclure.

Ces situations peuvent concerner les responsables d’une application comme les développeurs Laravel, les indépendants, les petites équipes et les partenaires techniques qui doivent en discuter.

Un outil possible dans un travail mené par Haingo Core Logic

Selon le contexte et le périmètre retenu, SATORI Engine peut soutenir un travail d’analyse mené par Haingo Core Logic. Il apporte des éléments techniques à examiner ; il ne définit ni la prestation, ni la décision à prendre.

Son utilisation n’est ni systématique ni promise à l’avance.

Un projet en développement

SATORI Engine est en développement actif. Les capacités présentées restent délimitées par leurs conditions d’utilisation et leurs limites ; il ne s’agit pas d’un produit finalisé.

Consulter l’état public, les jalons et les activités

État du projet

Statut
Actif
Phase
Développement
Focus actuel
Développer et qualifier les fondations d’une application contrôlée des changements, toujours soumise à une décision humaine.
Dernier jalon
Profils de preuve pour les changements contrôlés validés
Direction suivante
Poursuivre la qualification de ces fondations avant toute activation.
Mise à jour

Jalons validés

  1. Version stable 1.1.1 qualifiée

    La version stable 1.1.1 a été qualifiée avec ses limites et son registre de clôture.

  2. Répétabilité opérationnelle qualifiée

    Deux exécutions indépendantes ont produit des résultats fonctionnellement équivalents, avec des écarts expliqués.

  3. Cadre de changement contrôlé validé

    Le cadre contractuel permettant de préparer des changements sous décision humaine a été validé sans activer cette capacité.

  4. Profils de preuve pour les changements contrôlés validés

    Les règles de liaison, de provenance et de structure des preuves ont été validées, sans activation.

Preuves publiques

Aucune preuve publique n’est associée à cet état pour le moment.

Historique des activités

  1. Qualification des contrôles d’intégrité des preuves

    SATORI Engine a clôturé la qualification d’une étape de contrôle d’intégrité et de fraîcheur appliquée aux artefacts de preuve. La qualification a été démontrée sur un flux réel maintenu hors activation opérationnelle.

La méthode

Observer avant de modifier

Le principe est de distinguer ce qui est observé, ce qui en est déduit et ce qui doit être décidé. Les constats orientent la revue ; ils ne prennent pas la place du jugement humain.

Pour approfondir : le fonctionnement

Une copie de travail contrôlée, des résultats à examiner

Dans le modèle de préparation qualifié Prepare SAFE, une copie de travail est séparée de la source et des fichiers de résultats. La source n’est pas modifiée par défaut ; les écritures prévues se font dans les emplacements contrôlés du parcours.

Cette séparation n’est pas une sandbox du système d’exploitation et n’offre pas de garantie absolue contre toute modification de la source. Certains modes d’exécution ne passent pas par Prepare SAFE.

Le schéma suivant décrit un parcours conceptuel. Toutes les opérations optionnelles ne sont pas réalisées à chaque analyse.

Prepare SAFE → Engine → Evidence → Findings → Report

Prepare SAFE (Préparer) :

créer une copie de travail distincte dans le modèle de préparation prévu.

Engine (Examiner) :

exécuter les opérations retenues pour l’analyse.

Evidence (Conserver) :

produire les fichiers techniques qui décrivent les observations et les résultats.

Findings (Formuler des constats) :

relier les éléments disponibles aux points à examiner.

Report (Restituer) :

générer, lorsqu’elle est demandée, une restitution pour la revue humaine.

Le cockpit local

Le cockpit local permet de consulter les analyses, d’examiner les fichiers produits et d’effectuer certaines opérations contrôlées dans son périmètre actuel. L’ancienne action d’application directe des changements à la source n’est plus proposée par ce cockpit.

Ce qui peut être examiné

Des analyses ciblées, selon le contexte disponible

Cartographier les accès à l’application

Le moteur relève les routes Laravel enregistrées : leurs adresses, les méthodes HTTP, les actions associées, les paramètres et les mécanismes intermédiaires de traitement, appelés middleware.

Repérer des points à examiner en priorité

Les caractéristiques des routes et de leurs protections fournissent des signaux sur les accès publics, les zones d’administration, les actions d’écriture, l’authentification et les échanges de fichiers. Ces signaux orientent l’examen ; ils ne prouvent pas à eux seuls une vulnérabilité.

Exécuter certains contrôles applicatifs

Des scénarios ciblés peuvent concerner l’authentification, la limitation des requêtes, l’accès à des objets, l’envoi ou le téléchargement de fichiers et la protection contre les requêtes intersites non autorisées, dite CSRF. Leur exécution dépend des prérequis disponibles ; certains résultats peuvent être ignorés ou rester non concluants.

Relire les résultats des tests

Les résultats capturés distinguent notamment les échecs, les contrôles ignorés et les éléments utilisables pour examiner un constat ou préparer un retest.

S’appuyer sur les outils d’audit des dépendances

Lorsque les conditions du parcours le permettent, les outils d’audit de Composer ou de npm peuvent être utilisés. Il s’agit d’une assistance fondée sur ces outils, pas d’un scanner indépendant et exhaustif des dépendances.

Observer une surface HTTP limitée

Lorsqu’elle est activée, une exploration bornée relève des réponses HTTP, leurs codes de statut et leurs en-têtes. Elle ne constitue pas une exploration exhaustive de l’application.

Résultats et portée

Des fichiers techniques, pas automatiquement des preuves publiques

Selon les opérations réalisées, les fichiers produits peuvent décrire les routes, des signaux, des résultats de tests ou des constats. Ils peuvent être examinés indépendamment de l’interface. Un statut d’exécution terminé décrit le déroulement technique ; il ne signifie pas qu’aucun problème n’a été relevé.

Ces éléments de travail ne sont pas, par leur seule existence, des preuves publiques publiées par Haingo Core Logic. Aucune preuve publique n’est actuellement associée à l’état présenté ci-dessus.

Des appuis pour relire le développement

Le dépôt contient des suites de tests automatisés ainsi qu’une documentation technique et d’architecture. Leur présence ne signifie pas que tous les tests passent sur l’état courant. La documentation n’est ni exhaustive ni uniformément synchronisée avec l’implémentation.

Rejouer des contrôles et accompagner certaines corrections

Des retests ciblés

Les retests ciblés reprennent les fichiers de test liés à des échecs antérieurs, lorsque le contexte et les fichiers nécessaires sont disponibles. Un résultat peut rester incomplet ou non concluant ; ces retests ne couvrent pas toutes les régressions possibles et ne closent pas automatiquement les constats.

Des corrections sélectionnées et autorisées

Les parcours de remédiation sont limités à des cas pris en charge, notamment certains réglages de limitation des requêtes avec Fortify. Une sélection explicite et une autorisation précèdent l’application contrôlée dans la copie de travail.

Des tests peuvent ensuite être relancés automatiquement dans ce parcours autorisé ; l’acceptation du résultat reste humaine. SATORI Engine n’est pas un moteur général de réparation et ne corrige pas une application de manière autonome.

Ce que cette analyse ne garantit pas

SATORI Engine ne remplace pas un pentest complet. Il ne constitue ni une certification de sécurité, de qualité ou de conformité, ni un scanner de sécurité exhaustif. Il ne garantit pas l’absence de vulnérabilités.

Les résultats exigent une revue humaine. Les protections locales ne constituent pas non plus un dispositif complet de prévention des fuites de données.

Cette présentation n’ouvre pas un service autonome d’audit ou de correction à la commande.

Orientation du projet

Mieux expliquer les résultats, sans décider à votre place

L’orientation pédagogique vise à rendre plus lisibles le contexte d’un signal, les limites d’un résultat et les questions utiles à la revue humaine. L’élargissement des usages reste lié à la qualification des capacités concernées.

Une application Laravel ou un besoin technique à clarifier ?

Présentez à Haingo Core Logic le contexte de votre application, l’évolution envisagée et les points qui vous posent question. Le premier examen porte sur le besoin et son périmètre. Il ne vaut ni engagement de prise en charge, ni promesse d’utiliser SATORI Engine.

  • Documentation et transmission

    LÈSSE IN TRASSE

    Projet documentaire consacré aux affaires non élucidées et disparitions liées à La Réunion, avec une méthode de sourcing et de validation.

    Découvrir LÈSSE IN TRASSE
  • Jeux et expériences interactives

    UJEE

    Serious game 2D semi-interactif de sensibilisation aux contraintes quotidiennes liées au diabète de type 2 dans le monde professionnel.

    Découvrir UJEE
  • Jeux et expériences interactives

    Foot Cargo Prototype

    Prototype Unity 3D centré sur le portage à pied, le poids, l’équilibre et l’effort, dans une vision de survie logistique rurale.

    Découvrir Foot Cargo Prototype