EN

PILOTE

Apportez un module traduit. On vous dit s’il fait encore la même chose, ou on vous montre exactement où il diffère.

Votre intégrateur ou votre outil d’IA a traduit un programme. Vous nous envoyez l’original et la traduction. Chaque module revient avec l’une des trois réponses, et chaque écart se rejoue sur votre propre compilateur. On s’entend avec vous sur l’échéancier une fois qu’on a le code et le périmètre. Les actions critiques ont leur propre pilote, juste en dessous.

TROIS PILOTES, UNE MÉTHODE

Chaque pilote se termine par un dossier de vérification que votre équipe peut revérifier.

  1. PILOTE D’ENTRÉE

    Vérification de code

    La traduction que vous avez reçue fait-elle encore ce que faisait l’original ?

    VOUS RECEVEZ

    • D’abord, un rapport d’audit de traçabilité : ce que disent les documents de la traduction, comparé au code.
    • Ensuite, par module, l’entrée précise où il diffère, ou impossible à trancher, avec la raison. Les réponses « même comportement » sont suspendues pendant qu’on les reconstruit.
    • Chaque écart, avec de quoi le rejouer sur votre compilateur et sur le nouveau code.
    • Le périmètre, et les hypothèses sur le compilateur et CICS dont dépend chaque réponse.

    RÉUSSI SI

    Chaque module a l’une des trois réponses, chaque écart se rejoue chez vous, et ce qui n’a pas été couvert est écrit.

    LES LIMITES, PAR ÉCRIT

    Les réponses tiennent contre notre modèle du programme d’origine, pas contre tout compilateur ou toute configuration CICS. Pas encore de rejeu par un tiers.

  2. PILOTE · ACTIONS CRITIQUES

    Autorisation vérifiable

    Cette action critique respecte-t-elle vos règles, chaque fois qu’elle est demandée ?

    VOUS RECEVEZ

    • Votre règle écrite en logique, avec les lectures que nous avons choisies.
    • Un résultat par propriété : prouvée, réfutée avec la séquence exacte qui la brise, ou non démontrée avec la raison.
    • La barrière devant l’action, et une trace scellée de chaque décision.

    RÉUSSI SI

    Votre équipe de risque recalcule les décisions à partir des traces scellées sur sa propre machine, et chaque faille trouvée par le solveur est corrigée ou acceptée par écrit.

    LES LIMITES, PAR ÉCRIT

    Vaut là où l’action ne peut s’exécuter qu’à travers la barrière, dans le modèle et les bornes que le dossier énonce.

  3. PILOTE · CORRECTIFS DE SÉCURITÉ (C)

    Vérification de correctifs (C)

    Chaque correctif supprime-t-il l’échec que cause sa faille ?

    VOUS RECEVEZ

    • Par correctif : le harnais de test, les bornes, et un résultat (fermé, test trompé ou non analysé) avec la raison.
    • Les faux correctifs que le test devait rejeter, et les commandes pour tout rejouer.

    RÉUSSI SI

    Chaque correctif a l’un des trois résultats, et rien n’est déclaré fermé si le test n’a pas aussi rejeté les leurres.

    LES LIMITES, PAR ÉCRIT

    Une vérification bornée de l’échec que notre test met en évidence, pas de tous les chemins d’un attaquant. Notre juge des verdicts C est en reconstruction ; les résultats sont présentés comme des vérifications bornées, pas comme des preuves complètes.

COMMENT SE DÉROULE LE PILOTE D’AUTORISATION

  1. 01

    Choisir l’action

    Un type d’action que vos agents ou scripts exécutent déjà — un transfert, un accès, une suppression, un déploiement — et les règles qui l’encadrent aujourd’hui.

  2. 02

    Prouver la politique

    Nous encodons les règles, cherchons les séquences qui passent chaque règle mais trahissent l’intention, et prouvons que la politique corrigée tient.

  3. 03

    Appliquer et sceller

    La barrière tourne dans votre environnement, devant l’action. Chaque décision, autorisée ou bloquée, est scellée.

  4. 04

    Vérifier sans nous

    Votre équipe de risque ou votre auditeur revérifie le certificat et les traces sur sa propre machine.

Ce que vous apportez

  • Le type d’action, et où il s’exécute aujourd’hui.
  • La règle telle qu’elle est écrite : limites, approbations, fenêtres, gels.
  • Une personne responsable de cette règle, qui peut dire ce qu’elle voulait dire.
  • Un endroit dans votre environnement où la barrière peut se placer devant l’action.

Ce que vous gardez

  • La barrière, devant cette action.
  • Une trace scellée de chaque décision, comme le dossier de vérification.
  • Ce que le solveur a trouvé dans votre règle, y compris ses fuites, comme le montre le labo.
  • Les lectures choisies pour votre règle, et les limites de ce qui a été prouvé, par écrit.

CE QU’UN PILOTE NE VOUS DIRA PAS

Quatre choses, dites avant que vous les demandiez.

  1. 1

    Si l’ancien programme avait raison.

    On vérifie que le nouveau code fait ce que faisait l’ancien, bizarreries comprises. Savoir si l’ancien comportement était le bon, ça reste à vous de le juger.

  2. 2

    Si votre règle est la bonne.

    Il montre exactement ce que votre règle permet, y compris ce que personne ne voulait permettre. Le choix de la règle vous appartient.

  3. 3

    Quoi que ce soit sur les actions qui contournent la barrière.

    La preuve tient là où l’action ne peut s’exécuter qu’à travers la barrière. Le certificat énonce cette frontière.

  4. 4

    Si ce que l’appelant déclare est vrai.

    Une fenêtre ou une population déclarée est scellée avec le verdict, pas vérifiée contre vos systèmes. Un mensonge cohérent est au dossier, pas empêché.

UN BON CANDIDAT SI

  • Un programme a été traduit, ou est en train de l’être, par un intégrateur ou un outil d’IA
  • Ou un agent, une API ou un script peut déjà exécuter une action critique sans qu’une personne clique sur approuver
  • Quelqu’un devra montrer que le nouveau code, ou les règles, ont réellement tenu

Dites-nous quel module, ou quelle action.

RÉSERVER UN APPEL

Ou laissez un courriel professionnel, on vous écrit.