Sécurité

Un audit dont la moitié du travail a consisté à nous contredire.

Auditer veut dire une chose simple : relire tout le code en cherchant à le casser, comme le ferait quelqu’un qui vous veut du mal. Nous l’avons fait sur l’ensemble du logiciel, en interne, avec une règle. Chaque faille supposée est confiée à une seconde analyse chargée de démontrer qu’elle n’existe pas. Ce qui résiste est corrigé, puis surveillé par un test automatique.

problèmes examinés

Repérés en relisant tout le logiciel : l’application, les relais du réseau, le serveur qui tient l’annuaire des relais, les appels.

fausses alertes écartées

Vérification faite, le danger décrit n’existait pas. Un audit qui n’écarte rien est un audit qui n’a pas cherché.

failles réelles confirmées

30 sont corrigées, chacune avec un test automatique qui rejoue l’attaque pour vérifier qu’elle échoue désormais. 12 restent ouvertes et sont écrites noir sur blanc, avec leur raison.

La méthode, étape par étape

Étape 1 : attaquer

Nous relisons tout le code en cherchant les failles. Chaque comportement douteux est noté, avec l’attaque qu’il rendrait possible.
Étape 2 : contredire

Chaque problème noté part ensuite à une seconde analyse, dont le travail est de démontrer qu’il est faux. 30 des 72 n’ont pas survécu à cette étape. C’est ce qui nous permet d’affirmer que les chiffres annoncés ici ne sont pas gonflés.
Étape 3 : corriger et rejouer

Sur les 42 failles confirmées, 30 sont corrigées. Chaque correctif vient avec un test qui rejoue l’attaque à chaque nouvelle version : si la faille revient un jour, la fabrication de la version s’arrête avant qu’elle n’atteigne votre appareil. Les 12 restantes sont documentées avec la raison pour laquelle elles ne sont pas encore corrigées. Parfois le correctif dépend de travaux plus larges, parfois le remède coûterait plus cher que le mal.

Posture par défaut

[profile.release]
panic = "abort"

Cette ligne de configuration ordonne au logiciel de s’arrêter net dès qu’il rencontre une situation qu’il ne sait pas traiter, plutôt que de continuer dans un état incertain. La conséquence est assumée : tout plantage qu’un tiers peut déclencher compte comme une faille à corriger, jamais comme un incident à ignorer.

Ces chiffres viennent d’un audit interne, mené par l’équipe qui écrit le logiciel et non par un cabinet extérieur indépendant. Ils ne valent donc pas certification. Ils restent vérifiables : les tests qui rejouent chaque attaque sont publiés dans le dépôt public, à côté du code qu’ils surveillent, et n’importe qui peut les lire ou les relancer. Nous ne revendiquons aucun label que nous ne détenons pas. Le jour où un organisme indépendant nous en délivre un, son nom et la date seront écrits ici.

Signaler une vulnérabilité

Si vous trouvez une faille, écrivez-nous en privé avant d’en parler publiquement. Nous corrigeons d’abord, puis la faille et son correctif sont publiés. C’est ce qu’on appelle la divulgation coordonnée. Vos messages sont lus par les ingénieurs qui écrivent le code, pas par un service client.

Contact sécurité

crypto.app.organisation@proton.me

Chiffrement du courriel (PGP) sur demande · une personne vous répond

Suivi public des correctifs