From Vulnerability to Disclosure: How to Score, Report, and Responsibly Disclose Security Findings

Understanding CVSS, vulnerability assessment reports, Vulnerability Disclosure Policies, and the process of turning technical discoveries into actionable security reports.

Discovering a vulnerability can be exciting.

You find an exposed service, identify a weak authentication mechanism, uncover an insecure configuration, or reproduce a software vulnerability.

But after the discovery, an important question remains:

How do you communicate what you found in a way that an organization can understand, prioritize, and fix?

A screenshot of a vulnerable page is not a complete security report.

A scanner finding is not automatically a confirmed vulnerability.

And assigning a severity of Critical does not make a finding critical.

Professional security research requires more than identifying weaknesses. It requires evidence, impact analysis, severity assessment, clear documentation, and responsible communication.

This guide explores that process, from understanding CVSS to preparing a vulnerability assessment report and submitting findings through a Vulnerability Disclosure Policy.

1. First, Understand What You Actually Found

Before assigning a severity score, identify the nature of the issue.

A security assessment may reveal:

A software vulnerability.
Weak authentication.
Insecure session management.
Security misconfiguration.
Excessive permissions.
Sensitive information exposure.
Missing security controls.
An outdated or unsupported component.

These findings are not automatically equivalent.

For example, discovering an administrative login page does not prove that authentication can be bypassed.

Finding an open SSH port does not establish that SSH is vulnerable.

Identifying an outdated package does not prove that a particular vulnerability is exploitable in the installed configuration.

The first responsibility of an assessor is to distinguish an observation from a verified security issue.

A useful way to think about the process is:

Observation → Validation → Evidence → Impact Analysis → Severity Assessment → Reporting

Skipping validation can lead to false positives, inaccurate reports, and misleading severity ratings.

2. What Is CVSS?

The Common Vulnerability Scoring System (CVSS) is an open framework maintained by FIRST for communicating the technical severity of software, hardware, and firmware vulnerabilities.

It produces a numerical score from 0.0 to 10.0, along with a qualitative severity rating.

CVSS helps security teams compare vulnerabilities and communicate their technical characteristics in a consistent format.

It is important to understand what CVSS does not do.

CVSS does not:

Prove that a vulnerability exists.
Confirm that an exploit works.
Automatically determine business risk.
Replace a penetration test.
Determine legal liability.
Guarantee the order in which an organization should fix every issue.

A vulnerability's technical severity and its business risk are related, but they are not identical.

For example, a High-severity vulnerability affecting an isolated test server may require a different remediation priority from a Medium-severity vulnerability affecting a critical production system.

CVSS helps describe technical severity. Organizations must still consider their own environment and business context.

Official reference: FIRST — Common Vulnerability Scoring System.

3. CVSS Versions: Why the Version Matters

Two versions are particularly relevant when reading vulnerability reports:

CVSS v3.1

This version is widely used in existing vulnerability databases, security advisories, and assessment reports.

CVSS v4.0

CVSS v4.0 introduced updated metrics and a more detailed approach to describing vulnerability characteristics and their impact.

The v4.0 framework distinguishes between:

CVSS-B: Base metrics.
CVSS-BT: Base and Threat metrics.
CVSS-BE: Base and Environmental metrics.
CVSS-BTE: Base, Threat, and Environmental metrics.

These labels communicate which metric groups were used in the score.

Do not mix metric values or vector strings from different CVSS versions. A CVSS v3.1 vector and a CVSS v4.0 vector are not interchangeable.

For a new assessment, state the version explicitly and use the corresponding official calculator.

Reference: FIRST — CVSS v4.0 Specification.

4. Understanding the CVSS v4.0 Metrics

CVSS v4.0 uses four metric groups:

Base.
Threat.
Environmental.
Supplemental.

The Base metrics describe the intrinsic technical characteristics of the vulnerability.

Threat and Environmental metrics add context.

Supplemental metrics provide additional information but do not change the final CVSS score.

Let's examine the important groups.

4.1 Base Metrics

The Base group contains the primary metrics used to assess a vulnerability.

Attack Vector (AV)

How does an attacker reach the vulnerable component?

Network (N): The vulnerability can be exploited remotely over a network.
Adjacent (A): The attacker must be on an adjacent network.
Local (L): Local access is required.
Physical (P): Physical access is required.

Attack Complexity (AC)

Does exploitation require additional conditions or security circumvention?

Low (L): No special conditions or target-specific circumvention are required.
High (H): Exploitation requires additional complexity.

Attack Requirements (AT)

Are there deployment or execution conditions that must be present for exploitation?

None (N): No additional requirements.
Present (P): Specific conditions must exist.

Privileges Required (PR)

What privileges must the attacker already have?

None (N).
Low (L).
High (H).

User Interaction (UI)

Does another user need to participate in the attack?

None (N): No other user's interaction is required.
Passive (P): Limited interaction is required.
Active (A): The targeted user must take a more active action.

Vulnerable System Impact

These metrics describe the consequences to the vulnerable system:

Vulnerable System Confidentiality (VC).
Vulnerable System Integrity (VI).
Vulnerable System Availability (VA).

Each is assessed as None, Low, or High.

Subsequent System Impact

These metrics describe the effects on systems beyond the vulnerable component:

Subsequent System Confidentiality (SC).
Subsequent System Integrity (SI).
Subsequent System Availability (SA).

These metrics are important when exploitation of one component affects another system.

The purpose of these metrics is to describe what an attacker can actually achieve, not what might theoretically happen under an unsupported assumption.

4.2 Threat Metrics

The Threat metric group considers the current state of exploitation.

The key CVSS v4.0 Threat metric is:

Exploit Maturity (E)

It considers the maturity and availability of exploitation techniques or code.

For example, the availability of reliable public exploit code may affect the assessment compared with a vulnerability for which exploitation remains theoretical.

Threat conditions can change over time, which is why a vulnerability's practical exposure may change even when the underlying software remains the same.

4.3 Environmental Metrics

Environmental metrics allow an organization to adjust the assessment to its own environment.

Consider two systems affected by the same vulnerability:

One is an isolated development server.
The other supports a critical business service.

The technical vulnerability may be identical, but the importance of the affected systems is different.

Environmental metrics help reflect factors such as:

The importance of confidentiality.
The importance of integrity.
The importance of availability.
Modified exploitation conditions.
Modified impact within the organization's environment.

This is where the organization can make the assessment more relevant to its own infrastructure.

4.4 Supplemental Metrics

CVSS v4.0 also includes Supplemental metrics.

These provide additional context, such as:

Safety.
Automatable.
Recovery.
Value Density.
Vulnerability Response Effort.
Provider Urgency.

Supplemental metrics do not affect the numerical CVSS score.

They can still help security teams understand operational considerations and decide how to respond.

5. Understanding CVSS Severity Ratings

CVSS v4.0 uses the following qualitative severity ranges:

SeverityScoreNone0.0Low0.1–3.9Medium4.0–6.9High7.0–8.9Critical9.0–10.0

These ratings provide a convenient way to communicate technical severity.

However, the score should never be selected simply because a finding sounds dangerous.

The metric values must reflect the actual vulnerability and its demonstrated or reasonably supported impact.

A score without a defensible explanation is not a meaningful security assessment.

6. How to Perform CVSS Scoring

Let's walk through the practical process.

Step 1: Define the vulnerability

Start by writing a clear description.

Avoid vague statements such as:

"System is insecure."

Instead, describe the actual issue.

For example:

"An application stores authentication-related information in a client-side cookie using reversible encoding. The observed value can be decoded to reveal credential-like information."

This tells the reader what was observed without making unsupported claims about account takeover or remote compromise.

Step 2: Validate the finding

Before scoring, establish:

Which component is affected?
What version or configuration is involved?
Can the behavior be reproduced?
What access does an attacker need?
What is the actual security impact?
Are there additional conditions required?

If the finding is not sufficiently verified, document it as a potential issue or observation rather than presenting it as a confirmed vulnerability.

Step 3: Evaluate the Base metrics

Work through the Base metrics one at a time.

Ask:

Can the issue be exploited over a network?
Does exploitation require local or physical access?
Are additional conditions required?
Does the attacker need existing privileges?
Does another user need to interact?
What confidentiality impact is possible?
What integrity impact is possible?
What availability impact is possible?
Are other systems affected?

Do not assume every impact is High.

For example, the exposure of a username does not automatically mean complete confidentiality loss.

Similarly, discovering a potential local privilege escalation vulnerability does not establish that an attacker can remotely obtain root access.

Step 4: Consider Threat and Environmental metrics

After assessing the Base metrics, consider whether additional context is available.

Is reliable exploit code publicly available?

Is the vulnerability actively exploited?

Does the affected system support a critical business function?

Are there compensating controls?

These considerations help produce a more useful assessment for the environment in which the vulnerability exists.

Step 5: Generate the score and vector

Use the official calculator rather than estimating the numerical score manually.

Open the FIRST CVSS v4.0 Calculator

The calculator generates:

A numerical score.
A qualitative severity rating.
A vector string representing the selected metrics.

The vector string is particularly important because it allows another analyst to understand and reproduce the scoring decisions.

For example, a report should identify the CVSS version, score, severity, and complete vector string.

Step 6: Explain your reasoning

Do not stop at the number.

Explain why each important metric was selected.

A professional assessment should make it possible for another security analyst to review the evidence, understand the assumptions, and challenge or reproduce the scoring decision.

A CVSS score should be explainable, not just calculable.

7. A Practical Example: Applying the Process to Venus

Let's use the Venus assessment as an example.

During the investigation, an authentication-related cookie contained:

Z3Vlc3Q6dGhyZmc=

Base64 decoding produced:

guest:thrfg

Applying ROT13 produced:

guest:guest

This is useful evidence of reversible encoding.

But should we immediately assign it a High or Critical CVSS score?

No.

First, we need to establish:

Whether the cookie is actually used for authentication.
Whether the recovered information provides valid access.
Whether an attacker can obtain the cookie.
Whether the cookie can be reused.
Whether additional security controls restrict exploitation.
What level of access and impact is achievable.

Only after establishing these details can the analyst choose appropriate CVSS metrics.

The same approach applies to the potential PwnKit finding.

The presence of a LinPEAS result referencing CVE-2021–4034 is not enough to assign a confirmed vulnerability score to the target.

The installed package version and exploitation conditions must be verified.

This is why the original Venus assessment should not use arbitrary CVSS values simply to make the report appear complete.

If the available evidence is insufficient, state that scoring is pending validation.

That is better than publishing an impressive but inaccurate number.

8. CVSS Is Not the Same as Business Risk

This is one of the most important concepts in vulnerability management.

CVSS communicates technical severity. It does not independently determine the business priority of a finding.

Consider a hypothetical organization with two findings:

Finding A: A High-severity vulnerability affects an isolated test environment with no sensitive information.

Finding B: A Medium-severity vulnerability affects an externally accessible system supporting a critical business process.

Even though Finding A has a higher CVSS rating, the organization may decide that Finding B needs immediate attention.

Why?

Because remediation priority can also depend on:

Asset criticality.
Exposure to the internet.
Business impact.
Data sensitivity.
Existing security controls.
Active exploitation.
Regulatory obligations.
Remediation complexity.

A vulnerability management team should consider CVSS alongside threat intelligence and organizational risk.

A useful distinction is:

CVSS answers: How technically severe is this vulnerability?

Risk assessment answers: How much does this issue matter to this organization?

9. How to Write a Professional Vulnerability Assessment Report

After validating and assessing a finding, the next step is documentation.

A useful vulnerability report should be understandable to both technical teams and decision-makers.

I recommend the following structure.

9.1 Executive Summary

Summarize the assessment:

What was tested?
What was the objective?
What major findings were identified?
What are the most important recommendations?

Keep this section understandable to readers who may not have deep technical knowledge.

9.2 Scope and Methodology

Document:

Target systems.
IP addresses or application URLs.
Assessment dates.
Testing environment.
Authorized activities.
Tools used.
Testing limitations.

The scope is especially important because it defines what was and was not assessed.

9.3 Individual Finding Details

Each vulnerability should have its own finding entry.

A useful template is:

Finding ID: VULN-001

Title: Clear vulnerability name.

Affected Asset: Host, application, service, or component.

Severity: Informational, Low, Medium, High, or Critical, where supported by the selected assessment methodology.

CVSS Version: For example, CVSS v4.0.

CVSS Score: Numerical score, if justified.

CVSS Vector: Complete vector string.

Description: Explain the weakness.

Evidence: Include relevant output, screenshots, HTTP requests, or other supporting material.

Steps to Reproduce: Provide concise, safe, repeatable steps.

Security Impact: Explain the realistic consequences.

Remediation: Give practical corrective actions.

References: Include relevant vendor advisories, standards, or vulnerability identifiers where applicable.

9.4 Evidence Matters

A finding should contain enough evidence for another person to understand and validate it.

Useful evidence may include:

Relevant command output.
Sanitized screenshots.
HTTP request and response excerpts.
Configuration details.
Affected software versions.
Reproduction steps.
Relevant logs.

Avoid including passwords, session tokens, personal information, or sensitive production data in a report unless an authorized secure process specifically requires them.

Redact sensitive information before sharing evidence.

9.5 Remediation Should Be Actionable

"Fix the vulnerability" is not a useful remediation recommendation.

Instead, explain what needs to change.

For example:

Replace weak credentials and disable unnecessary accounts.
Store session state securely on the server.
Patch the affected software component.
Restrict administrative access.
Apply appropriate browser security headers.
Review and correct excessive permissions.

A report is more useful when the organization can move directly from finding to remediation.

10. What Is a Vulnerability Disclosure Policy?

A Vulnerability Disclosure Policy (VDP) explains how an organization accepts and handles reports from external security researchers.

It provides guidance on:

Which systems are in scope.
Which testing activities are permitted.
Which activities are prohibited.
How researchers should submit reports.
What information should be included.
How the organization handles reports.
How disclosure should be coordinated.

A VDP is not necessarily a bug bounty program.

A bug bounty program may offer financial rewards for eligible findings.

A VDP can simply provide an authorized process for receiving vulnerability reports without offering payment.

The two may operate together, but they are not the same thing.

Why does a VDP matter?

Without clear reporting instructions, researchers may not know:

Whether testing is authorized.
Which systems can be assessed.
Where findings should be submitted.
Whether proof-of-concept testing is permitted.
How long to wait before public disclosure.

A properly designed policy reduces uncertainty for both researchers and organizations.

For an example, see the CISA Vulnerability Disclosure Policy Template.

11. Understanding Scope and Authorization

This is where responsible security research becomes particularly important.

Never assume that a publicly accessible website is automatically authorized for penetration testing.

Before testing a real organization, review its published VDP or obtain explicit written authorization.

Look for the following information:

In-scope assets

Which domains, IP ranges, applications, APIs, or services are covered?

Out-of-scope assets

Are third-party services, cloud providers, employee systems, or external integrations excluded?

Permitted testing

Does the policy allow authentication testing, automated scanning, proof-of-concept exploitation, or other activities?

Prohibited testing

Common restrictions may include:

Denial-of-service testing.
Phishing and social engineering.
Physical security testing.
Accessing or modifying other users' data.
Establishing persistence.
Lateral movement.
Exfiltrating sensitive information.
Testing systems outside the published scope.

Reporting instructions

Does the organization provide an email address, web form, security portal, or third-party reporting platform?

If the policy is unclear, contact the organization before testing.

Do not treat silence as permission.

12. What Is Responsible Disclosure?

Responsible disclosure is the process of communicating a discovered vulnerability to the affected organization in a way that gives it an opportunity to investigate and remediate the issue.

A coordinated approach generally follows these stages.

Stage 1: Identify and Validate

Discover the potential vulnerability and collect sufficient evidence to establish that it exists.

Avoid unnecessary exploitation.

Stage 2: Review the Disclosure Policy

Check the organization's scope, authorization, testing restrictions, and reporting process.

If no policy exists, identify an appropriate security contact and seek guidance before conducting additional testing.

Stage 3: Prepare the Report

Include:

Vulnerability description.
Affected asset.
Technical evidence.
Reproduction steps.
Potential impact.
Suggested remediation
CVSS score and vector, if adequately supported.

Keep the report factual and concise.

Stage 4: Submit Privately

Use the organization's approved reporting channel.

Avoid publicly posting screenshots, exploit details, or sensitive information before the issue has been appropriately coordinated.

Stage 5: Cooperate With Validation

The organization may request additional information.

Respond with relevant evidence and clarify any assumptions in the original report.

Do not expand testing beyond the authorized scope simply because the organization asks questions.

Stage 6: Coordinate Remediation and Disclosure

Allow the organization reasonable time to investigate and fix the issue.

There is no universal disclosure deadline that applies to every organization or vulnerability. Follow the published policy and coordinate a reasonable timeline with the affected party.

Stage 7: Publish Responsibly, If Appropriate

After coordination, a researcher may publish a technical write-up or advisory, subject to applicable agreements, policy terms, and legal requirements.

Remove sensitive information that could expose users or create unnecessary risk.

The goal is to improve security, not to create additional opportunities for exploitation.

13. How to Prepare a Vulnerability Disclosure Report

Here is a practical template you can adapt when reporting a finding through an organization's VDP.

Vulnerability Disclosure Report Template

Subject: Vulnerability Report — [Short Vulnerability Title]

Researcher: [Your name or preferred identifier]

Affected Asset: [Domain, URL, application, or product]

Date Discovered: [Date]

Date Reported: [Date]

Vulnerability Type: [For example, Authentication Weakness]

Severity: [Rating, if justified]

CVSS Version and Score: [Version and score, if justified]

CVSS Vector: [Complete vector string, if applicable]

1. Summary

Provide a short explanation of the issue and where it was identified.

2. Technical Description

Explain the underlying weakness and affected component.

3. Steps to Reproduce

Provide safe, concise, repeatable steps.

4. Evidence

Include sanitized screenshots, relevant HTTP traffic, logs, or command output.

5. Potential Impact

Describe what an attacker could realistically achieve and under which conditions.

6. Recommended Remediation

Explain how the issue could be corrected or mitigated.

7. Testing Limitations

Mention any restrictions, assumptions, or validation steps that were not performed.

8. Additional References

Include relevant CVEs, vendor documentation, standards, or security advisories.

A good report should help the recipient reproduce and understand the problem without requiring unnecessary access to sensitive information.

14. Legal and Ethical Considerations

Security research does not operate outside the law.

A vulnerability disclosure policy may define authorized research activities and provide assurances for researchers who comply with its terms. However, those assurances are specific to the organization and the policy.

A few important principles:

Authorization comes first.

A public website, exposed service, or publicly accessible API is not automatically authorized for security testing.

Stay within scope.

Permission to test one domain does not automatically authorize testing its vendors, cloud infrastructure, connected applications, or other third-party systems.

Minimize impact.

Avoid unnecessary access to sensitive information, service disruption, data modification, or persistence.

Stop when sensitive data is encountered.

Follow the policy's instructions. In many programs, researchers are required to stop testing and notify the organization if they encounter personal, financial, or proprietary information.

Do not assume a disclaimer provides legal protection.

Adding "for educational purposes only" to an article does not make unauthorized testing lawful.

Legal requirements depend on the relevant jurisdiction, authorization, agreements, and circumstances.

For example, the Computer Fraud and Abuse Act is a United States federal law. GDPR applies within its defined territorial and material scope. Neither should be presented as a universal legal framework for every security researcher.

This article is educational information, not legal advice.

15. Putting It All Together: From the Venus Lab to a Professional Report

The Venus assessment provides a useful example of why this process matters.

The investigation identified:

Weak credential combinations.
An administrative application path.
Authentication-related cookie data that could be decoded.
A potential PwnKit privilege escalation avenue.
Missing HTTP security headers.

But each observation requires a different level of validation.

The weak credentials should be documented with the authentication evidence.

The cookie issue should explain what was recovered and whether that information actually enabled unauthorized access.

The administrative path should not be described as an access-control vulnerability without evidence of unauthorized access.

The potential PwnKit issue requires package-version verification and exploitation-condition analysis.

The missing headers should be described as configuration weaknesses, with their impact evaluated in the context of the application.

Only after these steps should the assessor determine which findings are suitable for CVSS scoring.

The report should then communicate the technical evidence, severity, limitations, and remediation recommendations.

Because Venus is an intentionally vulnerable lab machine, its assessment is an educational case study — not a real-world vulnerability disclosure to a software vendor or production-system owner.

For the practical investigation, see the companion article:

A Guest Account, a Reversible Cookie, and a Linux Box Called Venus

16. Final Checklist for Security Researchers

Before submitting a vulnerability report, review the following:

Was testing authorized?
Was the affected asset within scope?
Was the finding reproduced?
Is the evidence sufficient?
Have sensitive values been redacted?
Is the security impact clearly explained?
Is the CVSS version identified?
Is the vector string included where a score is reported?
Are the severity assumptions defensible?
Are remediation recommendations actionable?
Was the report submitted through the approved channel?
Is the disclosure timeline coordinated?

If these questions can be answered confidently, the report is much more likely to be useful to the receiving security team.

Conclusion: Finding Vulnerabilities Is Only the Beginning

Technical discovery is important, but it is not the entire job of a security researcher.

A vulnerability must be understood, validated, documented, and communicated.

CVSS provides a common language for describing technical severity. Vulnerability assessment reports turn technical observations into actionable findings. Vulnerability Disclosure Policies provide a structured way for organizations and researchers to communicate.

When these processes work together, security research becomes more valuable.

The goal is not to produce the highest possible severity score or publish the most dramatic proof of concept.

The goal is to provide accurate evidence, communicate realistic risk, respect authorization boundaries, and help organizations improve their security.

A good security researcher doesn't just find weaknesses. They make those weaknesses understandable, reproducible, and fixable.

References and Further Reading

CVSS and vulnerability scoring

Vulnerability disclosure

Disclaimer: This article provides general educational information about vulnerability assessment, CVSS, and responsible disclosure. It is not legal advice. Always obtain appropriate authorization, follow the applicable disclosure policy, and comply with the laws and agreements governing your testing activities.

Contents