Back to Insights
5 min read

The Anatomy of a Responsible Disclosure

Responsible disclosure is a process, not a moment. From the initial discovery of a vulnerability to the final confirmation that a patch has been deployed, a coordinated disclosure can span weeks or months. Understanding each phase helps both researchers and organizations navigate it effectively.

This article walks through the lifecycle of a fictional but realistic vulnerability disclosure, illustrating the decisions and communications involved at each stage.

Phase 1: Discovery

During routine reconnaissance of a SaaS application's API surface, a researcher identifies that the /api/v2/documents endpoint returns documents belonging to other organizations when supplied with sequential document IDs. The endpoint requires authentication, but does not verify that the authenticated user has access to the requested document.

This is a classic Broken Object-Level Authorization (BOLA) vulnerability. The researcher notes the endpoint, the request format, and the nature of the data exposed (internal business documents, potentially containing sensitive information).

At this stage, the researcher accesses only the minimum data necessary to confirm the issue — typically their own test data plus one or two adjacent records to verify the pattern. No bulk data access, no exfiltration.

Phase 2: Validation

Before reporting, the researcher validates the finding to ensure it is genuine and reproducible:

  • Confirms the issue exists across multiple document IDs (not a one-off data leak)
  • Verifies it affects different user accounts (not just their own test account)
  • Tests whether the issue exists in other API versions or related endpoints
  • Assesses the CVSS score based on attack vector, complexity, and impact

In this case, the vulnerability scores a CVSS 7.5 (High): network-accessible, low complexity, no user interaction required, with significant confidentiality impact. The researcher documents the full attack chain with screenshots and HTTP request/response pairs.

Phase 3: Reporting

The researcher looks for a responsible disclosure channel. They check:

  • /.well-known/security.txt on the target domain
  • A security page or VDP on the company website
  • Bug bounty program listings on HackerOne or Bugcrowd
  • A security@ email address

Finding a security.txt file with a contact email, the researcher sends a structured report containing:

  • Summary: One-paragraph description of the vulnerability
  • Affected system: The specific API endpoint and version
  • Reproduction steps: Exact HTTP requests to reproduce the issue
  • Impact assessment: What data is exposed, to whom, and under what conditions
  • CVSS score: With breakdown of scoring factors
  • Remediation suggestions: Implement document ownership verification before returning data

The report is sent via encrypted email. The researcher includes their disclosure timeline expectations: 90 days to remediate before any public disclosure is considered.

Phase 4: Coordination

Within 48 hours, the organization's security team acknowledges receipt. They confirm the issue is valid and provide an internal tracking reference. Over the next several weeks, the coordination involves:

  • The security team requests clarification on one reproduction step
  • The researcher provides additional detail and offers to verify the fix
  • The organization shares their remediation timeline: a patch in the next sprint (3 weeks)
  • Both parties agree on a disclosure timeline

Good coordination is characterized by clear communication, mutual respect, and shared goals. The researcher is not an adversary — they are a collaborator who found something the organization's own testing missed.

Phase 5: Remediation and Closure

The organization deploys a fix that adds proper authorization checks to the documents endpoint. They notify the researcher and invite verification.

The researcher confirms:

  • The original reproduction steps no longer work
  • Accessing other users' documents now returns a 403 Forbidden
  • The fix appears comprehensive (not just a patch for the specific IDs tested)

With verification complete, the disclosure is closed. The organization adds the researcher to their security acknowledgments page, and both parties agree that no public advisory is needed since no user data was compromised.

Lessons Learned

This scenario illustrates several principles that apply to every disclosure:

  • Minimum access: The researcher accessed only enough data to confirm the vulnerability. Restraint builds trust.
  • Structured reporting: A clear, well-organized report accelerates triage and remediation. The security team should not have to guess what the issue is.
  • Defined timelines: Both parties benefit from explicit expectations about response times and remediation windows.
  • Verification: Confirming the fix is genuine closes the loop and ensures the vulnerability is actually resolved, not just patched superficially.
  • Professional relationship: The interaction is collaborative, not adversarial. Both sides are working toward the same goal: a more secure system.

Responsible disclosure works when both parties engage in good faith. Researchers need safe harbor protections and clear reporting channels. Organizations need structured reports and reasonable timelines. When these elements align, vulnerabilities are fixed, users are protected, and the security ecosystem improves.