Étude de cas
Lier une autorisation aux dépendances du code
Une autorisation signée peut rester valide sur le plan cryptographique alors que le programme qu’elle devait couvrir a changé. Le problème apparaît lorsqu’une dépendance du programme manque dans l’empreinte associée à l’autorisation.
Une étude interne réalisée le 15 octobre 2026 a éprouvé ce cas sur deux chemins d’acquisition : l’exécution primaire et la qualification. Le correctif consiste à inclure le lecteur de récupération dans l’identité du code autorisé, puis à vérifier le refus avant l’accès aux ressources d’acquisition.
Une identité du code incomplète
L’empreinte générale agrégeait les empreintes de plusieurs fichiers, mais omettait le module c2_recovery_reference.py. Une modification de ce lecteur pouvait donc laisser l’empreinte générale inchangée. Un contrôle propre à C2 couvrait déjà le lecteur; le défaut concernait la couverture de l’autorisation partagée. Il ne démontrait pas que tous les contrôles étaient absents.
Cette distinction détermine la correction. Il faut compléter l’inventaire des dépendances couvertes et éprouver les points d’entrée qui utilisent cette identité. Ajouter une vérification isolée, sans passer par ces points d’entrée, laisserait ouverte la question de son ordre réel d’exécution.
Six refus attendus et deux admissions légitimes
Les essais commencent par préparer un accord sur une copie minimale du code. Le lecteur est ensuite modifié de trois façons : ajout d’un commentaire, vidage du fichier ou suppression. Ces trois modifications sont appliquées aux deux chemins d’acquisition, soit six cas de refus attendus.
Des sentinelles remplacent les accès aux identifiants, au coffre, au budget et au transport. Si l’une est atteinte avec l’ancien accord, le test échoue. Cette méthode vérifie l’emplacement du refus dans le chemin d’exécution. Les données et signatures employées sont synthétiques.
Deux autres cas vérifient le comportement autorisé : après une modification du lecteur, un accord nouvellement signé sur les nouveaux octets doit franchir le contrôle initial. Ils évitent de considérer comme correct un programme qui refuserait systématiquement toute opération. Ces deux cas portent sur l’admission locale; ils ne réalisent pas une acquisition auprès d’un fournisseur.
| Groupe d’essais | Avant correction | Après correction |
|---|---|---|
| Ancien accord après ajout, vidage ou suppression | Les six cas atteignent à tort une sentinelle d’acquisition. | Les six cas s’arrêtent avant les sentinelles. |
| Accord frais après modification légitime | Les deux cas montrent que l’empreinte n’a pas changé. | L’empreinte change et les deux admissions locales réussissent. |
Un correctif ciblé
Le correctif ajoute le lecteur à la liste des fichiers couverts par candidate_digest. Après une modification des octets, l’ancien accord ne correspond plus à l’empreinte attendue. Si le fichier manque, sa lecture échoue avant les effets d’acquisition. Les huit cas ciblés réussissent après cette correction.
Le producteur a également exécuté une suite complète : 1 575 tests et 74 sous-tests réussis, avec un code de sortie nul. Un avertissement provenait d’une archive ZIP volontairement construite avec un doublon. La revue indépendante du correctif a conclu sans défaut bloquant. Son exécution générale comportait toutefois deux passages distincts, comme l’explique l’étude consacrée au harnais.
Ce que démontre ce contrôle
La preuve concerne l’omission corrigée, les deux chemins éprouvés et les modifications essayées. Elle ne certifie pas automatiquement l’exhaustivité de toutes les dépendances futures. Une évolution du code peut introduire un nouveau fichier dont l’identité doit, à son tour, être liée à l’accord.
Pour appliquer cette méthode à un autre système, il faut identifier les octets effectivement consommés, montrer qu’une modification significative invalide un accord existant, vérifier l’arrêt avant les effets sensibles, puis préserver l’admission d’un accord frais. Ces quatre vérifications établissent le lien entre identité du code, autorisation et ordre d’exécution.
Provenance de l’étude
Les résultats proviennent de la validation avant/après du 15 octobre 2026 et de sa revue indépendante. Le dossier interne conserve le code, les huit cas ciblés, les journaux et les rapports. Les résultats de tests synthétiques décrivent le comportement local éprouvé; ils ne constituent pas une preuve d’exécution chez un fournisseur.