Pour les éditeurs de logiciels desktop, de bibliothèques, de SDK et d’outils de développement qui travaillent en C, C++ ou Java avec des composants traitant des entrées non fiables.

Lors de l’introduction d’un parseur, d’un protocole, d’une bibliothèque ou d’un composant natif important.

Ce que nous examinons

Définir les composants ciblés, l’environnement d’exécution, les exigences de compilation et les frontières de confiance.
Examiner le code pertinent, le traitement des entrées et le comportement de l’application.
Recourir à la revue de code, aux tests dynamiques ou au fuzzing ciblé, selon ce qui est convenu pour la cible.

Déroulement d’une mission

Envoyez un bref descriptif

Le produit, ce qui a changé, ce que vous devez savoir et pour quand. Un paragraphe suffit ; je réponds sous trois jours.

Recevez une proposition écrite

Périmètre, méthode, exclusions, livrables, prix et calendrier. La confidentialité, le NDA et les conditions de contre-audit sont fixées dans cette même proposition.

Suivez les travaux au fil de l’eau

Pour un audit, vous voyez les preuves et les priorités dès qu’elles apparaissent. Pour un développement, vous validez les jalons convenus.

Rapport et restitution

Vous recevez le rapport ou le livrable, puis une restitution avec votre équipe. Toute correction ou vérification complémentaire est convenue avec vous.

Je trouve la cause, puis j’écris le correctif.

J’ai écrit les correctifs de deux CVE du noyau Linux et sept autres correctifs aujourd’hui intégrés à la branche principale. Sur votre produit, chaque vulnérabilité est livrée avec le chemin dans le code, les conditions qui la déclenchent et un correctif que votre équipe peut relire.

Voir les 9 correctifs intégrés au noyau

Questions avant de commencer

Quels projets desktop sont concernés ?

Des applications, bibliothèques et composants qui soulèvent des questions de sécurité claires, notamment autour des entrées non fiables. Précisez le langage, le système d’exploitation et les exigences de compilation pour que nous confirmions l’adéquation.

Le fuzzing fait-il partie de l’audit ?

Il peut être inclus lorsqu’il convient à la cible. Nous convenons séparément de l’étude de faisabilité, de la campagne et des livrables, plutôt que de supposer que toutes les applications appellent la même approche.

Quels travaux publics appuient cette offre ?

Mes travaux publics comprennent CVE-2024-26855 et CVE-2025-37858 dans le noyau Linux, dont les correctifs ont été acceptés en amont. Ces fiches attestent d’un travail concret d’analyse et de correction de code natif.

Sous quel délai répondez-vous ?

Sous trois jours au plus. Vous recevez des questions sur votre produit ou les grandes lignes d’une proposition.

Combien cela coûte-t-il ?

Les tarifs publiés sont des prix de départ. Le prix final dépend du périmètre et de la complexité technique ; il est fixé dans la proposition écrite avant le démarrage.

Combien de temps cela prend-il, et quand pouvez-vous commencer ?

La durée et la date de démarrage dépendent du périmètre, de la complexité technique et de ma charge de travail. La proposition indique les dates.

Pouvons-nous travailler sous NDA ?

Oui. Les conditions de confidentialité, y compris un NDA si vous en avez besoin, sont fixées dans la proposition avant que vous ne partagiez du code, des identifiants ou des vulnérabilités.

Un contre-audit est-il prévu ?

Le contre-audit est convenu pour chaque mission dans la proposition : quelles vulnérabilités, quelle version et dans quel délai.

Travaillez-vous avec des agences ?

Oui. Les agences peuvent faire appel à moi pour le projet d’un client. Les conditions de livraison, y compris les rapports en marque blanche, sont fixées au cas par cas dans la proposition.

Sécurité des applications desktop et natives