16.2 Types of Assessments
Key Takeaways
- A vulnerability assessment favors breadth: automated scanning finds as many weaknesses as possible but stops short of exploitation.
- A compliance penetration test exists to satisfy a mandate such as PCI DSS, with scope and depth driven by the standard rather than by real-world attack paths.
- A traditional penetration test is goal-driven and manual — it chains weaknesses together to prove actual business impact, like an attacker would.
- White-box assessments give the tester full knowledge, black-box gives none, and gray-box gives partial knowledge such as user-level credentials.
- Bug bounties crowdsource testing from independent researchers under published rules, unlike a contracted, scoped assessment.
Four Assessment Types You Must Distinguish
The KLCP exam loves scenario questions that ask which assessment type fits a described engagement. Learn each type by its goal, depth, and deliverable.
Vulnerability Assessment
A vulnerability assessment answers: what weaknesses exist? It is broad, systematic, and heavily automated. The assessor runs scanners — OpenVAS/GVM and Nessus are the canonical examples — across every in-scope host, then validates and de-duplicates the output. Crucially, a vulnerability assessment stops short of exploitation: it reports that a host appears vulnerable to CVE-2017-0144 (EternalBlue), but does not fire the exploit. The deliverable is a prioritized list of vulnerabilities, usually ranked by CVSS (Common Vulnerability Scoring System) severity, with remediation advice. It is cheap, repeatable, and often run monthly or quarterly as hygiene, but it cannot show what an attacker could actually chain together. Three book-level details go with it. First, a vulnerability is a flaw that, if taken advantage of, compromises confidentiality, integrity or availability, while an exploit is the software that takes advantage of it — and not every vulnerability is exploitable. Second, because scanning is signature-based, every result is one of four outcomes: true positive (real — fix it), false positive (noise, but never dismiss a true positive as one without validating), true negative (genuinely clean), and false negative (a real vulnerability the scanner missed, the worst outcome because you have no idea it is there). Third, an authenticated scan, where the scanner logs in with supplied credentials, sees installed software, patch level and running processes rather than just listening services, and so finds far more than an unauthenticated one.
Compliance Penetration Test
A compliance penetration test answers: do we satisfy the auditor? Its scope and depth are dictated by an external mandate rather than by realistic attack paths. The flagship example is PCI DSS (Payment Card Industry Data Security Standard), which requires organizations handling cardholder data to perform regular penetration tests of the cardholder data environment. Know the other frameworks the book names too: DISA STIG, FedRAMP and FISMA. A compliance test usually begins with a vulnerability assessment, which on its own satisfies several PCI requirements (for example "do not use vendor-supplied defaults" and "regularly test security systems and processes"), while others — restricting physical access, maintaining a security policy — need work no scanner can do. The deliverable is evidence for an auditor: a report showing the required test happened, what was found, and that critical findings were fixed. Because the standard drives the work, compliance tests can be shallower than the name "penetration test" implies — the goal is passing the requirement, not emulating a determined adversary.
Traditional Penetration Test
A traditional (goal-driven) penetration test answers: what could a real attacker do? It is manual, creative, and depth-first. The tester agrees on objectives — steal the HR database, reach the domain controller, pivot from the DMZ into the internal network — and then attacks the way an adversary would, chaining small weaknesses into large compromise: a leaked password plus missing MFA plus a misconfigured service account equals full domain admin. Exploitation and post-exploitation are the point. The deliverable is a narrative report of attack paths with evidence (screenshots, hashes, captured flags) and business-focused remediation. Where a vulnerability assessment is a mile wide and an inch deep, a penetration test is narrow and deep.
Application Assessment
An application assessment (web or mobile) focuses on a single application rather than the network. The tester works through authentication, session management, input handling, access control, and business logic, benchmarked against the OWASP Top 10 — injection, broken access control, cryptographic failures, and so on. Typical Kali tooling includes Burp Suite (Community Edition ships with Kali) and OWASP ZAP as intercepting proxies, plus manual testing with crafted requests. Deliverables are per-finding write-ups with reproduction steps a developer can follow.
Knowledge Levels: White, Gray, and Black Box
Every assessment type can be run at a different knowledge level — how much information the tester starts with. Memorize this table; matching a scenario to a box color is a classic exam question.
| Level | Tester knows | Simulates | Trade-off |
|---|---|---|---|
| White-box (crystal box) | Everything: source code, architecture diagrams, credentials, network maps | Insider or well-resourced attacker; also code review | Most thorough per hour; least realistic externally |
| Gray-box | Partial knowledge — e.g., a standard user account, API docs | Compromised user or limited insider | Balances realism and efficiency |
| Black-box | Nothing but a name or IP range | External attacker starting from zero | Most realistic; most time burned on recon |
White-box testing finds more bugs per dollar because no time is wasted discovering what the client could simply hand over. Black-box testing answers the harder question of what an uninformed outsider can achieve, and it exercises the client's detection capability. Gray-box is the common compromise — for instance, giving the tester a normal domain-user account to simulate a phished employee.
Choosing the Right Assessment
These types are complementary, not competitors. A mature security program runs vulnerability assessments continuously as hygiene, commissions an application assessment before a major product launch, schedules a compliance penetration test because a standard demands it, and periodically buys a traditional penetration test to answer whether all that hygiene actually stops a determined attacker. When an exam scenario describes an engagement, anchor on three clues: what triggered it (a regulation points to compliance; a board-level question points to a traditional test), how deep it goes (scanner output versus demonstrated impact), and what is delivered (a vulnerability list, an attack-path narrative, or auditor evidence). Any two of the three clues are usually enough to name the assessment type.
Bug Bounties: A Different Model
A bug bounty is not a contracted assessment at all. Organizations — through platforms like HackerOne and Bugcrowd, or self-hosted — publish a scope and a reward table, then invite the world's independent researchers to test within those rules. Reports are paid per valid finding, with bounties scaled to severity. Contrast the models: a penetration test is a fixed-price, time-boxed engagement with a small named team, full authorization paperwork, and a guaranteed report; a bug bounty is continuous, crowdsourced, pays only for results, and produces a stream of individual findings rather than a holistic assessment. Bug bounties are excellent for breadth on hardened targets but are no substitute for a scoped penetration test, which also verifies detection, response, and chained attack paths. Kali is the platform of choice on both sides of this divide — hunters and consultants alike run the same toolkit.
A retail company that processes credit cards hires a firm to test its cardholder data environment specifically so it can show an auditor that the testing requirement of PCI DSS has been met. What kind of engagement is this?
Which statement best captures the difference between a vulnerability assessment and a traditional penetration test?
A client gives a tester a standard, non-privileged domain user account and API documentation, but no source code or network diagrams, to simulate what a phished employee could enable. Which knowledge level describes this test?