Penser comme un triager : verdicts et CVSS 3.1

Objectifs

À la fin de ce guide transversal, tu seras capable de :

• Comprendre le rôle, les contraintes et la grille d'analyse d'un triager de plateforme (YesWeHack, HackerOne, Bugcrowd, Intigriti).
• Distinguer avec certitude les statuts d'un rapport : valide, doublon de cause racine, hors périmètre, informatif et non applicable.
• Calculer rigoureusement le vecteur et le score CVSS 3.1 d'une vulnérabilité en maîtrisant les huit métriques fondamentales et leurs subtilités.
• Éviter les pièges de cotation fréquents : confusion entre privilèges requis (PR) et interaction utilisateur (UI), changement de portée (Scope: Changed), et surévaluation d'impact.
• Anticiper les évolutions vers le standard CVSS 4.0 et savoir aligner ton argumentation sur la politique propre à chaque programme.

Le rôle du triager : premier filtre, pas adversaire

Dans l'écosystème du bug bounty, le triager occupe une position charnière entre deux mondes aux attentes parfois contradictoires :

• Le chercheur (hunter), qui a passé des heures à chercher une faille, veut voir son temps valorisé, son rapport accepté rapidement et son impact reconnu à sa juste sévérité.
• L'équipe de sécurité cliente (l'entreprise), qui reçoit des dizaines de signalements par semaine, doit justifier chaque versement de prime, corriger en priorité ce qui menace réellement ses opérations et rejeter les faux positifs sans perdre de temps.

Le triager n'est pas là pour t'empêcher de toucher une prime. Son rôle est de qualifier objectivement chaque signalement selon un contrat clair : la politique du programme (program policy) et les standards de l'industrie (CVSS, CWE). S'il valide un rapport non reproductible ou hors scope, il perd la confiance du client. Si un rapport est clair, reproductible et documenté avec précision, le triager est ton meilleur allié : il confirme la faille, ajuste la sévérité au niveau approprié et transmet le dossier directement aux équipes de développement.

Le cycle de vie d'un rapport sur les plateformes

Chaque rapport déposé traverse des états standardisés :

1. Nouveau (New / Received) : le rapport vient d'être soumis. Il est placé dans la file d'attente des triagers.
2. Besoin d'informations (Needs more info) : le triager a tenté de reproduire la vulnérabilité mais une étape est manquante, une requête échoue ou l'environnement de test n'est pas spécifié. Tu as généralement entre 7 et 14 jours pour répondre.
3. Trié / Confirmé (Triaged / Accepted) : le triager a reproduit la vulnérabilité sur ses propres environnements, confirmé qu'elle entre dans le périmètre et validé la sévérité préliminaire. Le rapport est transmis au client pour correction.
4. Résolu (Resolved) : le correctif a été déployé en production. Le hunter peut être invité à re-tester (re-test) pour confirmer la remédiation. La prime (bounty) est attribuée selon la politique de paiement du programme.
5. Doublon (Duplicate) : un autre chercheur a soumis la même vulnérabilité avant toi, ou l'équipe interne avait déjà répertorié le bogue.
6. Informatif (Informative) : la découverte technique est réelle, mais le risque pour l'entreprise est nul ou insuffisant au regard de la politique. Aucune prime n'est versée, mais le travail technique est reconnu sans pénaliser la réputation du chercheur.
7. Hors périmètre (Out of scope) : l'actif testé ou le type d'attaque n'est pas autorisé par le programme.
8. Non applicable (Not Applicable / N/A) : le rapport est un faux positif (souvent issu d'un scanner automatisé non vérifié), le comportement décrit est intentionnel, ou aucune preuve de vulnérabilité n'est fournie. Ce statut entraîne une perte de points de réputation sur la plupart des plateformes.

L'arbre de décision du triage

Pour statuer sur un rapport entrant, un triager professionnel ne commence jamais par évaluer le montant de la prime. Il applique un entonnoir logique rigoureux composé de cinq questions séquentielles.

ARBRE DE TRIAGEDu rapport reçu au verdict : cinq questions dans l'ordre

Plein écran

Cliquer pour agrandir

1. La cible et le test sont-ils dans le périmètre ?

La première vérification porte sur le document qui fait foi juridiquement : la politique du programme.

• Le domaine ou l'adresse IP figure-t-il explicitement dans la section In Scope ?
• Si le scope mentionne *.acme.test, le sous-domaine identifié n'est-il pas pointé via un CNAME vers une infrastructure SaaS tierce expressément exclue ?
• La technique employée est-elle autorisée ? Les attaques par déni de service (DoS/DDoS), le brute-force volumétrique sans preuve d'impact logique, l'ingénierie sociale ou les tests physiques sont quasi universellement proscrits.

Si la cible ou la méthode est hors cadre, le verdict immédiat est Out of Scope.

2. Le scénario est-il fidèlement reproductible ?

Le triager se connecte à un environnement équivalent et exécute les étapes fournies. Si le rapport indique « envoyer une apostrophe dans le champ recherche » mais que la capture d'écran montre une erreur HTTP 500 sans plus de détails, ou si le script fourni dépend de variables non documentées, le rapport bascule en Needs more info.

Si le chercheur ne fournit pas les détails requis pour reproduire la faille, le rapport est finalement fermé sans validation.

3. La vulnérabilité est-elle déjà connue ?

Si la vulnérabilité est confirmée, le triager consulte la base de données des rapports existants du programme.

• Un rapport identique a-t-il été soumis par un autre chercheur quelques heures ou quelques jours plus tôt ?
• Le bogue fait-il partie de la liste des Known Issues publiée dans les consignes du programme ?

Si oui, le rapport est marqué Duplicate. Sur la majorité des plateformes, seul le premier rapport valide reçoit la prime.

4. La vulnérabilité fait-elle l'objet d'une exclusion explicite ?

Chaque entreprise définit ses priorités dans une section Out-of-Scope / Exclusions. Parmi les exclusions courantes :

• Absence d'en-têtes de sécurité HTTP (Strict-Transport-Security, X-Content-Type-Options) sans chaîne d'exploitation prouvée.
• Problèmes de configuration SPF, DKIM ou DMARC sans preuve d'usurpation exploitable sur un système critique.
• Self-XSS (exécution de script restreinte à la session du propre utilisateur sans vecteur de propagation).
• CSRF sur les formulaires de déconnexion (/logout).
• Énumération d'utilisateurs par différence subtile de message d'erreur ou de temps de réponse.

Si le rapport décrit l'un de ces éléments sans démontrer d'impact métier supplémentaire, le verdict est Informative ou Not Applicable.

5. Quel est l'impact réel sur la sécurité ?

Une fois la faille reconnue, le triager détermine son impact concret : permet-elle d'accéder aux données d'autres clients ? De modifier des transactions financières ? De compromettre le serveur ? C'est à cette étape que la sévérité finale est fixée via la grille CVSS 3.1.

Les verdicts expliqués en profondeur

Comprendre les critères de chaque verdict permet d'adapter sa stratégie de recherche et de ne jamais gaspiller son temps sur des rapports infructueux.

1. Valide (Triaged / Resolved)

Le rapport démontre sans ambiguïté une anomalie de sécurité dans le périmètre autorisé, avec des étapes de reproduction exhaustives et un impact prouvé. Une sévérité lui est attribuée (Low, Medium, High ou Critical), ouvrant droit aux récompenses financières et aux points de réputation.

2. Doublon (Duplicate)

Le sort le plus frustrant pour un hunter. Cependant, il existe une différence fondamentale entre :

• Le doublon temporel simple : un autre chercheur a soumis exactement la même requête 30 minutes avant toi.
• Le doublon de cause racine : tu trouves une IDOR sur GET /api/documents/download?id=123. Un rapport antérieur avait déjà signalé une IDOR sur GET /api/documents/preview?id=123. Si la fonction sous-jacente getDocument(id) en base de données ne contrôle pas les droits du propriétaire dans les deux cas, le second rapport sera fermé en doublon car la remédiation est unique.

3. Hors périmètre (Out of scope)

Ce verdict sanctionne le non-respect du périmètre contractuel. Attention aux pièges fréquents :

• Sous-domaines non inclus : le programme couvre *.acme.test, mais exclut expressément careers.acme.test et blog.acme.test qui sont hébergés chez des prestataires tiers en mode SaaS.
• Applications mobiles non compilées par l'entreprise : tester une version obsolète d'une application Android décompilée dont les endpoints d'API ont été décommissionnés.
• Réseau interne du cloud provider : scanner l'infrastructure physique ou les hyperviseurs de l'hébergeur plutôt que la couche applicative du client.

4. Informatif (Informative)

Le rapport est techniquement exact, le travail du chercheur est apprécié, mais la menace pour l'entreprise est jugée trop faible ou théorique pour justifier une prime. Exemples types :

• Découverte d'un endpoint d'administration accessible mais protégé par une authentification multi-facteurs robuste et sans bogue de logique.
• Divulgation de versions de logiciels publics (ex. Apache/2.4.52) sans vulnérabilité exploitable associée.
• Fuite d'un jeton d'API dans un fichier JavaScript public, alors qu'il s'agit d'une clé publique en lecture seule prévue par conception pour le fonctionnement du frontend (ex. clé publique Google Maps ou Stripe Publishable Key).

5. Non applicable (Not applicable)

Le verdict le plus dommageable pour le profil d'un hunter. Il correspond à :

• Des copier-coller bruts de rapports générés par des outils comme Nessus, Acunetix ou Nuclei sans aucune validation humaine.
• Des affirmations d'impact infondées (« Cette absence de header permet une prise de contrôle totale du serveur »).
• Des comportements normaux de l'application pris à tort pour des vulnérabilités.

Maîtriser CVSS 3.1 métrique par métrique

Le système CVSS v3.1 (Common Vulnerability Scoring System, maintenu par le FIRST) est le standard mondial utilisé pour quantifier la sévérité technique des vulnérabilités. Le score de base (Base Score) est calculé à partir de huit métriques regroupées en deux catégories : l'Exploitabilité et l'Impact.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  -> Score : 7.5 (High)

Examinons chacune de ces huit métriques et leurs pièges respectifs :

1. Attack Vector (AV) — Vecteur d'attaque

Définit le contexte réseau depuis lequel l'attaque peut être menée :

• Network (N) : la faille est exploitable à distance via Internet (cas de 95% des vulnérabilités web).
• Adjacent (A) : l'attaquant doit partager le même domaine de diffusion physique ou logique (même réseau Wi-Fi local, même sous-réseau VPN, Bluetooth).
• Local (L) : l'attaquant doit disposer d'un accès interactif local (shell SSH, application malveillante installée localement sur l'appareil).
• Physical (P) : nécessite un accès physique direct à la machine ou au terminal (ex. manipulation de ports USB).

2. Attack Complexity (AC) — Complexité d'attaque

Évalue l'existence de barrières ou de conditions hors du contrôle direct de l'attaquant :

• Low (L) : aucune condition aléatoire ou imprévisible. L'attaquant peut déclencher la faille à coup sûr à chaque tentative (ex. une injection SQL classique ou une IDOR sans contrôle).
• High (H) : l'attaque dépend de conditions de course temporelles (race conditions) difficiles à synchroniser, d'une configuration non standard spécifique, ou de la collecte préalable d'informations confidentielles complexes.

3. Privileges Required (PR) — Privilèges requis

Mesure le niveau d'autorisation préalable exigé pour déclencher l'attaque :

• None (N) : la vulnérabilité est accessible à un utilisateur non authentifié (internaute anonyme).
• Low (L) : l'attaquant doit posséder un compte utilisateur standard de base (ex. s'inscrire gratuitement sur le site).
• High (H) : l'accès nécessite des privilèges d'administrateur, de modérateur ou d'opérateur système.

4. User Interaction (UI) — Interaction utilisateur

Détermine si un tiers humain légitime doit effectuer une action pour que l'attaque réussisse :

• None (N) : l'attaque réussit de manière autonome sans intervention de la victime (ex. injection SQL, IDOR directe).
• Required (R) : la victime doit cliquer sur un lien forgé, visiter une page piégée ou autoriser une action (ex. XSS réfléchie, CSRF, détournement OAuth).

5. Scope (S) — Portée d'impact

La métrique la plus discutée en bug bounty. Elle détermine si le composant de sécurité vulnérable est distinct du composant de sécurité impacté :

• Unchanged (U) : l'impact reste confiné à la même autorité de sécurité que celle qui gère la ressource vulnérable.
• Changed (C) : la vulnérabilité franchit une frontière d'isolation d'autorité de sécurité (trust boundary). Deux exemples universels :
  • Cross-Site Scripting (XSS) : le serveur web vulnérable exécute du code dans le contexte de sécurité du navigateur de la victime (S:C).
  • SSRF vers infrastructure cloud : l'application web vulnérable permet d'interagir avec l'autorité de sécurité de l'hyperviseur cloud ou du service de métadonnées IAM (S:C).

6, 7 et 8. Confidentialité (C), Intégrité (I), Disponibilité (A)

Mesurent les conséquences directes sur les données et le service :

• None (N) : aucun impact sur ce pilier.
• Low (L) : accès partiel ou modification restreinte de données non critiques, dégradation mineure de service.
• High (H) : divulgation totale des données sensibles, altération critique de l'intégrité du système, ou interruption complète de la disponibilité du service.

Tableau comparatif de 8 vulnérabilités types

Voici huit scénarios courants rencontrés en bug bounty, notés selon la spécification FIRST CVSS v3.1 :

La politique du programme prime sur le CVSS brut

Une règle fondamentale régit toutes les plateformes de bug bounty : la politique écrite du programme prévaut systématiquement sur le calcul mathématique du score CVSS.

Les entreprises adaptent leurs grilles de primes en fonction de leur modèle de menace propre :

• Pour une banque en ligne, une vulnérabilité de logique métier permettant de manipuler des arrondis de centimes sera traitée en sévérité Critique, même si son score CVSS brut est modéré.
• Pour un fournisseur de contenu grand public, une vulnérabilité XSS stockée sera traitée avec une priorité extrême en raison du risque de défiguration d'image de marque ou de vers applicatif.
• Inversement, de nombreux programmes d'éditeurs logiciels plafonnent délibérément certaines failles (par exemple, toutes les SSRF sans accès au réseau interne sont rémunérées en Low forfaitaire, ou toutes les CSRF sont exclues sauf si elles modifient l'e-mail du compte).

Avant de contester la sévérité d'un triager, vérifie toujours si les consignes spécifiques du programme ne définissent pas une règle dérogatoire expresse.

Vers CVSS v4.0 : ce qui change

Publié fin 2023 par le FIRST, le standard CVSS 4.0 modernise la cotation pour corriger les rigidités historiques de CVSS 3.1. Les évolutions majeures incluent :

1. Nomenclature modulaire :
   • CVSS-B : Score de base seul (Base).
   • CVSS-BT : Score de base enrichi des données de menace (Threat - remplace le groupe Temporel).
   • CVSS-BE : Score de base enrichi des données environnementales (Environmental).
   • CVSS-BTE : Score complet combinant Base, Threat et Environmental.
2. Disparition de la métrique Scope au profit de deux niveaux d'impact distincts :
   • Impact sur le système vulnérable : VC (Vulnerable Confidentiality), VI (Integrity), VA (Availability).
   • Impact sur les systèmes tiers subséquents : SC (Subsequent Confidentiality), SI (Integrity), SA (Availability). Cela supprime les débats interminables sur le passage de S:U à S:C.
3. Affinement de l'interaction utilisateur (UI) :
   • Distingue désormais UI:P (Passive : la victime visite simplement une page piégée) de UI:A (Active : la victime doit soumettre volontairement un formulaire ou accepter un avertissement du navigateur).
4. Introduction des exigences d'attaque (AT — Attack Requirements) :
   • Isole les prérequis environnementaux ou d'infrastructure de la complexité intrinsèque de l'algorithme d'attaque (AC).

Pour aller plus loin

• FIRST CVSS v3.1 Specification Document : La référence officielle complète détaillant les définitions, formules mathématiques et exemples de cotation.
• FIRST CVSS v3.1 User Guide : Le guide d'application pratique publié par le groupe de travail du FIRST pour résoudre les cas d'arbitrage complexes.
• FIRST CVSS v4.0 Specification Document : La documentation officielle du nouveau standard de cotation de vulnérabilités.
• HackerOne Vulnerability Rating Taxonomy (VRT) : La grille de classification et de sévérité par défaut adoptée par de nombreux programmes de bug bounty.
• Bugcrowd Vulnerability Rating Taxonomy (VRT) : Le référentiel ouvert hiérarchisant les vulnérabilités de P1 (Critique) à P5 (Informatif).