Un mot de passe vendu 15 000 reais : ce que l'attaque contre Pix apprend aux ingénieurs QA

Entre la nuit du 30 juin et le 1er juillet 2025, pendant que presque tout le Brésil dormait, des centaines de millions de reais ont quitté les comptes que les institutions financières détiennent auprès de la Banque centrale du pays. L'argent a été transféré via Pix, le système de paiement instantané brésilien, puis dispersé sur des plateformes de cryptomonnaies en quelques heures.

Il n'y a pas eu de scène de piratage digne d'un film, personne n'a cassé de chiffrement devant un écran vert. Selon l'entreprise attaquée elle-même, les criminels ont utilisé des identifiants légitimes. Pour le système, ces virements étaient des demandes valides, faites par quelqu'un qui avait le droit de les faire.

Ce détail change tout pour ceux qui travaillent dans la qualité logicielle. Si l'on avait exécuté la suite de tests de ce système le lendemain matin, elle serait probablement passée. La connexion fonctionnait, les transactions étaient traitées, les messages arrivaient à destination. Le système a fait exactement ce pour quoi il avait été construit. Le problème, c'est que personne n'avait insisté suffisamment sur une autre question : qu'est-ce qu'il aurait dû refuser de faire ?

Ce qui s'est passé, selon les sources

L'entreprise au cœur de l'affaire est C&M Software, qui assure le lien technologique entre de petites institutions financières et le Système de paiements brésilien, y compris l'environnement de règlement de Pix. Lorsqu'une fintech ne dispose pas de connexion directe à cette infrastructure, elle peut faire appel à une entreprise comme C&M.

Les faits ci-dessous proviennent d'articles publiés à l'époque et dans les mois qui ont suivi, cités dans les références à la fin :

• C&M a indiqué que l'accès avait eu lieu par une intégration frauduleuse, avec les identifiants légitimes d'un client. L'entreprise a affirmé que les fonds des titulaires de comptes et les données des clients n'avaient pas été touchés.
• La cible était les comptes de réserve que les institutions détiennent auprès de la Banque centrale pour le règlement interbancaire. La Banque centrale a ordonné la coupure de l'accès des institutions à l'infrastructure exploitée par C&M.
• Six clients de C&M ont été touchés. À lui seul, l'un d'eux, BMP, s'est vu détourner plus de 500 millions de reais. Des articles ultérieurs estiment le total à environ 800 millions de reais.
• Le 3 juillet, la police civile de São Paulo a arrêté un employé du service informatique de C&M. Selon la police, il avait été abordé à la sortie d'un bar et avait vendu son accès pour 15 000 reais, versés en deux fois. Le commissaire chargé de l'enquête a décrit les identifiants remis comme « la première porte » qui a permis au groupe d'entrer.
• Quelques jours plus tard, la Banque centrale a autorisé C&M à reprendre ses activités en régime de production contrôlée, avec des horaires restreints, une surveillance renforcée des fraudes et des plafonds de transaction.
• En mars 2026, selon le directeur général de la Police fédérale brésilienne, 25 personnes avaient été arrêtées et plus de 500 millions de reais récupérés. L'enquête se poursuit.

Retenez deux chiffres : l'accès a été vendu 15 000 reais et a servi à déplacer des centaines de millions. L'écart entre ces deux montants mesure les dégâts qu'un seul accès pouvait provoquer. Et c'est dans cet écart que le travail de qualité peut faire la différence.

« Mais c'est le problème de l'équipe sécurité »

C'est la réaction la plus courante, et elle se comprend. Le QA ne réalise pas de tests d'intrusion, ne configure pas de pare-feu et n'enquête pas sur un employé qui vend son mot de passe. Rien de tout cela ne change. Personne ne suggère que l'ingénieur QA devienne expert en sécurité offensive.

La question est ailleurs. La norme ISO/IEC 25010, l'une des références les plus utilisées pour définir la qualité logicielle, classe la sécurité parmi les caractéristiques de qualité d'un produit, aux côtés de l'adéquation fonctionnelle, de la performance et de la fiabilité. Si la sécurité fait partie de la définition de la qualité, elle fait aussi partie de la conversation de ceux qui en ont la charge.

Prenons le cas de C&M. Aucune revue de code n'aurait détecté un employé abordé dans un bar. Mais la question « que se passe-t-il si un identifiant valide tombe entre de mauvaises mains ? » peut être posée lors de n'importe quel affinage, par n'importe quel membre de l'équipe. Et la personne qui passe ses journées à imaginer comment les choses peuvent mal tourner, c'est souvent l'ingénieur QA.

Il y a une différence importante entre mettre en place un contrôle de sécurité et remarquer qu'il manque. La première tâche peut revenir à l'équipe sécurité ou aux développeurs. La seconde concerne tout le monde, et le QA est particulièrement bien placé pour l'assumer, car il lit déjà les critères d'acceptation, connaît les parcours de bout en bout et a l'habitude de demander « et si ? ».

Là où les dégâts ont grandi

Un identifiant divulgué, c'est un incident. Des centaines de millions transférés en quelques heures, en pleine nuit, c'est un problème d'une tout autre ampleur. Entre les deux se trouve une série de questions qui auraient pu devenir des exigences testables :

• Quel est le montant maximal qu'un seul identifiant peut déplacer en une heure ?
• Le système se comporte-t-il de la même façon à 4 heures du matin qu'à 14 heures ?
• Combien de virements successifs vers de nouveaux destinataires sont considérés comme normaux avant que quelqu'un soit prévenu ?
• Qui reçoit l'alerte, en combien de temps, et que peut faire cette personne pour interrompre l'opération ?
• Un identifiant créé pour un client peut-il agir au nom d'un autre ?

Regardez la réponse de la Banque centrale après l'attaque : production contrôlée, horaires restreints, surveillance des fraudes et plafonds de transaction. Quelques mois plus tard, le régulateur a durci les règles pour les entreprises qui assurent ce type de connexion, notamment avec un plafond de 15 000 reais pour les virements Pix et TED effectués par les institutions connectées via ces prestataires. Chacune de ces mesures est une exigence qui peut être rédigée, testée et vérifiée. Aucune ne demande de casser un chiffrement. Elles demandent que quelqu'un ait posé la question avant.

Le guide OWASP API Security Top 10, référence mondiale en la matière, consacre une catégorie entière à ce sujet : l'accès sans restriction aux flux métier sensibles. Il explique que ce type de faiblesse n'est pas toujours un bug de code. Souvent, le système fonctionne parfaitement et n'a simplement aucune protection contre l'usage excessif d'une fonctionnalité qui peut nuire à l'entreprise. C'est donc un problème d'exigences, et les exigences sont le terrain du QA.

Le rôle du QA à chaque étape

L'ingénieur QA n'a pas besoin d'attendre un projet de sécurité pour contribuer. Les rituels que l'équipe pratique déjà suffisent.

Pendant l'affinage

C'est le moment le moins coûteux pour soulever un risque. Quand une user story touche à l'argent, aux données personnelles ou aux permissions, ajoutez des scénarios d'abus à côté des scénarios d'usage. Au lieu de demander seulement « l'utilisateur peut-il faire un virement ? », demandez aussi « qu'est-ce qui empêche quelqu'un de tout virer ? ». Si la réponse est « rien », cela doit devenir un critère d'acceptation ou, au minimum, une décision documentée de la personne qui a accepté le risque.

Pendant la planification des tests

Pour chaque fonctionnalité sensible, écrivez au moins un test d'autorisation négatif et un test de limite. Un identifiant en lecture seule tente d'écrire. Un utilisateur du client A tente d'accéder aux données du client B. Une série d'opérations dépasse le plafond prévu. Ces tests ne demandent aucun outil de sécurité. Ils demandent une intention.

Pendant le daily

Si vous avez remarqué quelque chose d'étrange pendant vos tests, comme un endpoint qui accepte plus qu'il ne devrait ou un message d'erreur qui révèle des détails internes, parlez-en au daily. Inutile d'être certain qu'il s'agit d'une vulnérabilité. Il suffit de dire « j'ai trouvé un comportement qui m'inquiète, j'aimerais en parler avec quelqu'un après ». Une alerte courte au bon moment vaut mieux qu'un rapport parfait livré trop tard.

Pendant les revues de code et de pull requests

Même sans être spécialiste en sécurité, on peut repérer des signaux simples : un contrôle de permission présent sur une route et absent d'une route similaire, une valeur configurable sans plafond, une erreur capturée puis ignorée sans aucune trace. Un commentaire comme « cette route n'a pas la même validation que la route X, est-ce voulu ? » est déjà une contribution précieuse.

Pendant les tests exploratoires

Réservez une partie de votre temps pour penser comme quelqu'un de malintentionné disposant d'un accès légitime. Pas un intrus extérieur qui tente d'entrer, mais quelqu'un de l'intérieur, avec un identifiant valide, qui essaie d'en faire plus que ce qu'il devrait. L'affaire C&M montre que ce scénario est bien réel.

Pendant les rétrospectives et après les incidents

Quand quelque chose tourne mal, le QA peut aider à transformer la leçon en test. Chaque défaillance importante devrait donner lieu à au moins un cas de non-régression, y compris les défaillances de sécurité. Si l'équipe ne les consigne pas, la même faille peut revenir lors du prochain refactoring.

Les questions que chaque QA devrait apporter à son équipe

Gardez cette liste. Elle s'applique à l'affinage de toute fonctionnalité qui touche à l'argent, aux données ou aux permissions :

1. Qui peut faire cela ? Et qui ne doit surtout pas pouvoir le faire ?
2. Combien peut-on faire ? Existe-t-il une limite par opération, par heure, par jour ?
3. Quand peut-on le faire ? Les opérations en dehors des heures ouvrées suivent-elles une règle différente ?
4. Qu'est-ce qu'un comportement inhabituel ? Et le système sait-il le détecter ?
5. Qui est prévenu ? Existe-t-il une alerte, qui la reçoit et en combien de temps ?
6. Comment arrêter l'opération ? Existe-t-il un moyen rapide de bloquer un identifiant ou une intégration ?
7. Qu'est-ce qui est journalisé ? Si quelque chose tourne mal, peut-on reconstituer qui a fait quoi ?

Aucune de ces questions ne demande de connaissances avancées en sécurité. Toutes produisent des critères d'acceptation testables.

Comment donner l'alerte sans devenir « le pénible de l'équipe »

Beaucoup de gens renoncent à signaler un risque par peur de paraître alarmistes ou d'empiéter sur le terrain d'une autre équipe. Quelques pratiques aident à se faire entendre :

• Décrivez un scénario, pas une opinion. « Ça a l'air peu sûr » ouvre un débat. « Un utilisateur avec un identifiant valide peut virer sans limite à 3 heures du matin sans déclencher la moindre alerte » déclenche une action.
• Montrez l'impact. Argent, données exposées, amendes, réputation de l'entreprise. L'affaire C&M est un bon exemple pour montrer que ce risque n'a rien de théorique.
• Apportez une suggestion, même simple. Un plafond, une alerte, une confirmation supplémentaire. La solution finale peut être décidée par quelqu'un d'autre, mais une proposition concrète facilite la discussion.
• Consignez-le. Ouvrez un ticket, laissez un commentaire sur la user story, notez-le dans le compte rendu. Si l'équipe décide d'accepter le risque, que ce soit une décision consciente et documentée.
• Impliquez ceux qui maîtrisent le sujet. Si l'entreprise dispose d'une équipe sécurité, transmettez-lui votre constat. Votre rôle est de remarquer et de communiquer. L'analyse approfondie peut rester entre les mains des spécialistes.

Une précaution importante : ne testez jamais une vulnérabilité supposée en production et n'essayez pas de l'exploiter pour prouver qu'elle existe. Signalez-la par les canaux appropriés et utilisez des environnements autorisés.

Ce qui ne relève pas du QA

Par souci d'honnêteté, il faut préciser les limites de cette responsabilité. Le QA n'est pas chargé d'empêcher qu'un employé soit corrompu. Il ne répond ni de la politique de mots de passe de l'entreprise, ni de la segmentation du réseau, ni des enquêtes sur les incidents. L'ingénieur QA n'a pas besoin de savoir réaliser des tests d'intrusion.

Ce que le QA peut faire, c'est s'assurer que les bonnes questions arrivent tôt, que les contrôles deviennent des exigences et que ces exigences soient testées comme n'importe quelle autre fonctionnalité. Dans une équipe mature, la sécurité est une responsabilité partagée. Le QA ne remplace pas le spécialiste, mais il peut être celui qui allume le voyant orange avant qu'on ait besoin du rouge.

Conclusion

L'attaque contre C&M a commencé par un mot de passe vendu 15 000 reais. Aucun ingénieur QA n'aurait empêché cette partie. Mais l'ampleur des dégâts dépendait d'autres questions : combien un identifiant pouvait déplacer, à quelle heure, sans que personne ne soit prévenu. Ces questions ont leur place dans un affinage ordinaire, un mardi comme un autre.

Vérifier que le système fait ce qu'il doit faire reste au cœur de notre métier. Mais dans les systèmes qui déplacent de l'argent, vérifier ce qu'il doit refuser de faire compte tout autant. Un ingénieur QA qui l'a compris cesse d'être la dernière barrière avant la production et devient l'une des premières voix à signaler le risque.

Dans votre équipe, quelqu'un a-t-il déjà demandé combien un seul identifiant peut déplacer avant que quelqu'un ne s'en aperçoive ?

Références

Les sources de presse ci-dessous sont en portugais.

1. Poder360. Une entreprise de services financiers visée par une cyberattaque. 2 juillet 2025.
2. Diário de Pernambuco. L'attaque n'a pas impliqué d'extraction de données clients, selon C&M Software. 3 juillet 2025.
3. Gazeta do Povo. Article sur l'arrestation du technicien qui a vendu l'accès. Juillet 2025.
4. Baguete. Un employé de C&M a vendu son mot de passe pour 15 000 reais. Juillet 2025.
5. Finsiders Brasil. Article sur ce qui a changé un an après l'attaque contre C&M Software. 2026.
6. OWASP. OWASP API Security Top 10, édition 2023 (catégories API5:2023 et API6:2023).
7. Sonar. Understanding the ISO/IEC 25010: framework for software quality (présentation de la norme ISO/IEC 25010:2023).