OSSTMM : méthodologie, calcul du RAV et comparatif PTES, NIST

L'OSSTMM (Open Source Security Testing Methodology Manual) est une méthodologie ouverte de test de sécurité publiée par l'ISECOM, l'Institute for Security and Open Methodologies, qui mesure la sécurité opérationnelle d'un périmètre au lieu de se contenter d'une liste de vulnérabilités. Sa version de référence, OSSTMM 3.02, date de décembre 2010 et couvre cinq canaux : humain, physique, sans-fil, télécommunications et réseaux de données. Elle se distingue par une métrique chiffrée de la surface d'attaque, le rav, et par un rapport normalisé, le STAR. En 2026, le sujet revient au premier plan : l'ISECOM a présenté en octobre la version 4, annoncée pour une diffusion publique le 1er décembre. Ce guide explique le fonctionnement de la méthode, sa place face à PTES, à l'OWASP et au NIST SP 800-115, et la manière de l'intégrer dans une démarche de pentest interne et de ses livrables.

OSSTMM : définition, origine et gouvernance par l'ISECOM

L'OSSTMM est né le 18 décembre 2000 à l'initiative de Pete Herzog, puis a été porté par l'ISECOM, organisation à but non lucratif fondée en 2001 et établie à New York et en Catalogne. Le manuel est développé en communauté et soumis à une revue par les pairs. Sa version courante, la 3.02, a été publiée le 14 décembre 2010 ; elle a rendu obsolètes toutes les versions 2.x ainsi que les versions candidates de la 3.0.

Contrairement à un référentiel de bonnes pratiques, le manuel ne décrit pas les solutions qu'une organisation devrait posséder. Il impose de vérifier, par des tests, la façon dont les protections se comportent réellement en production. Le manuel OSSTMM 3 publié par l'ISECOM résume cette posture : la méthode doit dire si ce que vous possédez fait ce que vous attendez, et pas seulement ce qu'on lui a demandé de faire.

Une méthode d'audit, pas une boîte à outils

Le manuel ne prescrit ni scanner ni outil d'exploitation. Il définit ce qu'il faut tester, dans quel ordre et comment consigner les résultats. Le démarrage rapide proposé par l'ISECOM tient en quatre éléments à suivre : les cibles testées, les parties de ces cibles réellement examinées, les types de contrôles découverts et, point souvent négligé, tout ce qui n'a pas été testé. Le reste du test peut se dérouler selon les habitudes de l'équipe.

Licence OSSTMM et certifications de l'ISECOM

Licence et conditions d'utilisation

OSSTMM 3, le manuel de l'Institute for Security and Open Methodologies (ISECOM), est diffusé sous licence Creative Commons BY-NC-ND 3.0 et sous l'Open Methodology License (OML 3.0). Concrètement, le manuel est gratuit à lire et à appliquer dans des prestations de test, de conseil, de formation ou de recherche.

Il ne peut en revanche être ni modifié, ni revendu, ni intégré commercialement dans un outil ou une liste de contrôle sans accord explicite de l'ISECOM. L'OML demande aussi à l'utilisateur d'être transparent sur la façon dont il applique la méthode, une exigence cohérente avec la logique de rapport du manuel, qui impose de déclarer ce qui a été testé et ce qui ne l'a pas été.

Des certifications individuelles adossées au manuel

L'ISECOM délivre des certifications fondées sur sa méthodologie. La version 3 du manuel cite notamment l'OPST (testeur de sécurité, orienté réseaux de données), l'OPSA (analyste, centré sur l'analyse et les métriques de surface d'attaque), l'OPSE, l'OWSE pour le sans-fil et la CTA pour l'analyse de confiance. Ces titres attestent d'une maîtrise de la méthode ; ils ne constituent pas une qualification réglementaire et ne remplacent pas l'expérience démontrée sur des missions réelles.

Sécurité opérationnelle : le changement de perspective de l'OSSTMM

Le cœur conceptuel de l'OSSTMM tient en une distinction. Une menace n'est efficace que si elle interagit, directement ou indirectement, avec un actif. La sécurité, au sens du manuel, désigne la séparation entre l'actif et la menace ; la sûreté (safety) désigne les contrôles qui limitent la menace ou ses effets lorsque la séparation est impossible. Un service publié sur Internet ne peut pas être totalement séparé : il doit donc être protégé par des contrôles.

De cette distinction découle la notion de surface d'attaque, définie comme l'absence de séparations spécifiques et de contrôles fonctionnels pour un vecteur donné. Le vecteur est la direction de l'interaction : depuis Internet vers la DMZ, depuis le réseau des postes vers l'annuaire, depuis un visiteur vers l'accueil. Un même périmètre possède donc plusieurs surfaces d'attaque, une par vecteur, et chacune se mesure séparément.

Plus de contrôles ne signifie pas plus de sécurité

L'OSSTMM insiste sur un point contre-intuitif : chaque contrôle ajouté peut créer de nouvelles interactions, donc de nouveaux points de défaillance. Empiler trois mécanismes du même type n'offre pas une véritable défense en profondeur, car contourner l'un revient souvent à contourner les autres. Le manuel recommande plutôt de diversifier les types de contrôles, d'où l'importance de les classer selon leur fonction opérationnelle réelle.

Des faits vérifiés plutôt que des opinions

La méthodologie OSSTMM distingue une limitation identifiée, constatée visuellement ou par déduction, d'une limitation vérifiée, démontrée par un test. Elle classe aussi les problèmes selon leur effet opérationnel et non selon une estimation d'impact, de difficulté ou de disponibilité d'un exploit. Ce parti pris vise la reproductibilité : deux analystes qui testent le même périmètre avec la même méthode doivent aboutir à des constats comparables.

Les cinq canaux de test et leurs trois classes

OSSTMM 3 a fusionné en une seule méthode ce qui relevait auparavant de tests séparés par technologie. Le manuel regroupe les interactions en trois classes de sécurité et cinq canaux. Chaque canal dispose de son propre chapitre et de ses propres modules, mais applique le même déroulement et la même métrique, ce qui permet de comparer un test d'ingénierie sociale avec un test réseau.

• PHYSSEC (sécurité physique) : le canal humain, qui couvre l'ingénierie sociale et les processus portés par le personnel, et le canal physique, qui couvre bâtiments, barrières, serrures, surveillance et environnement.
• SPECSEC (sécurité du spectre) : le canal sans-fil, qui couvre Wi-Fi, Bluetooth, RFID et toute émission électromagnétique exploitable.
• COMSEC (sécurité des communications) : le canal télécommunications, qui couvre téléphonie, PBX et VoIP, et le canal réseaux de données, qui couvre systèmes, services et équipements joignables par IP.

Cette approche par canal évite un biais fréquent des tests d'intrusion : réduire la sécurité au seul réseau de données. Un attaquant qui obtient un badge par ingénierie sociale contourne le pare-feu sans jamais l'affronter. Dans un audit OSSTMM, ce scénario relève du canal humain puis du canal physique, et il doit figurer soit dans le périmètre, soit dans la liste explicite des éléments exclus.

Périmètre, vecteurs et règles d'engagement

Avant tout test, l'analyste définit le périmètre, appelé scope, puis le découpe en vecteurs et en canaux. Les règles d'engagement du manuel encadrent la relation avec le client : contrat et autorisation écrite, refus de vendre par la peur ou l'incertitude, respect de la vie privée, absence de dégradation des opérations au-delà de ce qui a été convenu et transparence sur les limites du test. Elles rejoignent largement les attentes des commanditaires français.

Les six types de tests définis par OSSTMM 3

L'OSSTMM classe les tests selon deux questions : que sait l'analyste de la cible, et que sait la cible du test ? La combinaison produit six types, plus précis que le vocabulaire courant de boîte noire, grise ou blanche. Le choix du type conditionne l'interprétation des résultats : un test annoncé ne mesure pas la capacité de détection, alors qu'un test non annoncé la met directement à l'épreuve.

1. Blind : l'analyste ne connaît ni les défenses ni les actifs ; la cible est informée et préparée. Le test évalue surtout la compétence de l'analyste.
2. Double blind : l'analyste ne sait rien et la cible n'est pas prévenue. Le test mesure à la fois l'exposition et la préparation des équipes de défense.
3. Gray box : l'analyste dispose d'informations partielles sur les défenses et les actifs ; la cible est informée. C'est souvent le cadre d'une évaluation de vulnérabilités.
4. Double gray box : l'analyste a une connaissance partielle ; la cible connaît le périmètre et la fenêtre de test, mais ni les canaux ni les vecteurs utilisés.
5. Tandem : analyste et cible partagent toutes les informations. Ce format convient à l'audit interne approfondi et à la revue de configuration.
6. Reversal : l'analyste connaît tout de la cible, qui ignore quoi, quand et comment elle sera testée. Le format s'apparente à un exercice de red team.

En pratique, la plupart des pentests commerciaux relèvent du gray box ou du double gray box. Le reversal correspond aux exercices décrits dans notre guide red team du pentest réseau interne, qui éprouvent la détection autant que la prévention. Indiquer le type exact dans le rapport évite les comparaisons trompeuses entre deux campagnes menées dans des conditions différentes.

Déroulement d'un audit OSSTMM : quatre phases et dix-sept modules

Le flux de travail d'OSSTMM 3 enchaîne quatre phases, chacune composée de modules dont les sorties alimentent les suivants. Le chapitre consacré aux réseaux de données compte dix-sept modules ; les autres canaux suivent la même logique avec des modules adaptés, par exemple une vérification de la formation à la place de la vérification de configuration pour le canal humain.

Phase d'induction : comprendre le cadre

La première phase réunit la revue de posture (contexte légal, réglementaire et culturel, politiques internes), la logistique (contraintes de réseau, de temps et de distance qui influencent les mesures) et la vérification de la détection active. Ce dernier module identifie les mécanismes susceptibles de réagir au test et de fausser les résultats, comme un système de prévention d'intrusion ou un service de filtrage en amont.

Phase d'interaction : mesurer la porosité

La deuxième phase établit les données de base du rav. L'audit de visibilité recense les cibles perceptibles depuis le vecteur, la vérification des accès identifie les points d'interaction, la vérification de la confiance repère les relations où une cible accepte une interaction sans authentification, et la vérification des contrôles constate les mécanismes de protection effectivement présents et opérants.

Phase d'enquête : examiner les informations

La troisième phase analyse ce que le périmètre laisse échapper et la façon dont il est administré : vérification des processus et de la configuration, validation des biens et contenus exposés, revue de la ségrégation entre informations privées et publiques, vérification des expositions et veille concurrentielle sur les informations accessibles publiquement. Elle relie les constats techniques aux pratiques réelles d'exploitation.

Phase d'intervention : éprouver les contrôles

La dernière phase teste la solidité des contrôles : vérification de la quarantaine, audit des privilèges, validation de la survivabilité, c'est-à-dire de la continuité de service sous contrainte, et revue des alertes et des journaux. Ce module final vérifie si les actions de l'analyste ont été vues, enregistrées et remontées, ce qui en fait un indicateur concret de la capacité de détection de l'organisation.

Le processus en quatre points et la trifecta de l'OSSTMM

Au-delà des phases et des modules, le manuel OSSTMM décrit aussi un processus en quatre points applicable à chaque test : l'induction déduit des faits à partir de l'environnement, l'enquête examine les traces émises par la cible, l'interaction provoque des réponses par des sollicitations standard ou inhabituelles, et l'intervention modifie les interactions entre ressources pour observer les réactions.

La trifecta complète ce processus par trois questions : comment fonctionnent les opérations, en quoi diffèrent-elles de ce que croit la direction, et comment devraient-elles fonctionner ? Y répondre oblige l'analyste à confronter le fonctionnement observé aux attentes des décideurs, ce qui transforme un constat technique en écart de gouvernance compréhensible et actionnable.

Le rav de l'OSSTMM : mesurer la surface d'attaque

Le rav, souvent écrit RAV, est la signature de l'OSSTMM. Développé en Risk Assessment Values dans la plupart des sources, il ne mesure pas un risque mais une surface d'attaque : la quantité d'interactions non protégées d'un périmètre, pour un vecteur donné. Le manuel l'oppose volontairement aux analyses de risque, jugées trop dépendantes d'opinions sur la probabilité et l'impact. Le calcul repose sur trois familles de données, toutes issues du test lui-même.

La porosité : visibilité, accès, confiance

La porosité correspond aux ouvertures opérationnelles nécessaires pour que le périmètre soit utile. Elle additionne la visibilité (les cibles perceptibles), l'accès (les points où une interaction est possible) et la confiance (les interactions acceptées sans identification entre cibles du périmètre). Une porosité élevée n'est pas une faute en soi : un site public doit être visible et accessible. Elle définit simplement la surface que les contrôles doivent couvrir.

Les dix contrôles opérationnels

Les contrôles sont répartis en deux classes de cinq. La classe A, dite interactive, regroupe l'authentification, l'indemnisation (dissuasion juridique ou assurance), la résilience (maintien de la protection en cas de défaillance), la subjugation (interactions limitées à des options définies par le propriétaire) et la continuité (maintien du service). La classe B, dite de processus, regroupe la non-répudiation, la confidentialité, le respect de la vie privée, l'intégrité et l'alarme.

Les cinq types de limitations

Les limitations décrivent ce qui affaiblit la protection. Une vulnérabilité permet un accès non autorisé, prive un ayant droit de son accès ou permet de se dissimuler. Une faiblesse altère un contrôle de classe A, une préoccupation un contrôle de classe B. Une exposition donne une visibilité injustifiée sur une cible ou un actif, et une anomalie désigne un élément inexpliqué qui échappe au fonctionnement normal des opérations.

Lire et documenter un rav : sécurité réelle et gabarit de comptage

Lire le résultat : la sécurité réelle

Pour obtenir le rav, métrique de surface d'attaque de l'OSSTMM, le tableur de l'ISECOM combine la porosité, les contrôles et les limitations avec des pondérations et des fonctions logarithmiques pour produire la sécurité réelle (Actual Security), exprimée en ravs. Une valeur de 100 ravs représente l'équilibre entre la porosité et les contrôles, sans limitation. En dessous, une partie de la surface d'attaque reste découverte ; au-dessus, les contrôles excèdent le besoin, ce qui peut ajouter interactions et complexité.

En mission, la discipline de comptage compte davantage que la formule. Le gabarit ci-dessous, à remplir pour chaque vecteur, structure les données collectées avant leur saisie dans le calculateur de l'ISECOM. Les valeurs null sont à remplacer par les comptages réels, et la rubrique des éléments non testés doit être complétée avant toute restitution au client.

audit_osstmm:
  version: "OSSTMM 3.02"
  type_de_test: double_gray_box
  canal: reseaux_de_donnees
  vecteur: internet_vers_dmz
  non_teste:
    - "API partenaires (hors fenêtre autorisée)"
    - "Canal sans-fil du site secondaire"
  porosite:
    visibilite: null
    acces: null
    confiance: null
  controles_classe_a:
    authentification: null
    indemnisation: null
    resilience: null
    subjugation: null
    continuite: null
  controles_classe_b:
    non_repudiation: null
    confidentialite: null
    vie_privee: null
    integrite: null
    alarme: null
  limitations:
    vulnerabilites: null
    faiblesses: null
    preoccupations: null
    expositions: null
    anomalies: null
  preuves: "journal horodaté et capture par point d'interaction"

Le rapport STAR et la traçabilité des résultats

Le STAR (Security Test Audit Report) est le rapport normalisé de l'OSSTMM. Il ne remplace pas le rapport technique détaillé : il le résume sous une forme comparable d'un test à l'autre, avec le périmètre, le type de test, les canaux, les vecteurs, les comptages de porosité, de contrôles et de limitations, le rav obtenu et, surtout, la liste de ce qui n'a pas été testé. Il doit être signé par le ou les analystes.

Cette signature engage la responsabilité de l'analyste sur les faits rapportés. Le STAR peut être soumis à l'ISECOM pour une certification officielle du test, et un test certifié n'a pas à prouver que tout le manuel a été suivi : il doit seulement montrer ce qui a été testé et ce qui ne l'a pas été. Pour la structure du rapport technique qui l'accompagne, consultez notre modèle de rapport de test d'intrusion en entreprise.

Pourquoi le « non testé » est un livrable à part entière

Un rapport qui tait ses exclusions laisse croire que l'absence de constat vaut absence de problème. Dans un audit OSSTMM, un élément non testé doit être déclaré comme tel, jamais présenté comme sûr. Cette exigence protège le client, qui sait précisément ce qu'il a acheté, et l'auditeur, dont la responsabilité se limite au périmètre réellement examiné. Elle facilite aussi la planification de la campagne suivante sur les zones laissées de côté.

OSSTMM, PTES, OWASP et NIST SP 800-115 : quel référentiel pour quel besoin ?

Les recherches associant PTES, OSSTMM et NIST en cybersécurité trahissent une confusion fréquente : ces référentiels ne sont pas concurrents, ils répondent à des questions différentes. L'OSSTMM dit quoi mesurer et comment le prouver ; PTES dit comment conduire une mission de pentest ; l'OWASP dit comment tester une application web ; le NIST encadre l'évaluation technique au sein d'un programme de sécurité.

PTES, OWASP WSTG et NIST : l'apport de chaque référentiel

PTES : le déroulé d'une mission

Le Penetration Testing Execution Standard (PTES) découpe une mission en sept sections : interactions préalables, collecte de renseignements, modélisation des menaces, analyse des vulnérabilités, exploitation, post-exploitation et rapport. Son site présente toujours le standard comme une v1.0 et renvoie vers des lignes directrices techniques séparées. Notre guide méthodologique PTES détaille chacune de ces étapes.

OWASP WSTG : la profondeur applicative

Le Web Security Testing Guide de l'OWASP est un projet phare de la fondation, dont la version stable est la 4.2 et dont la version 5.0 est en cours de développement. Il décrit des cas de test précis pour l'authentification, les sessions, la validation des entrées ou la logique métier. L'OSSTMM ne descend pas à ce niveau de détail : pour une application web, il fournit le cadre de mesure et le WSTG le contenu des tests.

NIST SP 800-115 et NIST CSF : le cadre de programme

Publié en septembre 2008 par le National Institute of Standards and Technology, le NIST SP 800-115 aide les organisations à planifier et conduire des tests techniques, à analyser les résultats et à définir des mesures correctives. Il classe les techniques en revue, identification et analyse de cibles, et validation des vulnérabilités. Le NIST Cybersecurity Framework 2.0, publié en février 2024, se situe un cran au-dessus : il organise la gouvernance et les fonctions de sécurité, dont l'évaluation fait partie.

Combiner plutôt que choisir

Une combinaison courante consiste à cadrer la mission avec PTES, à appliquer le WSTG sur les applications, à décrire le périmètre, les canaux et les exclusions selon l'OSSTMM, puis à citer le NIST SP 800-115 lorsque le client évolue dans un environnement anglo-saxon ou fédéral. Le même raisonnement vaut pour les objets connectés, où notre article sur le pentest IoT selon l'OWASP complète utilement la vision multicanal de l'OSSTMM.

OSSTMM 4 : ce qui change en 2026

Après seize ans sans nouvelle version publique, OSSTMM 4 se précise. Pete Herzog l'a présentée le 16 octobre 2026 lors de la conférence ICIST, à l'Université de technologie de Kaunas en Lituanie, et annonce une diffusion publique le 1er décembre 2026. En attendant, la page OSSTMM de l'ISECOM réserve un accès anticipé aux membres Gold et décrit déjà la nouvelle architecture, que résument les chiffres ci-dessous.

Une architecture en volumes thématiques

OSSTMM 4 abandonne le manuel unique au profit d'un volume Foundation, qui porte la théorie, la cartographie de la surface d'attaque, les règles d'engagement, le modèle de mesure, le format STAR et le flux en quatre phases, et de volumes par canal appelés Facets. Aux cinq canaux historiques s'ajoutent le web, le cloud, le mobile, l'IA, le code source, l'OT/ICS et l'IoT. Chaque volume se veut une spécification testable autonome.

Pour ces nouveaux canaux, les pratiques actuelles restent pleinement utiles en attendant les volumes dédiés. Notre méthodologie de pentest cloud sur AWS, Azure et GCP et celle du pentest industriel en environnement OT couvrent déjà ces surfaces, avec leurs contraintes propres de responsabilité partagée et de disponibilité des procédés.

OSSTMM 4 : nouveaux contrôles, nouveau rav et points de vigilance

Un modèle de contrôles et un rav reformulés

Selon l'ISECOM, la version 4 remplace l'ancien modèle par cinq attributs (caractéristiques, contexte, force, ressources, récit), un treillis de quinze contrôles rattachés à trois phases temporelles (intention, réaction, résolution) et quinze contrôles de confiance, pensés notamment pour les agents d'IA. Le rav est recalculé avec une normalisation en logarithme décimal, un score par dimension et un format JSON destiné à l'outillage.

Correspondances réglementaires et ambitions théoriques

L'ISECOM annonce des correspondances entre les constats OSSTMM et NIS 2, DORA, l'AI Act, le RGPD, PCI DSS, ISO 27001 ou le NIST CSF. L'institut présente aussi la version 4 comme dérivée de la théorie quantique de l'information et de la thermodynamique, en s'appuyant sur un article de Pete Herzog paru en 2026. Ces affirmations restent à éprouver : tant que la version publique n'est pas stabilisée, OSSTMM 3.02 demeure la référence contractuelle prudente.

OSSTMM et qualification PASSI : le cadre français

En France, l'OSSTMM n'est pas un référentiel réglementaire. Les commanditaires publics et de nombreux opérateurs régulés exigent plutôt la qualification PASSI (prestataire d'audit de la sécurité des systèmes d'information) délivrée par l'ANSSI, dont le référentiel en vigueur, la version 2.2, couvre l'audit d'architecture, de configuration et de code source, les tests d'intrusion et l'audit organisationnel et physique. L'OSSTMM s'insère alors comme méthode interne de l'auditeur, compatible avec ces exigences.

Six étapes pour une mission alignée sur la méthodologie OSSTMM

Appliquer l'OSSTMM (Open Source Security Testing Methodology Manual) ne demande pas de refondre toute une pratique de test d'intrusion. Les six étapes suivantes suffisent pour une première mission conforme à l'esprit du manuel, en conservant les outils et les référentiels techniques habituels de l'équipe d'audit.

1. Définir le périmètre, les vecteurs et les canaux, puis lister dès le départ ce qui est exclu et pourquoi.
2. Choisir le type de test (gray box, double gray box, reversal) et l'inscrire dans la convention d'audit.
3. Préparer une grille de comptage par vecteur : visibilité, accès, confiance, contrôles et limitations.
4. Exécuter les tests techniques avec les référentiels adaptés (PTES, WSTG, guides de l'ANSSI) en horodatant chaque action.
5. Consolider les comptages, calculer le rav avec le calculateur de l'ISECOM et vérifier sa cohérence avec les constats.
6. Rédiger le rapport technique et un STAR signé, puis planifier la campagne suivante sur le même périmètre.

Retour terrain : Cas typique rencontré en mission — une ETI habituée aux rapports classés par criticité découvre, avec l'approche OSSTMM, une section explicite sur ce qui n'a pas été testé : site de secours exclu, comptes privilégiés jamais fournis. Ces angles morts, jusque-là implicites, deviennent un sujet de gouvernance. La principale difficulté tient au double gray box : annoncer périmètre et fenêtre de test sans dévoiler canaux ni vecteurs exige un interlocuteur unique côté client et une discipline de communication tenue jusqu'au bout.

Limites et critiques de la méthodologie OSSTMM

L'OSSTMM a aussi ses détracteurs. En octobre 2020, Martin Albrecht et Rikke Bjerg Jensen, chercheurs à Royal Holloway, ont publié une critique académique de l'OSSTMM. Ils contestent l'idée que la sécurité se mesure comme une quantité, jugent le rav vide de sens, reprochent au manuel de remplacer le risque par une métrique de confiance ambiguë et critiquent sa vision de l'humain comme menace à surveiller.

Sur le terrain, d'autres limites sont bien connues. Le manuel est dense et demande un vrai temps d'appropriation. Le rav dépend de conventions de comptage qui, mal définies, rendent deux mesures incomparables. L'OSSTMM reste peu prescriptif sur les techniques, ce qui impose de l'adosser à d'autres guides. Enfin, la version 3 date de 2010 et ne traite pas nativement du cloud, des conteneurs ni de l'IA.

Ces critiques n'invalident pas l'apport principal de la méthode : rendre explicites le périmètre, les vecteurs, le type de test et les exclusions, puis vérifier les contrôles au lieu de les supposer. La position la plus réaliste consiste à utiliser l'OSSTMM comme cadre de rigueur et de traçabilité, et à présenter le rav comme un indicateur de tendance sur un périmètre stable plutôt que comme une note absolue.

Retour terrain : Cas typique rencontré en mission — face à un comité de direction, la liste de vulnérabilités classées par criticité ramène le débat au seul décompte des failles critiques restantes. Le rav présenté seul déroute : sans point de comparaison, sa valeur ne dit rien. Sa variation entre deux campagnes, mise en regard des décisions prises, capte en revanche l'attention. J'associe donc en restitution le rav, pour l'évolution, et quelques constats prioritaires traduits en impacts métier, pour la décision.

À lire aussi : l'audit réseau ; les tests red team TIBER-EU.

Questions fréquentes

Conclusion

L'OSSTMM reste, en 2026, la méthodologie la plus exigeante pour transformer un test de sécurité en mesure vérifiable : périmètre découpé en vecteurs et en canaux, type de test explicite, contrôles vérifiés plutôt que supposés, limitations classées selon leur effet et rapport STAR qui assume ce qui n'a pas été testé. Son rav, discuté, fournit néanmoins un indicateur de tendance utile sur un périmètre stable.

La méthode gagne à être combinée avec PTES pour la conduite de mission, l'OWASP WSTG pour les applications et le NIST SP 800-115 pour le cadre de programme. L'arrivée d'OSSTMM 4 en décembre 2026 mérite une veille attentive, sans précipitation contractuelle. Pour organiser concrètement un test et ses livrables, appuyez-vous sur notre méthodologie de pentest interne 2026.