Reporting & Risk Assessment

CVSS is not risk. Here's why. CVSS tells you the technical severity of a vulnerability in a vacuum. It doesn't tell you what it means for your business. SQL injection on a public-facing site is different from SQL injection on an internal admin panel. Contextual risk assessment and clear reporting are key to effective vulnerability remediation.

CVSS Limitations

The Common Vulnerability Scoring System (CVSS) is an industry standard for vulnerability assessment, but it has important limitations you must understand.

What CVSS Measures

CVSS score includes multiple metrics:

  • Attack Vector (AV) — From where is the attack possible (network, adjacent, local, physical).
  • Attack Complexity (AC) — How difficult is it to exploit the vulnerability.
  • Privileges Required (PR) — Does the attacker need existing privileges.
  • User Interaction (UI) — Is user interaction required.
  • Scope (S) — Does the attack impact components beyond the vulnerable component.
  • Confidentiality/Integrity/Availability (C/I/A) — Impact on confidentiality, integrity, and availability.

What CVSS Does NOT Measure

  • Business context — CVSS doesn't know this server is your most important production system.
  • Data value — It doesn't distinguish between test and production data.
  • Compensating controls — Ignores WAF, segmentation, monitoring.
  • Actual exposure — A vulnerability on an internal application has different risk than on a public one.
  • Attack likelihood — Is this vulnerability actively exploited in the wild?
  • Regulatory impact — Doesn't consider GDPR, PCI-DSS, or other requirements.

Example of the Difference

Two vulnerabilities with CVSS 9.8:

  • Vulnerability A — RCE on a public web server storing customer data. Exploit is publicly available.
  • Vulnerability B — RCE on a development server in an internal network, accessible only to 5 developers.

Same CVSS, completely different actual risk. Prioritizing by CVSS alone would be wrong.

My Approach to Risk Assessment

I evaluate every vulnerability in the context of your specific environment. This includes:

1. Business Impact

What can an attacker actually do? What's the damage?

  • Financial damage — Direct loss (theft, extortion), indirect loss (downtime, remediation).
  • Reputational damage — Loss of customer trust, negative media attention.
  • Regulatory consequences — GDPR fines (up to 4% of global revenue), PCI-DSS, NIS2.
  • Operational consequences — Business disruption, recovery time.
  • Strategic impact — Loss of competitive advantage, intellectual property leakage.

2. Exploitability

Is this trivial or does it require a highly skilled attacker?

  • Technical difficulty — Is the exploit point-and-click or requires research?
  • Exploit availability — Publicly available? In Metasploit? 0-day?
  • Automation — Are there tools for mass scanning this vulnerability?
  • Active exploitation — Is the vulnerability currently exploited in the wild?
  • Attacker motivation — Is your organization an interesting target for specific threats?

3. Exposure

Who has access? What controls exist?

  • Accessibility — Publicly accessible, authenticated users, internal only, VPN.
  • Existing controls — WAF, IDS/IPS, segmentation, monitoring.
  • Authentication — Is it required? How strong?
  • Geographic restrictions — Geoblocking, IP whitelisting.

4. Attack Chains

Does this vulnerability enable other attacks?

  • Entry point — Is this the first step for further attacks?
  • Privilege escalation — Enables privilege elevation?
  • Lateral movement — Enables moving to other systems?
  • Persistence — Enables persistent access?

Structure of My Reports

I create two versions of each report: technical for the IT team and executive summary for management.

Executive Summary

For management who need a quick overview without technical details:

  • Testing scope — What we tested and what we didn't.
  • Key findings — Most important vulnerabilities in business language.
  • Risk assessment — Overall assessment of the organization's security posture.
  • Comparison — Where you stand relative to industry.
  • Priorities — What first, ranked by business risk.
  • Recommended next steps — Concrete actions.

Technical Report

For the IT team who will remediate the vulnerabilities:

  • Methodology — How we tested, which tools we used.
  • Detailed findings — Each vulnerability separately.
  • Reproduction — Step-by-step instructions for reproduction.
  • Evidence — Screenshots, HTTP requests/responses, log excerpts.
  • Remediation instructions — Concrete steps for fixing.
  • References — OWASP, CWE, CVE, vendor documentation.

Individual Finding Structure

  1. Title — Short, descriptive name of the vulnerability.
  2. Severity — Critical/High/Medium/Low + my contextual assessment.
  3. CVSS — Standard score for comparison.
  4. Affected assets — Which systems/components are vulnerable.
  5. Description — What the vulnerability is and why it's a problem.
  6. Business impact — What an attacker can do in your context.
  7. Reproduction — Step-by-step instructions.
  8. Proof of concept — Minimal exploit demonstrating the vulnerability.
  9. Remediation — How to fix, with code examples where appropriate.
  10. References — Additional resources for understanding.

Remediation Prioritization

Not all vulnerabilities require immediate action. My approach to prioritization:

Critical Priority (Immediately)

  • Actively exploited vulnerabilities
  • Vulnerabilities with public exploits on publicly accessible systems
  • Direct access to sensitive data without authentication
  • Remote Code Execution on critical systems

High Priority (Week)

  • Vulnerabilities enabling chains to critical systems
  • Privilege escalation in production environment
  • Vulnerabilities on systems with sensitive data

Medium Priority (Month)

  • Vulnerabilities on internal systems with access restrictions
  • Information disclosure without direct attack vector
  • Vulnerabilities requiring complex exploitation

Low Priority (Quarter)

  • Best practice recommendations
  • Vulnerabilities with minimal impact
  • Vulnerabilities on non-critical test systems

Measuring Progress

Security isn't a one-time project, but a continuous process. I track:

  • MTTD (Mean Time to Detect) — How quickly you discover vulnerabilities.
  • MTTR (Mean Time to Remediate) — How quickly you fix them.
  • Vulnerability trend — Is the count decreasing over time?
  • Recurring vulnerabilities — Are the same mistakes appearing again?
  • Coverage — What portion of infrastructure is regularly tested?

Communicating with Leadership

Technical reports rarely reach leadership in an effective form. My recommendations for communication:

  • Speak business language — Financial risk, not technical jargon.
  • Use scenarios — "If an attacker exploits this vulnerability, they can..." not "Buffer overflow enables RCE."
  • Compare with industry — "Your competitors average X days to fix such vulnerabilities."
  • Show security ROI — Cost of attack vs. cost of protection.
  • Propose concrete steps — Not just problems, but solutions.

My reports aren't just a list of vulnerabilities — they're a roadmap for improving your security posture, tailored to your business and your risks.