Penetration Testing: Disclosure and Career, Anti-Patterns, Contested Questions, Currency, and Canon¶
Part 4 of 4 of the Penetration Testing and Offensive Security reference (plugin
penetration-testing), covering §14–§20. Sibling skills:pentest-authorization-scoping-and-methodology(§0–§3),pentest-technical-domains(§4–§9),pentest-red-team-ai-and-reporting(§10–§13). Section numbers are shared across the set; a reference written as §N →skillpoints into that sibling skill.Currency: Verified August 2026. See §17 below for the currency snapshot and what goes stale first.
⚠️ THE PREREQUISITE FOR EVERYTHING BELOW. The entire difference between this profession and a felony is documented, informed authorization from someone with the authority to grant it, for a defined scope, in a defined window. Not implied consent. Not a verbal go-ahead. Not "the client seemed fine with it." Not a bug bounty scope you read quickly. §1 →
pentest-authorization-scoping-and-methodologyis the section that matters most, and it is first for that reason.This document is written for people doing authorized work — in-house security teams, consultancies, bug bounty participants operating inside a published scope, and the people who hire and manage them. It is a methodology, process, and professional practice reference. It deliberately does not contain exploitation recipes, working exploit code, or techniques for evading specific defensive products; those live in engagement-specific research, and the value of a reference like this is in the parts practitioners actually get wrong — scoping, method, evidence, and communication.
This is not legal advice. §1 →
pentest-authorization-scoping-and-methodologytells you what to ask your counsel, not what your obligations are in your jurisdiction.How to read this. Three markers: - [DURABLE] — professional practice, methodology, or a lesson the field has settled. - [VERSIONED] — regulation, tooling, market state. Verify. - [CONTESTED] — practitioners genuinely disagree.
The three framings that organize everything below: 1. The report is the product. The client is not buying access to their systems — they already have that. They are buying a prioritized, reproducible, actionable understanding of their risk. A brilliant compromise written up badly is a failed engagement (§13 →
pentest-red-team-ai-and-reporting). 2. Your job is to model a threat, not to win. "I got domain admin" is not the goal; "here is how an attacker with these capabilities would reach these assets, here is what detected them and what didn't, and here is what to fix first" is. 3. You are operating in someone's production environment and you can break it. Professional restraint — knowing what not to run — is a larger part of competence than the ability to run anything.
§14. Disclosure, Career, and Certification¶
14.1 Coordinated disclosure¶
[DURABLE] The norm is coordinated disclosure: report privately, agree a timeline (90 days is the common default), and publish after the fix or the deadline. The tension is real and permanent — vendors want longer, users benefit from pressure, and researchers sit in between.
The pipeline: report to the vendor (or a CNA, or the CNA of last resort) → CVE ID assigned → CVSS scored → published to NVD and increasingly EUVD. ⚠️ Getting a vendor to respond is often harder than finding the bug; CERT/CC and national CSIRTs coordinate when direct contact fails.
⚠️ Vendors still sometimes respond with lawyers. That this remains true is illustrated by Microsoft receiving the "lamest vendor" Pwnie Award at the 2026 Pwnie Awards for threatening security researchers with legal action. Document everything, keep communications professional and in writing, and get counsel before publishing anything contentious.
14.2 Getting in¶
[DURABLE] The path is: fundamentals → labs → certification → entry role. Skipping the fundamentals produces someone who can run tools and cannot explain results, which is the most common failure mode among junior testers.
Fundamentals you cannot skip: networking (TCP/IP, DNS, HTTP — properly), operating systems (Linux and Windows internals), at least one scripting language (Python), how web applications and authentication actually work, and how defenders work — because you cannot meaningfully test detection you don't understand.
Practice legally: HackTheBox, TryHackMe, PortSwigger Web Security Academy
(free, and the best structured web-testing training available), PentesterLab,
OverTheWire, VulnHub, CTFs, and your own lab. ⚠️ Never practice on systems you
don't own or aren't explicitly authorized to test (§1 → pentest-authorization-scoping-and-methodology) — this is where careers end before
they begin.
Certifications, roughly by role signal:
| Cert | Signal |
|---|---|
| OSCP (and OSCP+) | The practical benchmark employers look for. Hands-on exam |
| OSEP / OSWE / OSED | Advanced OffSec specializations |
| CRTO / CRTP / CRTE | Red team and AD operations — well-regarded practically |
| CREST (CRT, CCT, and the STAR-FS/CBEST routes) | Required or expected for regulated work in the UK and increasingly the EU (§2.3 → pentest-authorization-scoping-and-methodology) |
| GPEN / GWAPT / GXPN (SANS/GIAC) | Expensive, thorough, well-recognized |
| PNPT, CPTS/HTB CBBH | Newer, practical, increasingly credible |
| CEH | Broadly recognized by HR, less respected by practitioners |
| CISSP | Management and breadth, not a testing credential |
[DURABLE] For regulated work, accreditation is not optional signalling — it's a procurement gate. DORA Article 27 sets tester requirements, and the practical benchmarks cited for red team members are OSCP, OSEP, and CRTO, with CREST accreditation at the firm level.
⚠️ Certifications get you interviews. Demonstrated work gets you hired — a public write-up portfolio, CTF results, disclosed CVEs, or bug bounty history.
§15. Anti-Patterns¶
| Anti-pattern | Why |
|---|---|
| Any technical activity before signed authorization | This is the line between the profession and a crime (§1 → pentest-authorization-scoping-and-methodology) |
| Verbal or implied permission | Unenforceable and undefendable |
| Authorization from someone without the authority to grant it | Not authorization (§1.2 → pentest-authorization-scoping-and-methodology) |
| Testing third-party systems your client doesn't own | Cloud infra, SaaS, shared hosting, supply chain (§1.3 → pentest-authorization-scoping-and-methodology) |
| Relying on the DOJ charging policy as protection | It explicitly creates no enforceable right (§1.1 → pentest-authorization-scoping-and-methodology) |
| Working a bug bounty program with no safe harbour language | You have not been authorized (§1.4 → pentest-authorization-scoping-and-methodology) |
| Going just outside a bug bounty scope "to confirm" | Voids protection entirely |
| Exfiltrating more data than needed to prove the finding | A liability you now hold (§1.5 → pentest-authorization-scoping-and-methodology) |
| Concealing something you broke | Recoverable incident → career-ending failure |
| Running DoS or resource exhaustion without written permission | §6 → pentest-technical-domains |
| Aggressive scanning of OT/ICS, medical, or embedded devices | Safety issue, not a professionalism issue (§9.4 → pentest-technical-domains) |
| Leaving persistence or test accounts behind | Causes incidents months later (§11.1 → pentest-red-team-ai-and-reporting) |
| No contemporaneous notes | You can't answer "was that you?" or write reproduction steps |
| Not providing source IPs for deconfliction | Your traffic is indistinguishable from an attack (§3.2 → pentest-authorization-scoping-and-methodology) |
| Buying a red team before basic testing | Premium rates for findings an assessment would give you (§11.2 → pentest-red-team-ai-and-reporting) |
| Testing staging and reporting on production | You tested a system that doesn't exist (§2.2 → pentest-authorization-scoping-and-methodology) |
| Calling a vulnerability scan a penetration test | Mislabelling is endemic and it misleads buyers (§2.1 → pentest-authorization-scoping-and-methodology) |
| Pasting scanner output in as verified findings | Fastest route to being dismissed (§13.2 → pentest-red-team-ai-and-reporting) |
| Rating everything critical | Destroys prioritization and credibility |
| CVSS base score as the priority order | Ignores the client's environment entirely |
| "Validate input" as remediation | Not actionable |
| Reporting fifteen instances instead of one systemic cause | Fixes fifteen endpoints, not the process (§13.2 → pentest-red-team-ai-and-reporting) |
| Naming individual employees in a phishing report | Unprofessional, harmful, and an HR problem (§10 → pentest-red-team-ai-and-reporting) |
| Distressing pretexts (fake layoffs, family emergencies) | Real harm; "an attacker would" isn't sufficient justification |
| Impersonating law enforcement | §10 → pentest-red-team-ai-and-reporting |
| Physical engagement without the letter on your person | You may be detained; plan for it |
| Optimizing for "we got domain admin" | It's not the goal (§0 → pentest-authorization-scoping-and-methodology framing 2) |
| No negative findings in the report | "We tested X and it was solid" is valuable and rare |
| Practising on systems you don't own | Where careers end before they start (§14.2) |
| Autonomous agents with unbounded scope on live systems | An agent that adapts can wander out of scope — and it's your authorization (§12.2 → pentest-red-team-ai-and-reporting) |
| Treating AI agent output as verified findings | Verify everything you report |
§16. Contested Questions¶
16.1 Black box vs. grey/white box. §2.1 → pentest-authorization-scoping-and-methodology. The realism/coverage trade-off, and the
practitioner majority favouring more information for anything that isn't specifically a
detection test.
16.2 Red team vs. purple team. §11.2 → pentest-red-team-ai-and-reporting. Genuine disagreement, with the strong argument
being that purple delivers more improvement per dollar and the strong counter being that
only an unannounced exercise tests real response.
16.3 Point-in-time vs. continuous testing. Point-in-time: depth, a defensible artifact, regulatory fit. Continuous: matches how fast attack surfaces actually change — and the case is made pointedly that a formal TLPT is a snapshot while your attack surface changes every sprint, and a three-year cycle "is a regulatory compromise, not based on how often the threat landscape changes." The honest answer is both, at different depths.
16.4 Will AI replace penetration testers? §12.2 → pentest-red-team-ai-and-reporting — the evidence genuinely cuts both ways
and the marketing is loud. The defensible reading is that the mechanical work compresses
and the judgment work doesn't, which shifts the skill profile rather than eliminating it.
16.5 Disclosure timelines. 90 days is convention, not consensus. Vendors argue complex fixes take longer; researchers argue that without pressure, fixes don't ship.
16.6 Are certifications worth it? For: they're a procurement gate in regulated work and an HR filter everywhere else. Against: expensive, and they measure exam performance. Both are true; treat them as a ticket rather than an education.
16.7 Does offensive security training make the world less safe? The perennial dual-use argument. The field's settled position — that defenders must understand attacks, and that the knowledge is asymmetrically more useful to defenders because attackers already have it — is the reason this profession exists, but it isn't unanimous and it deserves to be held thoughtfully rather than as a slogan.
§17. Currency Snapshot — verified August 2026¶
| Thing | Status as of Aug 2026 | Decay risk |
|---|---|---|
| CVE program | ⚠️ Near-death in April 2025 when MITRE's contract was hours from expiring; CISA executed a contract option at the last minute. Funding has since been secured — CISA's acting director stated in 2026 that the program "is fully funded." A source close to the program described the agreement as reassuring but "a mystery contract with a mystery number." Long-term governance remains genuinely unsettled; the CVE Foundation was formed as an alternative structure | High |
| The alternatives that emerged | EUVD (ENISA's European Vulnerability Database) became fully operational 13 May 2025, drawing on open sources plus national CSIRT advisories and vendor guidance, with exploited-vulnerability markings. GCVE (Global CVE Allocation System, CIRCL.eu) launched as a complement. ENISA is one of 453 CNAs | Medium |
| Vulnerability volume | 40,000+ CVEs per year and rising; MITRE issues 24,000+ identifiers annually | Annual |
| EU CRA reporting | ⚠️ From September 2026 it becomes mandatory in the EU for manufacturers to report actively exploited vulnerabilities via the Cyber Resilience Act's Single Reporting Platform | High |
| DORA TLPT | Article 26: designated EU financial entities, at least every 3 years, production systems, TIBER-EU methodology. ⚠️ You do not self-select — your national TLPT authority notifies you; first wave of notifications expected in 2026. Full cycle 9–14 months provider-to-attestation. 200+ designated entities vs. fewer than 40 qualified red team providers by one 2026 estimate; a competent authority can reject a TLPT by an unqualified provider, forcing a restart. UK CBEST/STAR-FS recognized. DORA permits internal testers under conditions and mandates outsourcing every third test; TIBER-EU currently prohibits internal testers | Medium |
| Legal protection for researchers | DOJ CFAA charging policy directs declination for good-faith research but explicitly creates no enforceable right. Civil suits are reported as a more common threat than federal criminal prosecution. DMCA §1201 exemption exists for research. [VERSIONED] 2026 academic work argues European protection remains fragmented, citing cases in the Netherlands, Malta, and Germany, and jurisdictions like Italy lacking an exemption | Medium |
| Safe harbour | HackerOne's Gold Standard Safe Harbor aligned as of 1 January 2026 with recent legal developments including the Netherlands NCSC's disclosure policy. CISA BOD 20-01 requires US federal civilian agencies to publish a VDP | Low |
| Vendor behaviour | ⚠️ Microsoft received the "lamest vendor" Pwnie Award at the 2026 Pwnie Awards for threatening security researchers with legal action — legal retaliation is not a historical problem | Medium |
| AI adoption in offensive work | Bugcrowd 2026: 82% of hackers use AI in their workflows. HackerOne: 54% lack the skills to effectively prompt, evaluate, and course-correct AI tools. Reported ~35% reduction in time-to-report (Bishop Fox data) | High |
| AI capability benchmarks | XBOW's autonomous agent took #1 on HackerOne June 2025, 1,060+ valid submissions. ARTEMIS (Dec 2025) reportedly beat 9 of 10 human pentesters on a live 8,000-host network at $18/hour. A Feb 2026 LLM-agent benchmark on a 5-host AD environment compromised 4 of 5 hosts for $28.50 in API fees, running paths concurrently. ~70 new offensive AI tools launched in ~18 months | High |
| The counterweight | Synack CTO: AI does broad recon well, but "where AI often falls short is in contextual understanding and creativity — humans infer business logic that AI will sometimes miss." Agentic tooling raises real scope-control risk: an adaptive agent can wander outside its intended boundary | High |
| AI-generated report volume | A live strain on maintainers and triage teams, raised at RSAC 2026 in the context of the CVE program | High |
Goes stale fastest: everything in §12 → pentest-red-team-ai-and-reporting and the AI rows above; CVE governance;
DORA TLPT capacity and notification waves. Essentially never stale: §1 → pentest-authorization-scoping-and-methodology (authorization),
§2.2 → pentest-authorization-scoping-and-methodology (scoping questions), §3 → pentest-authorization-scoping-and-methodology (methodology), §5.1 → pentest-technical-domains's category structure, §13 → pentest-red-team-ai-and-reporting (reporting),
§15.
§18. The Canon¶
18.1 Methodology and standards — read these directly¶
OWASP Web Security Testing Guide (the working reference for §5 → pentest-technical-domains), OWASP MASTG/MASVS,
OWASP API Security Top 10, OWASP Top 10 (awareness, not methodology), OWASP LLM
and Agentic Applications material (§12.1 → pentest-red-team-ai-and-reporting), PTES, NIST SP 800-115, OSSTMM,
MITRE ATT&CK and ATT&CK Navigator, CWE, CVSS and EPSS, TIBER-EU and
CREST's TLPT guidance, and CISA's vulnerability disclosure and Product Security Bad
Practices material.
18.2 Books¶
| Author | Work | Why |
|---|---|---|
| Stuttard & Pinto | The Web Application Hacker's Handbook | Dated in specifics, still the best explanation of how to think about web testing |
| PortSwigger | Web Security Academy (free) | The modern successor in practice. Structured, hands-on, current |
| Peter Kim | The Hacker Playbook series | Practical engagement flow |
| Georgia Weidman | Penetration Testing: A Hands-On Introduction | The standard first book |
| OccupyTheWeb / various | Linux Basics for Hackers | Fundamentals (§14.2) |
| Chris Sanders | Practical Packet Analysis | Networking properly |
| Bratus, Erickson | Hacking: The Art of Exploitation | Low-level foundations |
| Dowd, McDonald, Schuh | The Art of Software Security Assessment | The deep code-review reference |
| Christopher Hadnagy | Social Engineering: The Science of Human Hacking | §10 → pentest-red-team-ai-and-reporting, including the ethics |
| Kim Zetter | Countdown to Zero Day | Why this field has stakes |
| Andy Greenberg | Sandworm | Threat actors as they actually operate |
| Cliff Stoll | The Cuckoo's Egg | Still the best narrative introduction to the discipline |
18.3 Practice, communities, people¶
PortSwigger Web Security Academy, HackTheBox, TryHackMe, PentesterLab, OverTheWire, VulnHub, CTFtime. HackerOne and Bugcrowd disclosed reports are an underused education — read the resolved reports in your target class. SANS reading room, Black Hat and DEF CON archives (free, decades deep), BSides (local and accessible), Pwnie Awards for the field's own view of itself.
Follow: PortSwigger Research (consistently the best web-security research published), Project Zero (the standard for depth and disclosure practice), Orange Tsai, James Kettle, SpecterOps (AD and identity), Rapid7 and Trail of Bits blogs, Krebs on Security and Risky Business for the ecosystem, and the Bugcrowd/HackerOne annual research for the community's own data.
§19. Quick Reference¶
19.1 Pre-engagement gate — all must be true¶
- [ ] Signed contract, SoW, and Rules of Engagement
- [ ] Authorization letter signed by someone with verified authority
- [ ] Scope enumerated explicitly, and out-of-scope enumerated explicitly
- [ ] Third-party systems identified and separately authorized or excluded (§1.3 →
pentest-authorization-scoping-and-methodology) - [ ] Cloud provider testing policy checked for the specific provider
- [ ] Testing window agreed (dates and hours)
- [ ] Prohibited techniques stated in writing
- [ ] Stop condition defined, and who can invoke it
- [ ] Emergency contacts on both sides, reachable during the window
- [ ] Source IPs provided for deconfliction
- [ ] Data handling, retention, and destruction agreed
- [ ] Whether the blue team is aware — decided and documented
19.2 During¶
- [ ] Contemporaneous notes: command, timestamp (UTC), target, result
- [ ] Least invasive proof that establishes the finding
- [ ] Inventory of every account, tool, config change, and persistence mechanism
- [ ] Immediate escalation path used for prior-compromise evidence, safety issues, and critical production findings
- [ ] Anything ambiguous about scope → stop and ask
19.3 Post¶
- [ ] Every finding verified, not scanner-asserted
- [ ] Severity justified, with the CVSS vector shown if used
- [ ] Reproduction steps a stranger can follow
- [ ] Remediation specific enough to action
- [ ] Systemic patterns called out, not just instances
- [ ] Negative findings included
- [ ] Executive summary written for a budget decision
- [ ] Cleanup verified with the client, not asserted
- [ ] Data destroyed per schedule, confirmed in writing
- [ ] Retest scheduled
§20. Sources and Method¶
Method. Narrative (not systematic) review, written as a methodology, process, and
professional-practice reference rather than an exploitation guide. The durable material —
§1 → pentest-authorization-scoping-and-methodology (authorization), §2 → pentest-authorization-scoping-and-methodology (scoping), §3 → pentest-authorization-scoping-and-methodology (methodology), §5.1 → pentest-technical-domains's category structure, §10 → pentest-red-team-ai-and-reporting's
ethics, §13 → pentest-red-team-ai-and-reporting (reporting), §15 — reflects published standards (OWASP, PTES, NIST SP 800-115,
MITRE ATT&CK), professional practice consistently described across the field, and the
failure modes practitioners report. Vulnerability classes are described at the conceptual
level already published in OWASP and CWE for defensive use; this document deliberately
contains no exploitation recipes, exploit code, or techniques for evading specific
defensive products, because the value of a reference at this level is in the parts
practitioners actually get wrong. Every time-sensitive claim was verified against a
primary or near-primary source in August 2026 and is flagged in §17.
Search log (August 2026): CVE program status, funding, and the EUVD/GCVE alternatives · AI in offensive security and autonomous pentesting capability · DORA TLPT requirements and the certification landscape · legal protection for security researchers, CFAA, and safe harbour.
Primary and near-primary sources consulted (selected): - CREST TLPT whitepaper and DORA guidance; regulation-dora.eu, CovertSwarm, Copla, Vaadata, and Pivot Point Security on Article 26/27 mechanics, provider capacity, and the TIBER-EU divergence on internal testers - HackerOne Safe Harbor documentation (GSSH alignment, 1 January 2026); Rapid7's CFAA researcher-protection advocacy; Lawfare and the Knight First Amendment Institute on safe harbour and CFAA/DMCA §1201; Journal of Cybersecurity (2026), "Hunting for vulnerabilities: call for European protection of security researchers" - Krebs on Security, CyberScoop, Cybersecurity Dive, CSO Online, and ENISA on the April 2025 CVE funding crisis, the 2026 funding resolution, the EUVD launch, and the CRA Single Reporting Platform - Bugcrowd and HackerOne 2026 community research (AI adoption; prompting skills gap); Security Boulevard's RSAC 2026 coverage quoting Synack's CTO; Hadrian, AppSecSanta, XHack, and PentestPad on AI agent benchmarks, tool proliferation, and operational risk; Cloud Security Alliance scoping guidance for AI implementations
Confidence statement. High confidence in §1–§3 → pentest-authorization-scoping-and-methodology, §5 → pentest-technical-domains, §13 → pentest-red-team-ai-and-reporting, §15 and §19 — these rest
on published standards, statutory frameworks, and professional practice described
consistently across the field for years. High confidence in the DORA TLPT structural
requirements, which come from the regulation and from CREST's own guidance. Moderate
confidence on the TLPT capacity figures (the "200+ entities vs. fewer than 40 providers"
and "9–14 month cycle" numbers come from vendor and consultancy analysis, and vendors in
this market have an obvious interest in urgency). Moderate-to-low confidence on §12.2 → pentest-red-team-ai-and-reporting's
AI benchmark figures specifically: the ARTEMIS, XBOW, and Excalibur results come from
vendor announcements, preprints, and secondary coverage rather than independently
replicated evaluation; benchmark conditions are rarely comparable, "beat 9 of 10 human
pentesters" depends entirely on which humans and which task, and this is the single most
vendor-saturated topic in the document — I have reported both the capability claims and
the documented limitations, and would treat the direction as more reliable than any
specific number. The legal material in §1 → pentest-authorization-scoping-and-methodology and §17 is descriptive, not advisory;
jurisdictional variation is large, the DOJ policy explicitly confers no rights, and
anything with real stakes needs actual counsel.
Plugin: penetration-testing · View SKILL.md on GitHub