Enregistrer une provenance structurée des recherches OSINT #80

Closed
opened 2026-07-22 12:30:34 +02:00 by fy59 · 0 comments
Owner

Enregistrer une provenance structurée des recherches OSINT

Description :

Objectif

Conserver durablement chaque exécution OSINT et relier son résultat brut aux entités et relations intégrées dans l’enquête.

Cette évolution remplace la traçabilité minimale actuellement stockée dans les descriptions par une provenance structurée.

Migration SQLite

Créer une migration V3 ajoutant les tables nécessaires à la provenance OSINT.

Table des exécutions OSINT

Chaque exécution doit conserver au minimum :

  • un UUID ;
  • l’identifiant de l’outil ;
  • la version détectée ;
  • le type d’action OSINT ;
  • l’UUID de la sélection d’origine ;
  • le type de sélection ;
  • la valeur interrogée ;
  • les arguments transmis à l’outil ;
  • la date de début ;
  • la date de fin ;
  • le code de sortie ;
  • l’état final ;
  • la sortie standard brute ;
  • la sortie d’erreur brute ;
  • une empreinte SHA-256 de la sortie brute.

Liaisons avec les objets intégrés

Ajouter des tables de liaison entre une exécution OSINT et :

  • les entités créées ou réutilisées ;
  • les relations créées ou réutilisées.

Chaque liaison doit préciser si l’objet a été :

  • créé pendant l’intégration ;
  • réutilisé car déjà présent.

Cycle de vie

Une exécution DNS doit être enregistrée après la fin de dig, avant l’étape de révision.

L’intégration ultérieure doit compléter cette provenance en ajoutant les liaisons vers les objets sélectionnés.

Annuler la révision ne supprime pas l’exécution brute : la recherche a réellement eu lieu et doit rester traçable.

Interface

La fenêtre de résultat doit afficher :

  • l’identifiant de l’exécution enregistrée ;
  • la date d’exécution ;
  • l’outil et sa version ;
  • l’état de conservation de la sortie brute.

Après intégration, le message doit indiquer que les entités et relations sont liées à cette exécution.

Sécurité et intégrité

  • Les arguments sont enregistrés sous une représentation déterministe.
  • Les sorties sont stockées sans modification.
  • L’empreinte permet de vérifier leur intégrité.
  • Une exécution enregistrée ne doit pas être modifiée silencieusement.
  • Les clés étrangères doivent empêcher les liaisons orphelines.
  • Une migration échouée doit être entièrement annulée.
  • Les anciennes enquêtes V2 doivent être migrées sans perte.

Critères d’acceptation

  • Une migration V3 crée les tables de provenance OSINT.
  • Une enquête V2 est migrée automatiquement vers V3.
  • Une nouvelle enquête est directement compatible avec V3.
  • Chaque résolution DNS terminée crée une exécution OSINT.
  • Les sorties standard et d’erreur sont conservées intégralement.
  • Une empreinte SHA-256 est enregistrée.
  • L’outil, sa version, la cible et les arguments sont enregistrés.
  • Annuler la révision conserve l’exécution brute.
  • Les entités intégrées sont liées à l’exécution.
  • Les relations intégrées sont liées à l’exécution.
  • Les objets réutilisés sont distingués des objets créés.
  • Les écritures sont transactionnelles.
  • Les DAO et modèles possèdent des tests.
  • Les nouvelles fonctions publiques respectent les commentaires Doxygen.
  • Toute la suite de tests passe.
# Enregistrer une provenance structurée des recherches OSINT Description : ## Objectif Conserver durablement chaque exécution OSINT et relier son résultat brut aux entités et relations intégrées dans l’enquête. Cette évolution remplace la traçabilité minimale actuellement stockée dans les descriptions par une provenance structurée. ## Migration SQLite Créer une migration V3 ajoutant les tables nécessaires à la provenance OSINT. ### Table des exécutions OSINT Chaque exécution doit conserver au minimum : - un UUID ; - l’identifiant de l’outil ; - la version détectée ; - le type d’action OSINT ; - l’UUID de la sélection d’origine ; - le type de sélection ; - la valeur interrogée ; - les arguments transmis à l’outil ; - la date de début ; - la date de fin ; - le code de sortie ; - l’état final ; - la sortie standard brute ; - la sortie d’erreur brute ; - une empreinte SHA-256 de la sortie brute. ### Liaisons avec les objets intégrés Ajouter des tables de liaison entre une exécution OSINT et : - les entités créées ou réutilisées ; - les relations créées ou réutilisées. Chaque liaison doit préciser si l’objet a été : - créé pendant l’intégration ; - réutilisé car déjà présent. ## Cycle de vie Une exécution DNS doit être enregistrée après la fin de `dig`, avant l’étape de révision. L’intégration ultérieure doit compléter cette provenance en ajoutant les liaisons vers les objets sélectionnés. Annuler la révision ne supprime pas l’exécution brute : la recherche a réellement eu lieu et doit rester traçable. ## Interface La fenêtre de résultat doit afficher : - l’identifiant de l’exécution enregistrée ; - la date d’exécution ; - l’outil et sa version ; - l’état de conservation de la sortie brute. Après intégration, le message doit indiquer que les entités et relations sont liées à cette exécution. ## Sécurité et intégrité - Les arguments sont enregistrés sous une représentation déterministe. - Les sorties sont stockées sans modification. - L’empreinte permet de vérifier leur intégrité. - Une exécution enregistrée ne doit pas être modifiée silencieusement. - Les clés étrangères doivent empêcher les liaisons orphelines. - Une migration échouée doit être entièrement annulée. - Les anciennes enquêtes V2 doivent être migrées sans perte. ## Critères d’acceptation - [x] Une migration V3 crée les tables de provenance OSINT. - [x] Une enquête V2 est migrée automatiquement vers V3. - [x] Une nouvelle enquête est directement compatible avec V3. - [x] Chaque résolution DNS terminée crée une exécution OSINT. - [x] Les sorties standard et d’erreur sont conservées intégralement. - [x] Une empreinte SHA-256 est enregistrée. - [x] L’outil, sa version, la cible et les arguments sont enregistrés. - [x] Annuler la révision conserve l’exécution brute. - [x] Les entités intégrées sont liées à l’exécution. - [x] Les relations intégrées sont liées à l’exécution. - [x] Les objets réutilisés sont distingués des objets créés. - [x] Les écritures sont transactionnelles. - [x] Les DAO et modèles possèdent des tests. - [x] Les nouvelles fonctions publiques respectent les commentaires Doxygen. - [x] Toute la suite de tests passe.
fy59 closed this issue 2026-07-22 12:30:58 +02:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#80
No description provided.