Un **rapport de plantage issu du fuzzing** doit réunir l'entrée qui provoque l'échec, la version exacte du programme cible, la commande, l'environnement et le comportement observé. Précisez avec quelle fiabilité le problème se reproduit, qui mène l'investigation et ce qui reste à établir concernant ses conséquences sur la sécurité. Une fois le correctif prêt, conservez les résultats obtenus en rejouant le cas sur la version corrigée.

Prenez le temps de préparer cette transmission avant de consacrer un nouvel après-midi à générer des entrées. Un répertoire de fichiers provoquant des plantages peut laisser l'ingénieur qui le reçoit face à des questions élémentaires : quel exécutable les a produits ? L'échec se produit-il en dehors du processus de fuzzing ? Le programme cible a-t-il été compilé avec un outil de détection des erreurs mémoire ? Quel résultat permettra de considérer le problème comme corrigé ?

Les [conseils de Chris Wellons sur les tests avec AFL++](https://nullprogram.com/blog/2025/02/05/) ont fait l’objet d’une nouvelle [discussion sur Hacker News](https://news.ycombinator.com/item?id=50271106), observée le 2 novembre 2026. L'article date du 5 février 2025 : il s'agit d'un regain d'intérêt pour un guide technique plus ancien. Son approche pratique permet d’aborder une autre question : comment transformer une découverte en travail qu'une autre personne peut reprendre ?

La démarche ci-dessous propose une méthode de transmission pour une petite équipe d'ingénierie. Elle s'appuie sur la documentation d'AFL++ et de ClusterFuzz. Elle ne rend pas compte d'une campagne de fuzzing que nous aurions menée, et l'exemple d'analyseur de documents sert uniquement d'illustration : il ne décrit aucune vulnérabilité découverte.

## Conservez l'expérience avant de la simplifier

Enregistrez assez de contexte pour reconstituer l'exécution qui a échoué. L'entrée compte, mais aussi l'exécutable, le harnais de test, la configuration et les observations qui permettent de l'interpréter.

Le **harnais de test** est le code qui transmet les entrées générées à la fonction ou au programme testé. Consignez sa révision avec celle du programme cible. Si quelqu'un modifie la façon dont le harnais initialise un analyseur ou lui transmet un tampon, la même entrée peut correspondre à une expérience différente.

Conservez l'entrée d'origine dans un espace à accès restreint, avec une référence stable dans le rapport. Sauvegardez les sorties utiles avant de remplacer les binaires ou de recréer votre environnement. Indiquez la plateforme, le compilateur, les options de compilation, la configuration de détection des erreurs mémoire et les options d'exécution dont l'utilisation est établie. Signalez les détails manquants au lieu de les reconstituer de mémoire.

Supposons qu'un harnais fictif d'analyse de documents échoue lorsqu'on lui fournit un fichier enregistré. « L'analyseur plante sur cette pièce jointe » laisse plusieurs explications possibles. Le fichier révèle peut-être un défaut du programme cible, le harnais appelle peut-être mal l'analyseur, ou un réglage d'exécution particulier est peut-être nécessaire pour observer l'échec. Votre première note doit préserver ce qui s'est passé sans trancher prématurément entre ces explications.

Wellons décrit deux pièges utiles à connaître concernant les harnais, dans le cadre qu'il étudie : du code C/C++ dont les sources sont accessibles, sous Linux avec glibc. Le premier concerne un état qui persiste entre les itérations du mode persistant ; le second, des tampons d'entrée surdimensionnés qui masquent certaines lectures hors limites à AddressSanitizer. Ces exemples invitent à examiner l'expérience elle-même. Ils ne justifient pas de recopier tous les réglages du compilateur dans un environnement technique sans rapport.

Évitez de faire d'une pièce jointe à un ticket public l'unique copie d'une entrée sensible. Un cas généré peut être anodin, mais une investigation peut aussi porter sur de vrais documents, des chemins internes ou des sorties de diagnostic. Déterminez qui a besoin d'y accéder et conservez le fichier là où ces personnes pourront le récupérer. Un lien que l'ingénieur suivant ne peut pas ouvrir reste une transmission incomplète.

## Rendez la commande de reproduction utilisable ailleurs

Une instruction de reproduction doit permettre à l'ingénieur suivant d'exécuter le cas prévu sans deviner vos conventions locales. Fournissez la commande avec son répertoire de travail, l'entrée requise et les paramètres d'environnement pertinents.

La [procédure de correction de ClusterFuzz](https://google.github.io/clusterfuzz/using-clusterfuzz/workflows/fixing-a-bug/) met à disposition le cas de test déclencheur et la version du programme, et consigne la ligne de commande ainsi que les variables d'environnement importantes. La documentation précise que ces variables peuvent être nécessaires pour reproduire l'échec. C'est un modèle utile, même si votre équipe utilise un autre outil.

Pour transmettre le cas, identifiez le binaire cible par une référence de compilation stable et une révision du code source. Précisez si le programme lit un fichier, l'entrée standard ou une autre interface. Expliquez comment obtenir ou compiler l'exécutable. Ne remplacez les chemins propres à une machine par des emplacements documentés qu'après avoir vérifié que les instructions modifiées décrivent toujours la même exécution.

Distinguez la préparation de l'exécution. Si l'ingénieur destinataire a besoin d'une image de conteneur particulière, d'un répertoire de données de test ou d'une configuration de compilation, indiquez-le avant l'instruction de reproduction. Ne laissez pas une étape de préparation indispensable dans un ancien message de discussion.

Décrivez ensuite précisément ce que vous avez observé. « Échoue » peut désigner un diagnostic de détection d'erreur mémoire, un signal reçu par le processus, un dépassement du délai d'exécution ou une sortie inattendue. Conservez le diagnostic utile et indiquez le comportement attendu. Une capture d'écran peut aider à reconnaître un résultat, mais elle ne doit pas constituer l'unique trace d'une commande ou d'une erreur qu'il faudra copier et examiner.

Consignez les tentatives comme des observations. Si un cas se reproduit de façon intermittente, dites-le et décrivez les conditions essayées. Ne concluez pas qu'une découverte initiale était invalide après une seule tentative infructueuse. Désignez une personne pour mener une expérience susceptible d’expliquer l’écart, par exemple comparer la version d’origine ou vérifier l’état du harnais.

## Distinguez la réduction du cas de test de l'évaluation de sécurité

Réduire une entrée peut faciliter l'investigation. Cela ne suffit pas à établir que l'échec est exploitable ou que le chemin de code concerné est accessible dans votre produit.

[AFL++ documente `afl-tmin`](https://aflplus.plus/docs/fuzzing_in_depth/#4-triaging-crashes) pour réduire les cas de test. Gardez le cas d'origine à côté du cas réduit et consignez la méthode utilisée. Vérifiez à nouveau le comportement pertinent avant de considérer le cas réduit comme un substitut. Le fichier plus petit doit aider à expliquer l'échec étudié, et pas simplement provoquer un échec quelconque.

La même documentation rappelle qu'évaluer l'exploitabilité peut nécessiter un travail conséquent de débogage et d'analyse du code. Préservez cette distinction dans le rapport. « Échec détecté par l'outil de contrôle mémoire et reproduit » est un résultat utile. « Vulnérabilité exploitable à distance confirmée » exige des preuves qui dépassent largement le simple arrêt du processus.

Pour l'analyseur fictif, les questions suivantes pourraient porter sur la présence du code concerné dans la version distribuée, la possibilité que des documents non fiables l'atteignent et les privilèges du processus d'analyse. Ce sont des pistes d'investigation, pas des faits établis concernant cet exemple. Consignez l'exposition connue séparément des hypothèses.

Considérez aussi le regroupement des cas comme un moyen d'organiser l'investigation. Plusieurs fichiers enregistrés ou traces de pile similaires ne suffisent pas à établir le nombre de causes distinctes ou de vulnérabilités exploitables. Conservez les liens entre les observations apparentées, tout en permettant de revoir ces regroupements à mesure que l'ingénieur progresse.

Si l'investigation nécessite une procédure de divulgation publique, passez par votre [programme de divulgation des vulnérabilités](/blog/how-to-set-up-vulnerability-disclosure-program). Les éléments de reproduction facilitent cette procédure ; ils ne déterminent ni le calendrier de divulgation ni l'autorisation de publier des fichiers sensibles.

## Transmettez un rapport unique avec une expérience précise à mener

Le rapport doit répondre rapidement à deux questions : que peut reproduire la personne qui reprend le dossier, et quelle incertitude doit-elle lever ensuite ?

Vous pouvez adapter ce modèle à votre outil de suivi. Il s'agit d'une proposition de fiche, pas d'une exigence liée à un outil. Préférez des liens vers les fichiers à accès restreint plutôt que de tout coller dans la description.

```text
Programme cible et révision du code source :
Révision du harnais de test et point d'entrée :
Plateforme, compilateur, options de compilation et réglages de détection des erreurs mémoire :
Entrée d'origine et emplacement du fichier :
Entrée réduite et méthode de réduction, si disponibles :
Commande de reproduction et répertoire de travail :
Échec observé et sorties pertinentes :
Comportement attendu :
Tentatives de reproduction et résultats :
Exposition connue et impact restant à évaluer :
Responsable de l'investigation et prochaine expérience :
Révision du correctif, résultats de réexécution et test de non-régression :
```

Vous n'avez pas besoin de toutes les réponses avant de créer un rapport. Vous devez en revanche distinguer un champ vide d'une conclusion vérifiée. « Révision du programme cible inconnue ; référence de compilation demandée à l'auteur du signalement » en dit plus qu'un statut affirmatif appliqué à des preuves incomplètes.

La [documentation de triage de ClusterFuzz](https://google.github.io/clusterfuzz/using-clusterfuzz/workflows/triaging-new-crashes/) considère la fiabilité de la reproduction, le type de plantage, la plateforme et les intervalles de révisions où une régression a été introduite comme des informations utiles à l'investigation. Ces intervalles sont disponibles pour les plantages qui se reproduisent de manière fiable. Votre propre fiche peut conserver les mêmes distinctions sans prétendre avoir identifié le commit à l'origine du problème.

Un tableau de décision succinct permet de voir immédiatement quelle action mener :

| Éléments disponibles | Action utile à mener | Conclusion encore ouverte |
| --- | --- | --- |
| Entrée sans version du programme ni commande correspondante | Demander le contexte de reproduction manquant | Un autre ingénieur peut-il reproduire l'échec ? |
| Échec reproductible dans la configuration consignée | Confier l'étude de la cause et de l'exposition | Impact sur la sécurité et périmètre du produit concerné |
| Échec intermittent | Conserver les tentatives et étudier les différences de conditions | Pourquoi la fiabilité varie-t-elle ? |
| Plusieurs cas apparemment liés | Comparer les éléments et maintenir les liens | Nombre de causes distinctes |
| Correctif sans résultat de réexécution | Tester le cas consigné sur la version corrigée | L'échec observé est-il corrigé ? |

Désignez une personne pour l'expérience suivante. Dans l'exemple de l'analyseur, il pourrait s'agir de l'ingénieur capable de comparer le comportement du harnais avec le point d'entrée utilisé en production. Le rapport doit préciser ce qu'elle vérifiera et où consigner le résultat.

Si une découverte confirmée reste ensuite bloquée faute de décision sur la compatibilité ou la publication, le problème change de nature. Notre [guide d'escalade des décisions de correction de sécurité](/blog/security-fix-decision-escalation) explique comment attribuer cette décision à un responsable et fixer une date de réexamen.

## Vérifiez le correctif sur l'échec consigné

La référence d'un correctif indique ce qui a changé. Les résultats de réexécution indiquent ce qui s'est passé lorsque vous avez testé le cas pertinent après cette modification.

Gardez ensemble la révision qui échoue, la révision corrigée, la configuration, la référence du cas de test et les résultats. Lorsque c'est possible, conservez le cas dans vos tests de non-régression pour que les modifications futures vérifient le comportement corrigé. Décrivez le résultat attendu assez clairement pour qu'un autre ingénieur comprenne plus tard pourquoi le test existe.

La procédure de correction de ClusterFuzz décrit la réexécution des cas sur des versions ultérieures. Cette automatisation appartient à ClusterFuzz. Si votre équipe rejoue un cas manuellement ou dans un autre système, consignez la méthode et le résultat réels au lieu de reprendre le libellé de vérification d'un outil.

Vérifiez que l'expérience n'a pas changé par accident. Un résultat sans erreur obtenu après avoir désactivé la détection pertinente ou modifié le harnais peut répondre à une autre question. Expliquez les changements de configuration intentionnels et leur effet sur les conclusions possibles.

Pour un échec intermittent, décrivez l'incertitude restante et la période d'observation ou les tests supplémentaires retenus. Aucun nombre universel de tentatives ne prouve la disparition de tous les défauts de ce type. De même, la réexécution réussie d'un cas étaye une conclusion concernant ce cas et cette configuration ; elle ne certifie pas la sécurité de l'ensemble de l'analyseur.

## Gardez les preuves et le cycle de vie du rapport ensemble dans Kit

Votre outil de fuzzing, votre système de compilation, votre débogueur et vos ingénieurs produisent les preuves techniques. Un outil de suivi des rapports aide à les relier à l'investigation et aux échanges qui l'accompagnent.

Les rapports de sécurité de Kit permettent de conserver des notes de reproduction, des évaluations et des états du cycle de vie, notamment « Clarification nécessaire », « Validé », « Résolu » et « Correctif vérifié ». Vous pouvez garder le résumé de reproduction et les références avec le rapport au fil du travail. Kit chiffre au repos les champs de texte du rapport, dont les étapes de reproduction ; cette affirmation ne s'étend pas à tous les fichiers que vous pourriez stocker ailleurs.

Un état du cycle de vie doit résumer le travail consigné. Avant de marquer une découverte comme vérifiée, ajoutez un lien vers le résultat réel de réexécution et rendez visibles les limites de périmètre restantes. Kit n'exécute pas AFL++, ne réduit pas un corpus de plantages, n'établit pas l'exploitabilité et ne lance pas vos tests de non-régression.

Commencez par la prochaine découverte qui attend déjà votre attention. Vérifiez qu'un autre ingénieur peut obtenir l'entrée, identifier la version du programme, exécuter la commande et comprendre l'échec observé. Comblez les lacunes, désignez l'expérience suivante et gardez son résultat avec le rapport. Votre équipe dispose ainsi d'une investigation concrète à poursuivre.