Pour les responsables techniques, les responsables produit et les équipes qui modifient des fonctions sensibles, reprennent une base de code ou analysent une vulnérabilité connue.

Quand vous avez besoin d’une analyse de cause racine et d’un correctif réaliste.

Ce que nous examinons

Définir les modules, les modifications, les dépendances et les flux de données concernés.
Examiner les frontières de confiance, les droits d’accès et le traitement des entrées non fiables.
Analyser les vulnérabilités dans leur contexte et discuter de correctifs adaptés à l’architecture.

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 langages et technologies examinez-vous ?

Je travaille sur du code applicatif, notamment en C, C++ et Java, avec une expérience de développement en PHP/Laravel, Vue, Node.js et MySQL. Présentez votre stack et vos objectifs pour que nous confirmions le bon périmètre.

Avez-vous besoin de toute la base de code ?

L’accès dépend de la question posée. Même une revue ciblée peut nécessiter le code environnant, des informations de compilation ou des tests pour comprendre les droits, les dépendances et les flux de données.

La revue peut-elle porter sur un correctif proposé ?

Oui. Nous pouvons vérifier si une modification convenue traite la cause d’origine et si elle introduit des problèmes connexes. Tout travail d’implémentation est convenu séparément si nécessaire.

Pouvons-nous commencer par un seul composant ?

Oui. Une revue limitée d’une fonctionnalité, d’un module ou d’une modification critique peut constituer une première mission utile. Le rapport en précise explicitement les limites.

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.

Revue de code sécurité