Chapter 11: Vulnerability Assessment

"A vulnerability unpatched is a door left open. A vulnerability unassessed is a door you don't even know exists." — Dan Farmer, co-creator of SATAN (Security Administrator Tool for Analyzing Networks)

In Chapter 10, we learned to scan networks, enumerate services, and catalog what's running on our targets. We left MedSecure Health Systems with a spreadsheet full of IP addresses, open ports, service versions, and enumeration data. But raw scan data is not intelligence — it is noise. The critical question is not "what ports are open?" but rather "which of these services are vulnerable, how badly, and what should we fix first?"

This chapter bridges the gap between scanning and exploitation. Vulnerability assessment is the disciplined process of identifying security weaknesses, classifying them using standardized frameworks, validating them through manual testing, prioritizing them by risk, and communicating them clearly to stakeholders who must decide how to allocate limited remediation resources.

Unlike exploitation (Part 3), vulnerability assessment stops short of actually compromising systems. It answers the question "could this be exploited?" rather than "I have exploited it." This distinction is critical both practically and contractually: many organizations engage penetration testers specifically for vulnerability assessment, where the deliverable is a prioritized list of weaknesses rather than proof of compromise.

11.1 Vulnerability Assessment vs. Penetration Testing

11.1.1 Defining the Terms

The terms "vulnerability assessment" and "penetration testing" are frequently confused, even by security professionals. Understanding the distinction is essential for scoping engagements, setting expectations, and communicating with clients.

Vulnerability Assessment is a systematic process of identifying and classifying security weaknesses in systems, networks, and applications. It is broad in scope — the goal is to find as many vulnerabilities as possible across the entire attack surface. Think of it as a comprehensive health screening: you test everything and document every issue.

Penetration Testing is a simulated attack that attempts to exploit vulnerabilities to demonstrate real-world impact. It is typically deeper but narrower — the goal is to prove that specific vulnerabilities can actually be exploited to achieve a defined objective (e.g., gaining domain admin, accessing patient records, exfiltrating credit card data). Think of it as a stress test: you probe specific weaknesses until something breaks.

💡 Key Insight: Many engagements combine both approaches. A typical penetration test begins with a vulnerability assessment phase (scanning and identifying weaknesses), then moves into exploitation of the most promising findings. The assessment provides breadth; the penetration test provides depth.

11.1.2 Where Vulnerability Assessment Fits in the Pentest Lifecycle

In the standard penetration testing methodology (PTES), vulnerability assessment falls between information gathering (Chapters 7-10) and exploitation (Chapters 12-17):

Reconnaissance → Scanning → Vulnerability Assessment → Exploitation → Post-Exploitation → Reporting
                           ^^^^^^^^^^^^^^^^^^^^^^^^
                           YOU ARE HERE (Chapter 11)

The assessment phase takes the raw scan data from Chapter 10 and transforms it into an actionable list of weaknesses ranked by severity and exploitability.

11.1.3 Types of Vulnerability Assessments

Network Vulnerability Assessment: Scans network hosts and services for known vulnerabilities, misconfigurations, and missing patches. This is the most common type and what most organizations think of when they request a "vulnerability assessment."

Web Application Vulnerability Assessment: Focuses on web application security issues (OWASP Top 10), including injection flaws, authentication weaknesses, and business logic errors. Covered in depth in Part 4.

Host-Based Assessment: Examines individual systems for local vulnerabilities — missing patches, insecure configurations, weak file permissions, unnecessary services. Typically requires credentials (authenticated scanning).

Database Assessment: Evaluates database security — default credentials, excessive privileges, unpatched versions, encrypted data handling.

Cloud Security Assessment: Reviews cloud infrastructure configurations — IAM policies, storage permissions, network security groups, encryption settings. Covered in Chapter 29.

Wireless Assessment: Tests wireless network security — encryption protocols, access point configurations, rogue APs. Covered in Chapter 25.

11.2 CVE, CVSS, and Vulnerability Databases

11.2.1 The CVE System

The Common Vulnerabilities and Exposures (CVE) system provides standardized identifiers for publicly known security vulnerabilities. Maintained by the MITRE Corporation and funded by the U.S. Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA), CVE serves as the universal language for vulnerability identification.

Each CVE entry has: - CVE ID: A unique identifier in the format CVE-YYYY-NNNNN (e.g., CVE-2021-44228) - Description: A brief explanation of the vulnerability - References: Links to advisories, patches, and technical details

📊 Scale: The CVE database has grown dramatically. In 2024, over 28,000 new CVEs were assigned — an average of 77 new vulnerabilities per day. This volume underscores why automated scanning and prioritization are essential; no team can manually track this pace.

CVE Numbering Authorities (CNAs) are organizations authorized to assign CVE IDs. Major CNAs include MITRE (the root CNA), Microsoft, Google, Apple, Red Hat, Cisco, and over 300 others. When a vulnerability is discovered, the researcher or vendor requests a CVE ID from the appropriate CNA.

11.2.2 The CVSS Scoring System

The Common Vulnerability Scoring System (CVSS) provides a standardized method for assessing the severity of vulnerabilities. Currently in version 3.1 (with version 4.0 released in late 2023), CVSS produces a numerical score from 0.0 to 10.0.

CVSS v3.1 Metric Groups:

Base Metrics (intrinsic properties of the vulnerability):

Temporal Metrics (change over time): - Exploit Code Maturity: How developed available exploit code is - Remediation Level: What type of fix is available - Report Confidence: How well-validated the vulnerability is

Environmental Metrics (specific to the organization): - Modified base metrics adjusted for the specific environment - Confidentiality/Integrity/Availability Requirements of the affected asset

CVSS Score Ranges:

Example CVSS Calculation — Log4Shell (CVE-2021-44228):

Base Score: 10.0 (Critical)
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Breakdown:
  Attack Vector: Network (remotely exploitable)
  Attack Complexity: Low (trivial to exploit)
  Privileges Required: None (no authentication needed)
  User Interaction: None (no user action required)
  Scope: Changed (can affect other components)
  Confidentiality: High (complete data access)
  Integrity: High (complete data modification)
  Availability: High (complete denial of service)

⚠️ CVSS Limitations: CVSS scores measure technical severity, not business risk. A CVSS 10.0 vulnerability on an isolated development server with no sensitive data may be less urgent than a CVSS 6.0 vulnerability on a production payment processing system. Always combine CVSS with business context.

11.2.3 Vulnerability Databases

Beyond CVE itself, several databases provide enriched vulnerability information:

National Vulnerability Database (NVD) — nvd.nist.gov: Maintained by NIST, the NVD enriches CVE entries with CVSS scores, CWE classifications, affected product configurations (CPE), and fix information. It is the primary reference for CVSS scores.

Exploit Database (exploit-db.com): A repository of public exploits and corresponding vulnerable software, maintained by Offensive Security. If a vulnerability has a public exploit, it is likely cataloged here.

VulnDB (vulndb.cyberriskanalytics.com): A commercial vulnerability intelligence database that includes vulnerabilities not yet assigned CVE IDs, along with detailed risk ratings and vendor response timelines.

MITRE ATT&CK: While not a vulnerability database per se, ATT&CK maps techniques used by adversaries, including which vulnerabilities are commonly exploited in the wild.

CISA Known Exploited Vulnerabilities (KEV) Catalog: A curated list of vulnerabilities known to be actively exploited in the wild. This is extremely valuable for prioritization — if a vulnerability is on the KEV list, it should be patched immediately.

🔗 Practical Tip: During a vulnerability assessment, cross-reference your findings against multiple databases. A vulnerability found by your scanner should be verified against the NVD for CVSS scoring, checked against the KEV catalog for active exploitation, and searched on Exploit-DB for available proof-of-concept code.

11.2.4 CWE: Common Weakness Enumeration

While CVE identifies specific vulnerabilities, CWE (Common Weakness Enumeration) categorizes the types of weaknesses that lead to vulnerabilities. For example:

• CWE-89: SQL Injection
• CWE-79: Cross-Site Scripting
• CWE-287: Improper Authentication
• CWE-522: Insufficiently Protected Credentials
• CWE-798: Use of Hard-Coded Credentials

CWE is valuable for trend analysis — if your assessment reveals multiple findings mapped to CWE-89, it suggests a systemic issue with input validation that needs architectural remediation, not just individual patching.

11.3 Automated Vulnerability Scanning

11.3.1 How Automated Scanners Work

Automated vulnerability scanners (introduced in Chapter 10, Section 10.6) work through a multi-phase process:

1. Discovery: Identify live hosts and open ports
2. Service fingerprinting: Determine what software is running on each port
3. Vulnerability checking: Match discovered software versions against vulnerability databases; send targeted probes to confirm specific weaknesses
4. Result correlation: Combine findings, eliminate duplicates, assign severity scores
5. Reporting: Generate structured reports with findings, evidence, and remediation guidance

11.3.2 Authenticated vs. Unauthenticated Scanning

The single most impactful decision in vulnerability scanning is whether to use credentials:

Unauthenticated (External) Scanning: - Sees only what is exposed on the network - Identifies vulnerabilities in network-facing services - Misses local vulnerabilities (missing OS patches, local misconfigurations) - Faster, simpler setup - Simulates an external attacker's view

Authenticated (Credentialed) Scanning: - Logs into the host using provided credentials (SSH, SMB, WMI) - Examines installed software versions, patch levels, and local configurations - Identifies significantly more vulnerabilities (5-10x typical increase) - Can check for specific missing patches (KB articles on Windows, package versions on Linux) - Simulates an insider or post-compromise attacker's view

# Nessus credentialed scan results comparison (typical):
Unauthenticated:  47 vulnerabilities (12 critical, 8 high)
Authenticated:   312 vulnerabilities (45 critical, 67 high)

📊 MedSecure Scenario: For the MedSecure assessment, we run both unauthenticated and authenticated scans. The unauthenticated scan identifies 156 findings across 347 hosts. The authenticated scan (using a service account with local admin privileges) reveals 2,847 findings — including 312 critical missing patches on Windows systems that weren't visible from the network.

11.3.3 Scan Configuration Best Practices

Pre-scan preparation: 1. Confirm scope and authorization documents are signed 2. Obtain credentials for authenticated scanning (domain admin or local admin for Windows, root or sudo for Linux) 3. Identify fragile systems that should be excluded or scanned gently (medical devices, ICS/SCADA systems, production databases under heavy load) 4. Schedule scans during maintenance windows for production environments 5. Notify the client's security operations team to prevent alert fatigue

Scanner configuration: - Enable credentialed checks for maximum coverage - Configure appropriate scan policies (aggressive for dev/staging, careful for production) - Set appropriate timing and parallelism to avoid network congestion - Enable compliance checks if relevant (PCI DSS, HIPAA, CIS Benchmarks) - Configure output formats for post-processing (XML, CSV, JSON)

Post-scan activities: - Review scan logs for errors or authentication failures - Verify that all in-scope hosts were successfully scanned - Check for scan artifacts that need cleanup (temporary files, test accounts) - Begin the validation and prioritization process (Sections 11.4-11.5)

11.3.4 Web Application Vulnerability Scanning

Web application scanners (DAST — Dynamic Application Security Testing) operate differently from network vulnerability scanners:

Common DAST Tools: - Burp Suite Professional: Industry-standard web scanner with active and passive scanning - OWASP ZAP: Free, open-source web application scanner - Acunetix: Commercial web vulnerability scanner - Nikto: Open-source web server scanner (covered in Chapter 10) - Nuclei: Template-based scanner effective for web vulnerabilities

DAST scanning process: 1. Crawling/Spidering: Discover all pages, forms, and parameters 2. Passive analysis: Identify issues from observed responses (missing headers, information leakage) 3. Active scanning: Send attack payloads to discovered parameters (SQL injection, XSS, command injection probes) 4. Result reporting: Classify and present findings

⚠️ Web Scanner Limitations: Automated web scanners are effective at finding common vulnerability patterns but struggle with business logic flaws, complex multi-step workflows, and modern JavaScript-heavy applications. They should always be supplemented with manual testing (covered in Part 4).

11.4 Manual Vulnerability Validation

11.4.1 Why Manual Validation Is Essential

Automated scanners are indispensable for efficiency, but they produce false positives (reporting vulnerabilities that don't actually exist), false negatives (missing real vulnerabilities), and findings that lack context. Manual validation addresses all three issues.

Every professional vulnerability assessment includes manual validation of scanner findings. This is what separates a professional assessment from a "scan and deliver" report that provides minimal value to the client.

11.4.2 Validation Techniques

Version Verification: The scanner reports that Apache 2.4.49 is running and flags it as vulnerable to CVE-2021-41773 (path traversal). Validate by:

1. Confirming the version: curl -I http://target — check the Server header
2. Checking the specific vulnerability condition: CVE-2021-41773 requires mod_cgi or mod_cgid to be enabled for RCE. Is it?
3. Testing the vulnerability manually: bash curl 'http://target/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd'
4. Documenting the result with screenshots and response data

Configuration Verification: The scanner flags "SMBv1 enabled." Validate by:

nmap --script smb-protocols -p 445 target
# Output should show "SMBv1" in the results

Credential Testing: The scanner reports default credentials on a service. Validate by attempting to authenticate:

# MySQL default credentials
mysql -h target -u root --password=''

# SSH default credentials
ssh admin@target  # with common passwords

# Web application default login
curl -X POST http://target/login -d "username=admin&password=admin"

SSL/TLS Validation: The scanner reports weak ciphers or protocols. Validate with:

# Check for specific weak protocols
openssl s_client -connect target:443 -tls1
openssl s_client -connect target:443 -ssl3

# Or use testssl.sh for comprehensive analysis
testssl.sh target:443

11.4.3 The Validation Workflow

For each scanner finding:

1. Read the finding description and understand what the scanner is claiming
2. Check the evidence — what proof did the scanner provide?
3. Attempt manual reproduction — can you confirm the vulnerability exists?
4. Assess actual impact — in this specific environment, what could an attacker do with this vulnerability?
5. Document your validation — screenshots, command output, response data
6. Classify the finding — True positive, false positive, or needs further investigation

💡 Efficiency Tip: You cannot manually validate every finding in a large assessment (thousands of results). Prioritize validation of: (1) all Critical and High findings, (2) findings that seem unusual or unexpected, (3) findings that the client will question, and (4) a random sample of Medium/Low findings to calibrate the scanner's accuracy.

11.5 Vulnerability Prioritization and Risk Rating

11.5.1 Beyond CVSS: Business Context

CVSS provides a technical severity score, but vulnerability prioritization requires business context. A mature vulnerability assessment considers:

Asset Criticality: - Is this a domain controller, a database server with PII, or a developer workstation? - What is the business impact if this system is compromised? - Is the system in production or development?

Exposure: - Is the vulnerable system Internet-facing or internal-only? - Are there compensating controls (WAF, IPS, network segmentation)? - Is the vulnerability reachable from the attacker's starting position?

Exploitability: - Is there a public exploit available? - Is the vulnerability being actively exploited in the wild (check CISA KEV)? - What skill level is required for exploitation? - Does exploitation require authentication or user interaction?

Data Sensitivity: - Does the system process, store, or transmit regulated data (PII, PHI, PCI)? - What is the regulatory impact of a breach?

11.5.2 Risk Rating Frameworks

Qualitative Risk Rating:

A common approach multiplies likelihood by impact:

DREAD Model: Originally from Microsoft, DREAD scores each vulnerability on five factors: - Damage: How bad would an exploit be? - Reproducibility: How easy is it to reproduce? - Exploitability: How much effort to exploit? - Affected users: How many people are impacted? - Discoverability: How easy to find?

Each factor is rated 1-10, and the average produces an overall risk score.

OWASP Risk Rating Methodology: OWASP provides a more detailed framework that separately assesses threat agent factors, vulnerability factors, technical impact, and business impact. It is particularly valuable for web application assessments.

11.5.3 Practical Prioritization

💡 MedSecure Prioritization Example:

From our 2,847 findings, we apply prioritization:

Tier 1 — Immediate Remediation (address within 24-48 hours): - Apache 2.4.49 path traversal on patient portal (CVSS 9.8, Internet-facing, handles PHI) - SMBv1 enabled on 3 servers (CVSS 9.8, EternalBlue exploit publicly available, CISA KEV listed) - Default SNMP community strings on network infrastructure (CVSS 7.5, exposes entire network topology)

Tier 2 — Urgent Remediation (address within 1-2 weeks): - 45 missing critical Windows patches (various CVSSs, internal-only, compensating controls exist) - NFS no_root_squash on backup server (CVSS 7.5, internal access required) - Anonymous LDAP bind on domain controllers (CVSS 5.3, information disclosure)

Tier 3 — Standard Remediation (address within 30 days): - SSL/TLS weak cipher suites (CVSS 5.3, theoretical risk) - Missing security headers on web applications (CVSS 4.3, defense-in-depth) - Informational findings (software version disclosure, unnecessary services)

11.5.4 Communicating Risk to Stakeholders

Different audiences need different levels of detail:

Technical Teams: Full vulnerability details, affected hosts, proof of concept, specific remediation steps, configuration changes, patches to apply.

Management: Executive summary with overall risk posture, trending analysis, comparison to previous assessments, business impact of top findings, resource requirements for remediation.

Board/Executives: One-page summary with risk score, comparison to industry benchmarks, key findings in business terms, investment recommendations.

11.6 False Positives, False Negatives, and Verification

11.6.1 The False Positive Problem

A false positive is a scanner finding that incorrectly identifies a vulnerability that does not actually exist. False positives waste remediation resources, erode trust in assessment findings, and create alert fatigue.

Common causes of false positives:

1. Version-based detection: The scanner identifies the software version and flags known vulnerabilities for that version, without confirming the specific conditions or patches applied. A system running Apache 2.4.49 might have the CVE-2021-41773 patch applied as a backport without changing the version number (common on enterprise Linux distributions like Red Hat).

2. Banner spoofing/modification: The banner says "Apache/2.4.49" but the actual version is different (banner has been deliberately changed or the scanner misread it).

3. Compensating controls: The vulnerability exists in the software, but a WAF, IPS, or network segmentation makes it unexploitable in the specific environment.

4. Configuration differences: The vulnerability requires a specific configuration that is not present (e.g., CVE requires a specific module to be enabled, but it is not).

11.6.2 The False Negative Problem

A false negative is a real vulnerability that the scanner fails to detect. False negatives are more dangerous than false positives because they create a false sense of security.

Common causes of false negatives:

1. Non-standard ports: The scanner checks for MySQL on port 3306 but misses a MySQL instance running on port 13306.

2. Rate limiting/firewall interference: The scanner's probes are being dropped or rate-limited, causing it to report ports as filtered when they are actually accessible.

3. Plugin/template gaps: The scanner's vulnerability database doesn't include a check for a recently disclosed vulnerability.

4. Authenticated-only vulnerabilities: The scanner runs unauthenticated and misses local vulnerabilities that require credential access.

5. Logic flaws and custom vulnerabilities: No automated scanner can find business logic flaws or vulnerabilities unique to custom-developed applications.

11.6.3 Verification Strategies

Cross-scanner verification: Run multiple scanners against the same targets. Vulnerabilities found by two or more scanners are more likely to be true positives.

Manual spot-checking: Validate a representative sample of findings across each severity level.

Patch verification: For version-based findings, confirm whether the vulnerability was actually patched by checking package versions (rpm, dpkg) or Windows Update history.

Exploit testing: For critical findings, attempt exploitation in a controlled manner (with authorization) to definitively confirm exploitability. This bridges vulnerability assessment into penetration testing.

🔴 Case Example: During a MedSecure assessment, the scanner flags 47 instances of "Apache Struts CVE-2017-5638" across the network. Manual validation reveals that only 3 instances are actually running Apache Struts — the remaining 44 are Apache HTTP servers that the scanner misidentified due to similar banner patterns. Without manual validation, the client would have wasted significant effort investigating 44 non-issues.

11.7 Vulnerability Assessment Reporting

11.7.1 Report Structure

A professional vulnerability assessment report typically contains:

1. Executive Summary (1-2 pages) - Engagement overview and scope - Overall risk rating (Critical/High/Medium/Low) - Key findings in business terms - Trending analysis (if repeat assessment) - Strategic recommendations

2. Methodology - Tools used and versions - Scan configurations and credentials - Date and time of scanning - Limitations and exclusions

3. Findings Summary - Vulnerability count by severity - Findings by category (missing patches, misconfigurations, default credentials, etc.) - Top 10 most critical findings - Charts and visualizations

4. Detailed Findings For each vulnerability: - Title and CVE/CWE references - Severity rating (CVSS + risk-adjusted) - Affected hosts/systems - Description of the vulnerability - Evidence (screenshots, command output, scanner evidence) - Impact analysis - Remediation steps (specific, actionable) - References

5. Appendices - Full host/port inventory - Complete vulnerability list - Scan configuration details - Tool output files

11.7.2 Writing Effective Finding Descriptions

Each finding should follow a consistent structure:

FINDING: Apache HTTP Server Path Traversal (CVE-2021-41773)

Severity: Critical (CVSS 9.8)
Risk Rating: Critical (Internet-facing, PHI data)
Affected Hosts: 10.10.1.20 (web01.medsecure.local)

DESCRIPTION:
The Apache HTTP Server version 2.4.49 running on the patient portal
contains a path traversal vulnerability that allows unauthenticated
attackers to read arbitrary files on the server and potentially
execute arbitrary code when mod_cgi is enabled.

EVIDENCE:
Request:
  curl 'http://10.10.1.20/cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd'

Response:
  root:x:0:0:root:/root:/bin/bash
  daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
  [... truncated ...]

IMPACT:
An attacker could read sensitive configuration files, patient data,
and credentials stored on the web server. With mod_cgi enabled,
remote code execution is possible, granting full control of the system.

REMEDIATION:
1. Upgrade Apache HTTP Server to version 2.4.51 or later.
2. As an interim measure, disable mod_cgi and mod_cgid if not required.
3. Implement a web application firewall (WAF) rule to block
   path traversal patterns.
4. Review server logs for evidence of prior exploitation attempts.

REFERENCES:
- CVE-2021-41773: https://nvd.nist.gov/vuln/detail/CVE-2021-41773
- Apache Advisory: https://httpd.apache.org/security/vulnerabilities_24.html

11.7.3 Remediation Prioritization Roadmap

Include a clear prioritization roadmap in your report:

11.7.4 Report Delivery and Communication

• Draft delivery: Submit a draft report for factual review. The client may know about compensating controls or planned decommissioning that affects your findings.
• Debrief meeting: Walk through findings with technical and management stakeholders. A report alone is often insufficient — the discussion provides context and drives action.
• Remediation support: Be available to answer questions during the remediation phase. Clarify specific findings, suggest alternative fixes, and validate that remediations were effective.
• Retest: After the client remediates, perform a targeted retest to confirm that vulnerabilities have been properly addressed.

11.8 Chapter Summary

This chapter transformed raw scan data into actionable vulnerability intelligence. We covered the complete vulnerability assessment lifecycle:

Assessment vs. Penetration Testing: Vulnerability assessment identifies and classifies weaknesses across the entire attack surface; penetration testing exploits them to prove impact. Both are valuable and complementary.

CVE, CVSS, and Vulnerability Databases: The CVE system provides universal vulnerability identification. CVSS quantifies technical severity. The NVD, Exploit-DB, and CISA KEV catalog provide enrichment data essential for prioritization.

Automated Scanning: Credential-based scanning reveals dramatically more findings than unauthenticated scanning. Tool selection (Nessus, OpenVAS, Nuclei) depends on scope, budget, and target type. No single scanner catches everything.

Manual Validation: Critical for filtering false positives, discovering false negatives, and adding business context that automated tools cannot provide. Validation is what distinguishes a professional assessment from an automated scan dump.

Prioritization: CVSS alone is insufficient. Effective prioritization combines technical severity with asset criticality, exposure, exploitability, and data sensitivity to produce actionable risk ratings.

False Positives and Negatives: Both are inevitable. Cross-scanner verification, manual spot-checking, and strategic exploitation testing minimize both.

Reporting: Professional reports communicate findings clearly to technical and business audiences, with specific evidence, impact analysis, and actionable remediation guidance organized by priority.

✅ Key Principle: A vulnerability assessment is only as valuable as the remediation it drives. The best assessment in the world is worthless if the report sits on a shelf. Write reports that compel action — clear, prioritized, business-contextualized, and actionable.

In Part 3, we shift from identifying vulnerabilities to exploiting them. The next chapter introduces the Metasploit Framework and the fundamentals of exploitation — where the findings from your vulnerability assessment become proof of real-world risk.

"Vulnerability assessment is not about finding the most vulnerabilities. It is about finding the right vulnerabilities and communicating them in a way that drives the right remediation at the right time." — Chris Nickerson, security researcher