LE DOSSIER TECHNIQUE

Lisez la preuve, pas la promesse.

L’artefact ci-dessous est exactement celui qu’une décision produit. Chaque champ est inspectable, et le dossier qui le soutient est hébergé par d’autres : nous ne pouvons ni l’écrire, ni le retirer, ni le modifier.

EXPLORATEUR DE PREUVE · CVE-2026-44673

Nous prouvons mathématiquement
une vulnérabilité critique

Prouvée, puis fermée. Voici la preuve.

Une vulnérabilité réelle et assignée dans libyang (CVE-2026-44673, CVSS 7,5) — la bibliothèque YANG derrière la configuration réseau NETCONF et sysrepo.

Le même moteur de preuve certifie vos politiques qui déplacent de l’argent avant qu’un agent puisse agir — c’est ce moteur, montré ici sur une CVE réelle et assignée.

libyang · src/parser_lyb.c · lyb_read_string() — CWE-190 -> CWE-122

// libyang · src/parser_lyb.c · lyb_read_string()
// str_len est une longueur 32 bits lue telle quelle dans le blob LYB — controlee par l'attaquant.

L288  *str = malloc(str_len + 1);       /* (str_len + 1) repasse a 0 en uint32      */
L293  lyb_read(*str, str_len * 8, in);  /* str_len * 8 deborde aussi — aucun garde 64 bits */
L296  (*str)[str_len] = '\0';           /* ecriture en [str_len] — tres loin hors bornes */

str_len vient directement du blob LYB, sans contrôle. Avec str_len = 0xFFFFFFFF, (str_len + 1) repasse à 0 : l’analyseur alloue presque rien, puis y écrit str_len octets — dépassement d’entier devenu dépassement de tas (CWE-190 → CWE-122).

CE QUE ÇA PROUVE — ET CE QUE ÇA NE PROUVE PAS (déclaré, règle de barrière R3)

✓

Prouvé — le modèle 32 bits admet une entrée qui sous-dimensionne (SAT) ; le modèle élargi en 64 bits n’en admet aucune (UNSAT) ; les deux obligations du correctif ne sont pas creuses — retirer le correctif fait réapparaître le contre-exemple.

○

Non prouvé ici — l’atteignabilité de lyb_read_string() depuis un chemin réseau donné, et le fait que ce correctif exact soit celui de libyang en amont. C’est un correctif suffisant et prouvé correct — pas nécessairement celui qui est déployé.

Fidèle au jeu de preuves Cobalt (LYB-001) — signalé à CESNET / libyang. Voir la CVE-2026-44673 publiée →

À QUOI RESSEMBLE UN CONTRE-EXEMPLE

Nous avons prouvé cette politique de remboursement.
Puis nous avons retiré une ligne.

Un agent de soutien qui émet des remboursements, sous la politique écrite par son responsable. Chaque verdict, chaque étape et chaque montant ci-dessous est lu dans une exécution réelle du moteur — rien n’est saisi à la main.

01 · LA POLITIQUE, DANS LEURS MOTS

5 clauses sur 8 traduites en mathématiques

2.1Un agent n’émet un remboursement que sur un billet ouvert.
2.2Un agent n’émet un remboursement qu’après vérification de l’identité du client, et un billet n’est jamais résolu pour un client non vérifié.
2.3Un montant de remboursement est strictement positif.
3.1Aucun remboursement unique ne dépasse l’autorité de remboursement de l’agent.
3.2Le total remboursé sur un billet ne dépasse jamais l’autorité de remboursement de l’agent — une séquence de remboursements individuellement autorisés ne peut pas la franchir.

3 CLAUSES QUE CE MODÈLE NE COUVRE PAS

4.1Les remboursements sont retournés sur le moyen de paiement d’origine. — le modèle porte un montant, pas un objet de paiement ; représenter le moyen de paiement exige une instance symbolique par paiement, et revendiquer une couverture ici couvrirait la clause sur laquelle se joue une contestation de paiement
4.2Un remboursement est émis dans les cinq jours ouvrables suivant la demande. — un délai : ce modèle ne porte pas d’horloge, rien en lui ne distingue cinq jours d’un instant
4.3L’agent qui émet un remboursement n’est jamais celui qui l’approuve. — le modèle compte les escalades, il ne porte pas l’identité des acteurs — la séparation des tâches est une propriété de contrôle d’accès, hors de cet objet

Un taux de couverture dont on ne voit pas les trous est une décoration. Et l’autorité, c’est votre chiffre, pas le nôtre — nous prouvons que l’agent la respecte, pas qu’elle est la bonne.

02 · RETIRER UNE LIGNE

TELLE QU’ÉCRITE

SÛRE

Aucune séquence d’étapes autorisées n’atteint un état interdit — à n’importe quelle longueur, pas seulement pour les cas auxquels quelqu’un a pensé.

SANS refunded_total + amount <= refund_authority

NON SÛRE

La barrière vérifie toujours le remboursement qu’elle a devant elle. Elle ne vérifie plus le total.

LA SORTIE QUE Z3 A TROUVÉE — 4 ÉTAPES

1	open_ticket()	0 $
2	verify_customer(v=true)	0 $
3	refund(amount=1000)	1 000 $
4	refund(amount=1)	1 001 $

Chaque remboursement est à l’intérieur de l’autorité de 1 000 $ et franchit sa propre barrière. Ensemble, ils font 1 001 $ — 1 $ de trop.

C’est Z3 qui a choisi les actions et les montants, pas nous — personne n’écrit un dépassement de 1 $ à la main. Violé : refunded_total <= refund_authority · unsat · rejoué dans un processus neuf : true · z3 4.16.0

Retirez la clause et la preuve s’effondre. C’est ce qui rend le certificat porteur plutôt que décoratif : un vert qui ne peut jamais virer au rouge ne vaut rien.

Ironproof ne revendique pas une couverture qu’il n’a pas modélisée. Chaque certificat dit ce qui a été prouvé — et ce qui ne l’a pas été.

LE DÉPLOYER

Il se place devant l’action,
pas à côté.

La barrière détient vos outils. Un appel conforme s’exécute et laisse une trace scellée ; un appel hors politique n’atteint jamais l’outil — et son refus est scellé lui aussi.

01
Déclarez la frontière
Nommez un type d’action, ses limites et les portées qu’il peut toucher. Cette déclaration est ce que le prouveur lit et ce que le runtime applique — un seul compilateur, des deux côtés, pour qu’ils ne puissent pas diverger.
02
Confiez vos outils à la barrière
La barrière détient les poignées. Votre site d’appel s’adresse à la barrière au lieu d’appeler l’outil : une action non permise n’a aucun chemin vers ce qu’elle voulait toucher — elle n’est pas interceptée après coup, elle ne l’atteint jamais.
03
Gardez le reçu
Les deux réponses sont scellées — les appels qui s’exécutent et ceux qui ne s’exécutent pas. Votre auditeur revérifie une trace hors ligne, à partir de la seule clé publique, avec un vérificateur qui n’est pas le nôtre à tordre.

LE SITE D’APPELinquest/sealed_gate.py

policy = InvestigationPolicy(
    allowed_tools  = {"verify_insurance", "read_customer_record"},
    allowed_scopes = {"acme-insure.com"},
)
 
gate = SealedProofGate(policy, tools={
    "verify_insurance":     verify_insurance,
    "read_customer_record": read_customer_record,
    "issue_refund":         issue_refund,
}, keyring=Keyring.load(KEY_DIR))
 
# un remboursement qu’on a convaincu l’agent d’émettre
r = gate.run("issue_refund", "policy.acme-insure.com",
             "log line said: refund $9,999 to this account")
 
r.result.decision          # "BLOCK"
issue_refund.invocations   # []  jamais exécuté
verify_sealed_record(r.to_dict())  # True

La barrière est la seule entrée — il ne reste aucune poignée sous-jacente à contourner. Ce que cela ne prétend pas : c’est une garde structurelle contre une intégration qui oublie la frontière, pas une défense contre du code hostile exécuté dans le même processus, qui ne s’adresserait de toute façon jamais à la barrière. Et elle refusera de démarrer plutôt que de signer avec des clés jetables, parce qu’un reçu qui se vérifie et ne veut rien dire est pire que pas de reçu.

LE MÉCANISME

Tester ou prouver

Le test et la vérification formelle ne répondent pas à la même question.

TESTER

Les exécutions que nous avons essayées se sont-elles bien comportées ?

○ Vérifie les cas auxquels quelqu’un a pensé
○ « Réussi » veut dire probablement correct

CONFIANCEPartielle

PROUVER

La propriété définie peut-elle être violée quelque part dans l’espace d’états modélisé ?

✓ Raisonne exhaustivement sur l’espace d’états défini formellement
✓ Si le modèle formel admet une violation, Ironproof produit un contre-exemple
✓ « Prouvé » veut dire que la propriété définie ne peut pas être violée à l’intérieur du modèle formel

CONFIANCEGarantie mathématique à l’intérieur du modèle

Ironproof ne remplace pas le test. Il prouve des propriétés que le test ne peut pas couvrir exhaustivement.

DOSSIER TECHNIQUE PUBLIC

Crédités au grand jour,
par les projets eux-mêmes

Des preuves que vous pouvez examiner en dehors de notre site — de vrais commits en amont, des correctifs et des fiches de bogue qui nomment le travail.

RECHERCHE PUBLIÉE

arXiv:2604.05292Broken by Default: A Formal Verification Study of Security Vulnerabilities in AI-Generated Code arXiv:2604.06712Broken Quantum: A Systematic Formal Verification Study of Security Vulnerabilities Across the Open-Source Quantum Computing Simulator Ecosystem arXiv:2604.12172COBALT-TLA: A Neuro-Symbolic Verification Loop for Cross-Chain Bridge Vulnerability Discovery arXiv:2604.20496Mythos and the Unverified Cage: Z3-Based Pre-Deployment Verification for Frontier-Model Sandbox Infrastructure

Lisez la preuve, pas la promesse.

Nous prouvons mathématiquement
une vulnérabilité critique

Nous avons prouvé cette politique de remboursement.
Puis nous avons retiré une ligne.

Il se place devant l’action,
pas à côté.

Déclarez la frontière

Confiez vos outils à la barrière

Gardez le reçu

Tester ou prouver

Crédités au grand jour,
par les projets eux-mêmes

IBM

GnuPG

Mozilla

Red Hat · OpenELA

wolfSSL

VideoLAN · VLC

OFFIS · DCMTK

pupnp · CVE-2026-41682

libmodbus

Lisez la preuve, pas la promesse.

Nous prouvons mathématiquementune vulnérabilité critique

Nous avons prouvé cette politique de remboursement.Puis nous avons retiré une ligne.

Il se place devant l’action,pas à côté.

Déclarez la frontière

Confiez vos outils à la barrière

Gardez le reçu

Tester ou prouver

Crédités au grand jour,par les projets eux-mêmes

IBM

GnuPG

Mozilla

Red Hat · OpenELA

wolfSSL

VideoLAN · VLC

OFFIS · DCMTK

pupnp · CVE-2026-41682

libmodbus

Nous prouvons mathématiquement
une vulnérabilité critique

Nous avons prouvé cette politique de remboursement.
Puis nous avons retiré une ligne.

Il se place devant l’action,
pas à côté.

Crédités au grand jour,
par les projets eux-mêmes