Audits

Cette page est le registre de référence des examens de sécurité menés par des tiers sur les composants d’Intention. Elle indique ce qui a été audité, ce qui est en cours d’examen, et — tout aussi important — ce qui ne l’a pas encore été.

​

Statut actuel

Le bridge inter-chaînes est le composant soumis à un examen de sécurité par un tiers. Le périmètre couvre les contrats sur la chaîne externe et l’infrastructure de signature qui les sous-tend : la conservation des actifs, la vérification des signatures, le chemin de retrait en deux phases et sa période de contestation, et la propagation de l’ensemble des validateurs de part et d’autre de la frontière entre chaînes. La priorité donnée au bridge est délibérée. C’est le seul composant dont le modèle de sécurité n’est pas celui du réseau — la moitié tourne sur une autre chaîne, avec ses propres validateurs et ses propres modes de défaillance, et c’est là qu’une compromission se traduit le plus directement par une perte de fonds. Le reste du protocole est vérifiable en rejouant des blocs ; un contrat de bridge sur une chaîne externe, non. L’auditeur et le rapport seront publiés ici à l’issue de l’examen, avec le périmètre et les conclusions.

​

Comment lire un rapport à sa publication

Un audit utile répond à trois questions : quel était le périmètre, qu’ont réellement examiné les relecteurs, et qu’est-ce qui reste ouvert à la publication. Chaque rapport publié ici rendra les trois explicites.

• Le périmètre est un hash de commit accompagné d’une liste énumérée de composants. Un fichier ou un contrat qui n’y figure pas n’a pas été audité.
• Les conclusions sont classées par gravité. Celles dont le risque est accepté sont accompagnées de leur justification et des contrôles d’atténuation éventuels, plutôt que d’être omises.
• Les écarts depuis l’audit sont suivis séparément. Tout changement postérieur à l’audit qui touche du code audité est signalé, afin que vous puissiez savoir si le rapport publié décrit encore le système en fonctionnement.

C’est ce dernier point qui manque le plus souvent ailleurs. Un audit décrit un commit précis. Le code qui a bougé depuis est du code que personne n’a relu, et un rapport qui ne le dit pas surestime ce qu’il couvre.

​

Contrôle continu

Les audits ponctuels viennent s’ajouter à des contrôles permanents :

• Des relectures obligatoires sur chaque changement du noyau, du consensus et du bridge.
• Du fuzzing et des tests fondés sur les propriétés contre les machines à états d’appariement, de risque et de règlement, y compris des contrôles de déterminisme qui rejouent des blocs entérinés et comparent les résultats octet pour octet.
• Des tests différentiels entre des builds indépendants du moteur — une divergence est traitée comme un bug de consensus, pas comme un échec de test.
• Un programme de bug bounty public pour une couverture externe continue.

​

Pour aller plus loin