OSSTMM
a metrics-driven view of the Open Source Security Testing Methodology Manual

OSSTMM: a measurable security test, not a checklist

The Open Source Security Testing Methodology Manual (OSSTMM) is published by the Institute for Security and Open Methodologies (ISECOM). It defines a security test by what is measured rather than by which tools are used: four channels (Human, Physical, Wireless, Telecommunications, Data Networks), a structured set of modules per channel, and a Risk Assessment Values (RAV) calculation that produces a reproducible operational security number. Where most methodologies describe a sequence of activities, OSSTMM describes a result to be evidenced and a calculation to support it.

OSSTMM sits next to other methodologies rather than replacing them. The Penetration Testing Execution Standard (PTES) gives the engagement workflow. The OWASP Top 10 and OWASP Testing Guide give the deep technical reference for web application testing. The NIST SP 800-115 technical guide gives the federal reference. The MITRE ATT&CK framework gives the adversary technique vocabulary. OSSTMM brings the channel model and the metric.

The four operational channels

OSSTMM is unusual in dividing the engagement by interaction channel rather than by asset type. The choice is deliberate: a single asset (a building, a person, a service) is reachable through different channels with different controls, and a methodology that does not separate them tends to under-test the human and physical paths because they are harder to scope. Capturing channel scope explicitly on the engagement keeps the report honest about what was tested and what was deliberately excluded.

The RAV: a reproducible attack surface number

The Risk Assessment Values (RAV) calculation is what gives OSSTMM its compliance and benchmarking appeal. The RAV produces a single number for the operational security state of the test target, derived from porosity (the unprotected attack surface), the controls observed, and the limitations identified. The number is reproducible when inputs are captured consistently across engagements, which makes year-on-year comparison and cross-portfolio reporting tractable. The buyer gets a metric that survives the report cycle; the consultancy gets a deliverable that demonstrates value over time, not just at delivery.

The five-way limitation classification (vulnerability, weakness, concern, exposure, anomaly) is also useful outside an OSSTMM engagement. It produces a sharper finding ledger than a single severity rating because not every issue is a vulnerability: a process gap is a concern, a logging gap is a weakness, an unintended information disclosure is an exposure. The findings management feature captures this kind of structured metadata so the OSSTMM ledger feeds directly into the RAV calculation rather than living in a side spreadsheet.

Engagement type: blind, gray box, tandem, reversal

OSSTMM is explicit that an engagement is interpretable only when the test type is captured. A finding rate from a blind test means something different from a finding rate from a tandem test, and a buyer comparing two engagements without that context will draw the wrong conclusion. Capture the engagement type on the rules of engagement record so the report stands on its own context.

The module set per channel

OSSTMM tests each channel through a structured set of modules. The list below summarises the module categories that appear across the standard. Tracking module coverage per channel on the engagement record evidences breadth, not just the modules the assigned tester prefers, and the audit trail makes the RAV inputs verifiable.

Rules of engagement: signed, channel-aware, before any active testing

OSSTMM expects a signed rules of engagement document covering scope, test type, channel coverage, allowed techniques, escalation, and reporting expectations before any active testing. Channel awareness matters: the rules of engagement for a Wireless channel test carry different authorisations than a Data Networks test, and the rules of engagement for a Human channel test carry different stop-test conditions than a Physical channel test. The free rules of engagement template provides the operational ROE document that an OSSTMM engagement expects to be signed before any reconnaissance starts.

Reporting: the STAR and the technical body

OSSTMM defines a Security Test Audit Report (STAR) format that summarises the engagement on a single page or two: scope, channels tested, test type, RAV, and an attestation. The STAR is the buyer-facing executive artefact. The full technical report covers per-finding evidence, reproduction, and remediation. Both belong on the engagement record so the deliverable is reproducible and the audit trail is intact. The pentest report writing guide and the penetration testing report template cover the structural questions in more depth, and the AI report generation feature composes the deliverable from the underlying engagement, channel coverage, RAV inputs, and finding evidence rather than from a blank page.

How OSSTMM compares to PTES, OWASP, NIST 800-115, and ATT&CK

OSSTMM is rarely run in isolation. The strongest pentest programmes pair it with at least one workflow methodology and one technique catalogue. The contrast below is a working operator's view: the practitioner question is which standard to combine with OSSTMM, not which to pick instead of it.

Where SecPortal fits in an OSSTMM-aligned engagement

SecPortal is the operating layer for an OSSTMM-aligned engagement. The platform handles scope, channel coverage, module execution evidence, RAV inputs, and the STAR delivery so the engagement runs as a single workflow rather than a long email thread with attachments. For consultancies running OSSTMM engagements on behalf of multiple clients, the security consultants workspace bundles that with branded client portals and findings deduplication across engagements.

Looking for the engagement workflow itself, end-to-end? The penetration testing use case captures how SecPortal turns an OSSTMM-shaped engagement into a structured record covering scope, channels, modules, findings, retests, and the deliverable. For penetration testing firms running OSSTMM consistently across a client portfolio, the same engagement record carries the RAV inputs forward through retests so the year-on-year comparison the methodology promises is operationally tractable.

Need to position OSSTMM alongside a broader methodology comparison? The penetration testing methodology guide covers OSSTMM, PTES, OWASP, and NIST SP 800-115 side by side, including where each one is the strongest fit and how they tend to be layered in practice.