Penetration Test

Origin & evolution

The idea predates the web. In the late 1960s the US government convened "tiger teams" to probe time-sharing systems, and the 1970s RAND and Anderson reports on computer security treated deliberate penetration as a way to measure how well a system actually held up. The practice matured alongside the systems it tested, moving from mainframes to networks to web applications to cloud and APIs.

Methodology arrived to make results comparable. The Penetration Testing Execution Standard (PTES) defines seven phases: pre-engagement interactions, intelligence gathering, threat☠️ThreatSecurityA specific security threatView reference → modelling, vulnerability🔓VulnerabilitySecurityA known vulnerabilityView reference → analysis, exploitation, post-exploitation, and reporting. For web applications specifically, the OWASP Testing Guide supplies a detailed checklist of what to probe and how. PTES describes the shape of an engagement; OWASP fills in the application-layer detail.

A second distinction hardened over time, by how much the tester knows going in. Black-box testing grants no internal knowledge and most closely mimics an external attacker. White-box hands over source code, architecture, and credentials for the deepest coverage. Grey-box sits between, typically a standard user account, which trades some realism for far better use of a fixed time budget. Most commercial engagements today are grey-box for exactly that reason.

How it works in practice

A fintech commissions a two-week grey-box test ahead of a funding round. The rules of engagement are explicit: production is in scope but the payment processor's sandbox only, testing windows are 09:00 to 17:00 UTC, no denial-of-service, and any finding that exposes live customer data triggers an immediate stop-and-call.

In week one the testers chain two issues. A verbose error message leaks an internal hostname (low on its own), and that hostname runs an admin panel reachable from the internet with default credentials. Alone, each is minor. Chained, they grant administrative access, which a scanner would have rated as two unrelated mediums. The report ranks the chain critical, includes the exact reproduction steps, and the team patches the panel within forty-eight hours. The value was the chaining, the human judgement no automated tool produced.

Penetration test vs. its neighbours

• Vulnerability scan is automated and broad: it enumerates known weaknesses by signature and version, fast and cheap, with no exploitation. A pentest exploits and chains findings to prove real impact. A scan tells you a door is unlocked; a pentest walks through it and shows what is in the room.
• Red team is an objective🏁ObjectiveStrategyA strategic goal (OKR)View reference →-driven, often covert exercise that tests detection and response across people, process, and technology, with a goal like "reach the customer database." A pentest aims for breadth of findings against a defined scope; a red team aims for one realistic path and tests whether the defenders notice.
• Threat is what the pentest simulates. A good engagement is scoped against the threats that matter to the business, so the test is a controlled instance of a threat rather than a generic sweep.

In the graph

In the Unified Product Graph, a penetration test sits in the security region as an assessment activity, linked to what it examined and what it found. A product_tested_by_penetration_testProducttested byPenetration Testhierarchy edge and a penetration_test_assesses_servicePenetration TestassessesServicecross-domain edge record the scope at the product and service level, so coverage gaps are queryable: a critical service with no linked test is an obvious blind spot. A security_review_commissions_penetration_testSecurity ReviewcommissionsPenetration Testhierarchy edge ties the test to the governance decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → that authorised it, preserving the chain of authorisation that makes the work legitimate. The outbound vulnerability_discovered_by_penetration_testVulnerabilitydiscovered byPenetration Testcross-domain edge connects each finding back to the engagement that surfaced it, which lets the graph distinguish flaws found in the open from flaws found under contract before an attacker did.