Testing Methodology
PTES + NIST SP 800-115, the OWASP Testing Guides (with ASVS / MASVS verification when source is provided, plus the OWASP AI Testing Guide for AI/LLM targets), and MITRE ATT&CK / ATLAS - the standards that guide every TurboPentest pentest, the same way they guide IntegSec's human-led engagements.
Last reviewed: 2026 Q2
PTES - Penetration Testing Execution Standard
PTES is the de facto industry workflow for pentest engagements. Every TurboPentest pentest follows the seven PTES phases - five run automatically by Paladin, two (pre-engagement and reporting) are bookended by the platform. See what is PTES for a plain-language explainer of the standard itself.
- 1
Pre-engagement Interactions
Platform-bookendedAutomated via the /quote and /start checkout flow: scope agreed, target verified, BAA signed for healthcare scopes, exclusions logged. The platform bookends this phase so that every Paladin engagement starts with the same pre-engagement controls a manual IntegSec engagement would have.
- 2
Intelligence Gathering
Paladin agentPaladin's reconnaissance agent runs subdomain enumeration (Subfinder), HTTP probing (HTTPX), technology fingerprinting, port scanning (Naabu), TLS analysis (TestSSL), and WAF detection (Wafw00f). Output is a normalized attack-surface map fed forward to threat modeling.
- 3
Threat Modeling
Paladin agentPaladin's threat-modeling agent builds a STRIDE-based threat model from the discovered surface: identifies attack paths, prioritizes exploit candidates, and assigns each path a likelihood and impact bucket so vuln-analysis spends its tool-budget on the highest-risk surfaces.
- 4
Vulnerability Analysis
Paladin agentFifteen platform components run in parallel - 14 industry scanning tools (OWASP ZAP, Nuclei, Nikto, FFUF, OpenVAS, IntegSec PentestTools, plus white-box source-code tools when GitHub is connected) orchestrated by Paladin AI as the 15th component. Findings are deduplicated across tools, false-positives filtered, and each candidate is scored before exploitation attempts.
- 5
Exploitation
Paladin agentPaladin's exploitation specialist agent attempts to confirm each candidate finding with a proof-of-concept. Findings without successful exploitation stay in vuln-analysis (and are reported with that lower confidence); confirmed exploits move to the exploitation phase and ship with reproducible PoC evidence.
- 6
Post Exploitation
Paladin agentPaladin's chaining agent looks for related findings: chained attacks, lateral movement opportunities, credential reuse, privilege escalation paths. Single-finding reports miss the way real attackers compose exploits - this phase produces the multi-step attack narratives that change a CISO's risk posture.
- 7
Reporting
Platform-bookendedAutomated PDF generation: executive summary, findings with severity and CVSS, PTES phase tag, OWASP Testing Guide reference, MITRE ATT&CK technique IDs, OWASP Top 10 classification, and an attestation letter. The platform bookends this phase the same way the kickoff phase is bookended.
NIST SP 800-115 - Federal-Recognized Testing Workflow
NIST SP 800-115 is the federal government's recognized standard for information security testing. We follow its four-phase model end-to-end. Where PTES gives the granular execution workflow, NIST SP 800-115 gives the high-level vocabulary auditors and federal buyers expect to see in every assessment.
- Phase 1 - Planning
Scope agreed, target verified, exclusions logged. Maps to PTES Pre-engagement Interactions.
- Phase 2 - Discovery
Reconnaissance, fingerprinting, attack-surface mapping. Maps to PTES Intelligence Gathering and Threat Modeling.
- Phase 3 - Attack
Vulnerability identification and exploitation with proof-of-concept evidence. Maps to PTES Vulnerability Analysis + Exploitation + Post-Exploitation.
- Phase 4 - Reporting
Findings, evidence, severity ratings, remediation, attestation letter. Maps to PTES Reporting.
OWASP Testing Guides - Per Target Type
OWASP publishes detailed testing guides for different application types. TurboPentest selects the relevant guide based on what your target actually is - a web app, an API, an AI / LLM product, or a mobile app - and Paladin picks the matching category set before scoping.
Web applications - OWASP WSTG (Web Security Testing Guide)
The primary guide for web app pentests. Categories Paladin covers:
WSTG-INFO Information GatheringWSTG-CONF Configuration & Deployment ManagementWSTG-IDNT Identity ManagementWSTG-ATHN AuthenticationWSTG-ATHZ AuthorizationWSTG-SESS Session ManagementWSTG-INPV Input ValidationWSTG-ERRH Error HandlingWSTG-CRYP CryptographyWSTG-BUSL Business Logic TestingWSTG-CLNT Client-side TestingWSTG-APIT API TestingEach finding on a web app target carries the most specific WSTG category code (e.g. WSTG-AUTHN-03 Testing for Weak Lock Out Mechanism). For the full category-by-category breakdown, see the OWASP Top 10 hub.
APIs - OWASP API Security Top 10 (2023)
For API-only or API-heavy targets. Paladin classifies findings against:
API1:2023Broken Object Level AuthorizationAPI2:2023Broken AuthenticationAPI3:2023Broken Object Property Level AuthorizationAPI4:2023Unrestricted Resource ConsumptionAPI5:2023Broken Function Level AuthorizationAPI6:2023Unrestricted Access to Sensitive Business FlowsAPI7:2023Server Side Request ForgeryAPI8:2023Security MisconfigurationAPI9:2023Improper Inventory ManagementAPI10:2023Unsafe Consumption of APIs
See the OWASP API Security Top 10 hub for a page on each category.
AI / LLM applications - OWASP AI Testing Guide (primary)
The OWASP AI Testing Guide v1.0 (November 2025) defines 32 testing procedures across four layers: AI Application (AITG-APP), AI Model (AITG-MOD), AI Infrastructure (AITG-INF), and AI Data (AITG-DAT). Not every procedure is testable from the same vantage point - black-box external testing covers different procedures than white-box source-code testing, and several procedures are governance reviews rather than penetration tests. Here's our honest coverage breakdown:
| Coverage | Count | What's in this bucket |
|---|---|---|
| Covered today (black-box) | ~10 | Prompt injection (AITG-APP-01), indirect prompt injection (APP-02), sensitive data leak (APP-03), unsafe outputs (APP-05), agentic behavior limits (APP-06), prompt / system-prompt disclosure (APP-07), model extraction surface checks (APP-09), content bias (APP-10), hallucinations (APP-11), toxic output (APP-12), over-reliance probes (APP-13). |
| When source code is provided | ~7 | Input leakage (APP-04), embedding manipulation (APP-08), runtime model poisoning (MOD-02), poisoned training sets (MOD-03), supply-chain tampering verification (INF-01), fine-tuning poisoning (INF-05), harmful content in training data (DAT-04). White-box artifacts - pipelines, training data, model files - are required to test these meaningfully. |
| Governance / out of pentest scope | ~7 | Explainability and interpretability (APP-14), plugin boundary policy reviews (INF-03), capability-misuse policy (INF-04), dataset diversity & coverage audits (DAT-03), data minimization & consent flows (DAT-05), AI ethics governance, harmful-content policy audits. These are program audits - not penetration tests - and we surface them in scoping but don't pretend a pentest delivers them. |
| On roadmap | ~8 | Evasion attacks (MOD-01), membership inference (MOD-04), inversion attacks (MOD-05), robustness to OOD inputs (MOD-06), goal alignment (MOD-07), resource exhaustion at the model layer (INF-02), dev-time model theft (INF-06), training data exposure / runtime exfiltration (DAT-01, DAT-02). Validated attack patterns are added as the OWASP working group publishes them and as the Paladin agent's methodology is extended. |
When a procedure is on roadmap, we say so. The AITG was published in November 2025; we covered the testable subset at launch and are expanding coverage with the Paladin agent's methodology updates as new attack patterns are validated by the OWASP working group.
Each AI/LLM finding still carries the most specific AITG procedure code (e.g. AITG-APP-01 Testing for Prompt Injection) - the code identifies which procedure produced the evidence, while the coverage buckets above describe which procedures Paladin can run today versus which require source code, are governance audits, or are still being added.
Vulnerability classification - OWASP LLM Top 10 (2025)
Where AI Testing Guide gives the testing procedure, the OWASP LLM Top 10 gives the vulnerability class. Both apply on AI/LLM findings - AITG codes the test that produced the evidence; LLM Top 10 codes what kind of weakness it is:
LLM01:2025Prompt InjectionLLM02:2025Sensitive Information DisclosureLLM03:2025Supply ChainLLM04:2025Data and Model PoisoningLLM05:2025Improper Output HandlingLLM06:2025Excessive AgencyLLM07:2025System Prompt LeakageLLM08:2025Vector and Embedding WeaknessesLLM09:2025MisinformationLLM10:2025Unbounded Consumption
See the OWASP LLM Top 10 hub for a page on each category.
Red-team methodology - OWASP Generative AI Red Teaming Guide
Complements AI Testing Guide as the offensive playbook for adversarial probing of generative AI - jailbreak chains, model-behavior probes, agent abuse, multi-turn coercion, and RAG poisoning patterns. Used by Paladin's AI/LLM specialist agent during exploitation.
Mobile - OWASP MASTG (Mobile Application Security Testing Guide)
For mobile application targets. Categories Paladin covers:
MASTG-STORAGE StorageMASTG-CRYPTO CryptographyMASTG-AUTH AuthenticationMASTG-NETWORK Network CommunicationMASTG-PLATFORM Platform InteractionMASTG-CODE Code QualityMASTG-RESILIENCE ResilienceWhen source code is provided for mobile targets, findings are also verified against the OWASP MASVS (Mobile Application Security Verification Standard) levels: L1 (standard), L2 (defense-in-depth), and R (resilience against client-side threats like reverse engineering and tampering). See the OWASP Mobile Top 10 hub for a page on each category.
When Source Code Is Provided - Verification Standards
Customers can connect their GitHub repository for white-box source-code analysis. When source is provided, additional verification standards apply on top of the black-box testing methodology above.
OWASP ASVS - Application Security Verification Standard
ASVS defines three verification levels for web and API applications. When Paladin runs source-code tools (Opengrep, Gitleaks, Grype) against a connected repo, each source-code finding is classified to the appropriate ASVS level via the asvsLevel field on that finding.
L1- Basic verification appropriate for all software (opportunistic-attacker threat model).L2- Standard verification for applications handling sensitive data; the recommended target for most apps.L3- Advanced verification for high-value targets (critical infrastructure, financial systems, life-safety).
Web/API findings without source-code provenance do not carry an ASVS level - the standard requires source visibility to apply meaningfully.
OWASP MASVS - Mobile Application Security Verification Standard
The mobile counterpart to ASVS. When source is provided for a mobile target, findings are classified to MASVS levels via the masvsLevel field.
L1- Standard security for typical mobile apps.L2- Defense-in-depth for sensitive mobile apps (banking, health, enterprise).R- Resilience against client-side threats (reverse engineering, tampering, hooks, runtime instrumentation).
OWASP Code Review Guide
The OWASP Code Review Guide is the reference methodology for the source-code analysis itself - what to look for, how to grep for it, how to verify hits, and how to write up the finding. Source-code findings produced by Paladin cite the OWASP Code Review category in the finding details where applicable.
MITRE ATT&CK - Adversary Technique Mapping
Knowing a vulnerability exists is half the picture. Knowing how an attacker would exploit it is the other half. Every TurboPentest finding is mapped to one or more MITRE ATT&CK techniques (T#### IDs), so security teams can correlate findings with adversary playbooks and threat intelligence.
MITRE ATT&CK is a knowledge base of adversary tactics and techniques used in real-world attacks. Maintained by the MITRE Corporation, it's the lingua franca for SOC analysts, threat hunters, and red teams.
| Technique ID | Name | Typical TurboPentest finding |
|---|---|---|
| T1190 | Exploit Public-Facing Application | Common with confirmed RCE / SQLi / SSRF findings |
| T1078 | Valid Accounts | Credential reuse, weak default credentials |
| T1110 | Brute Force | Weak rate limiting, missing lockout |
| T1539 | Steal Web Session Cookie | Session hijacking, missing Secure / HttpOnly flags |
| T1505.003 | Web Shell | Confirmed file upload + execution |
| T1556 | Modify Authentication Process | Auth bypass findings |
| T1059.007 | JavaScript Execution | XSS findings |
| T1574 | Hijack Execution Flow | Insecure deserialization |
Multiple techniques per finding are common - a confirmed SQLi might map to both T1190 and T1003 if it leads to credential dumping. Sub-techniques (T1505.003) are preferred over parent techniques (T1505) where applicable.
MITRE ATLAS - Adversarial Threat Landscape for AI Systems
For AI/LLM targets, findings are mapped to MITRE ATLAS technique IDs (format AML.T####) instead of (or in addition to) ATT&CK techniques. ATLAS is the AI-specific adversary technique catalog maintained by MITRE - the AI equivalent of ATT&CK.
Examples: AML.T0051 LLM Prompt Injection, AML.T0060 Erode ML Model Integrity. Paladin's schema accepts both T#### and AML.T#### IDs in the mitreAttackTechniques array; the two can mix on a single finding (e.g., a chained AI exploit that lands via prompt injection then pivots to credential reuse).
OWASP Top 10 - Compliance-Friendly Cross-Reference
Every finding also carries an OWASP Top 10 2025 classification. The OWASP Top 10 is the most-cited security standard in compliance frameworks (SOC 2, ISO 27001, PCI DSS) - auditors recognize it. The deeper OWASP Testing Guides above tell you what was tested; OWASP Top 10 tells your auditor.
Findings are tagged with A##:2025 codes (e.g. A05:2025 Injection, A02:2025 Security Misconfiguration). These codes flow into the compliance mapping document.
See also: for how findings map to specific compliance framework controls (SOC 2 TSC, ISO 27001 Annex A, PCI DSS v4.0 Req 11.4.x, HIPAA Security Rule), see the compliance mapping methodology.
How Paladin Uses This Methodology
Paladin is TurboPentest's AI agent - but it's not freelancing. Every finding it produces must conform to the methodology defined above.
- Phase tagging is required
Paladin's report schema requires a PTES phase on every finding. Findings without a phase fail validation and don't ship.
- Testing Guide reference is required
Paladin determines target type (web / API / AI / mobile) at scoping and selects the relevant OWASP Testing Guide. Every finding carries both a category code (e.g.
WSTG-AUTHN-03) and the human-readable category name. - MITRE ATT&CK technique is required
Paladin maps every finding to at least one MITRE ATT&CK technique ID. Sub-techniques are preferred where applicable.
- OWASP Top 10 is required
As before, every finding gets an
A##:2025code for compliance reporting. - Validation is enforced
The Paladin report validator (
src/lib/paladin/validate-report.ts) rejects reports with missing or malformed methodology fields. The pipeline does not deliver a report unless every finding meets the schema. - Methodology is logged
The PDF report renders all four classifications visibly on every finding, plus a methodology paragraph in the report intro citing the standards used.
References & Versions
Methodology last reviewed: 2026 Q2. Updated when standards revisions ship - version-controlled in git.
Companion document: Compliance mapping methodology - how the standards above map to SOC 2, ISO 27001, PCI DSS, and HIPAA controls.
About this reference
These security references are maintained by IntegSec, an offensive-security firm whose team holds CISSP, OSCP, and OSCE certifications and has run thousands of penetration tests. Content is kept current as tools, standards, and attack techniques evolve.