Vulnerability Disclosure: CVD, VDP, Bug Bounty and Responsible Disclosure

Every day, security researchers, penetration testers, and occasionally even ordinary users discover security vulnerabilities in other companies’ products and services. In 2019, a security researcher reported a critical vulnerability in a German online store—the company filed a criminal complaint under the “hacker clause.” The researcher was acquitted, but the case shows that without a clear vulnerability disclosure policy, security researchers face legal uncertainty, and companies miss out on valuable vulnerability reports.

The Three Disclosure Models

1. Full Disclosure (Immediate Publication)

The researcher publishes all details of the vulnerability immediately—including exploit code—without first contacting the affected company.

Argument in favor: Maximum pressure on vendors; rapid public disclosure protects everyone. Argument against: Attackers can exploit the vulnerability immediately before patches are distributed.

Accepted for: Systems that are already being actively exploited ("0-day in the wild") when the vendor has not responded for years.

2. Coordinated Vulnerability Disclosure (CVD) – the standard

ISO/IEC 29147 and ISO/IEC 30111 define this process internationally.

CVD Process:

Researcher discovers vulnerability
        ↓
Researcher contacts vendor (CERT, security@vendor.com, HackerOne)
        ↓
Vendor confirms vulnerability (ideally < 7 days)
        ↓
Joint coordination of the fix
        ↓
Patch is developed and distributed (90-day standard deadline)
        ↓
CVE number is assigned
        ↓
Coordinated release: Patch + disclosure simultaneously

3. Non-Disclosure

Vulnerability is reported confidentially to the vendor and closed without public disclosure after a patch is released. Rarely used, e.g., for critical infrastructure.

VDP vs. Bug Bounty - Difference and Distinction

Vulnerability Disclosure Program (VDP):
  Definition: Formalized process for reporting vulnerabilities
  Reward: NONE (only recognition, Hall of Fame)
  Goal: Protect security researchers + retain vulnerabilities
  Scope: Clearly defined what may be tested
  Suitable for: All companies, starting now!

Bug Bounty Program:
  Definition: VDP + financial reward for valid findings
  Reward: 100–100,000+ EUR depending on severity
  Goal: Attract motivated researchers for more intensive testing
  Suitable for: When an internal security team is available (triage resources!)
  Caution: Without good triage → program turns into chaos

When to use which:
  Start: VDP (free, low effort)
  Growth: VDP → Bug Bounty if:
  □ Internal security team available for triage
  □ Budget for payouts (typically 50,000–200,000 EUR/year)
  □ Program management resources (1–2 people)

The 90-day deadline

Google Project Zero (Google’s internal security research team) popularized the 90-day deadline: If a vendor has not released a patch after 90 days, Google publishes the details—even without a patch.

Result: A significant acceleration in patch development among major vendors. Microsoft, Apple, Adobe—all have optimized their processes to be able to respond within 90 days.

Exceptions: For actively exploited zero-days: 7 days. For particularly critical infrastructure: up to 120 days.

CVE - Common Vulnerabilities and Exposures

Every publicly known vulnerability is assigned a standardized CVE identifier:

CVE-2024-3094  → XZ Utils Backdoor (2024)
CVE-2021-44228 → Log4Shell (2021)
CVE-2017-0144  → EternalBlue (WannaCry, 2017)

Format: CVE-[Year]-[Sequential Number]

CVE Assignment: Through CVE Numbering Authorities (CNAs) – MITRE is the primary CNA; major vendors are CNAs themselves (Microsoft, Apple, Red Hat).

CVSS Score: Each CVE receives a CVSS v3/v4 score (0–10) that quantifies severity, attack complexity, and impact.

Security.txt - Contact Information for Researchers

RFC 9116 - security.txt:

Location (according to RFC):
  https://www.example.com/.well-known/security.txt
  https://example.com/security.txt  (alternative)

Complete security.txt with PGP signature:
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA256

  Contact: mailto:security@example.com
  Contact: https://example.com/security
  Expires: 2027-12-31T23:59:59.000Z
  Encryption: https://example.com/pgp-key.txt
  Acknowledgments: https://example.com/security/hall-of-fame
  Preferred-Languages: de, en
  Canonical: https://example.com/.well-known/security.txt
  Policy: https://example.com/security/disclosure-policy

  -----BEGIN PGP SIGNATURE-----
  [PGP signature]
  -----END PGP SIGNATURE-----

Important: PGP signature recommended!
  → Researchers can verify authenticity
  → Prevents fake security.txt files (redirect attacks)
  → gpg --clearsign security.txt

Check security.txt:
  curl https://www.example.com/.well-known/security.txt
  # Tool: securitytxt.org/checker

Why security.txt is important:

• Researchers know immediately where reports go
• No reports sent to incorrect addresses (support@, info@)
• Demonstrates security maturity and openness to external reports
• BSI and CERT-Bund use security.txt for automated monitoring

VDP Policy Creation

Elements of a complete VDP policy:

1. Scope (What can be tested?):

   IN SCOPE:
   → Web applications under *.company.com
   → Mobile apps (iOS App Store / Google Play Store – specify App IDs!)
   → API endpoints: api.company.com
   → Publicly accessible infrastructure

   OUT OF SCOPE (explicitly exclude!):
   → Third-party software (WordPress Core, etc.)
   → Physical security
   → Social engineering targeting employees
   → Denial-of-service attacks
   → Tests that affect other users!
   → Sub-processors/third-party providers: Explicitly exclude!

   Important: Vaguely worded scope = Researchers test more than expected!

2. Safe Harbor Clause (Core of the VDP):

   Sample text:
   "COMPANY acknowledges that security research is important.
   If you follow our policy in good faith, COMPANY will:

   - Not file criminal charges under §202a StGB or similar laws
   - Not initiate civil lawsuits for VDP-compliant activities
   - Notify authorities if we are contacted by researchers acting under the VDP
   - Ensure that our relevant parties are aware that you are acting within the scope of the VDP

   This Safe Harbor applies ONLY if:
   → No data is exfiltrated (only proof of the vulnerability)
   → No systems are intentionally damaged
   → Only in-scope systems are tested
   → A report is submitted as soon as possible after discovery"

3. Timeline Expectations:

   Acknowledgment:    Within 72 hours
   Initial Triage:    Within 7 days
   Remediation:       CVSS 9-10 (Critical): 7 days
                      CVSS 7-8.9 (High): 30 days
                      CVSS 4-6.9 (Medium): 90 days
                      CVSS 0-3.9 (Low): 180 days
   Coordinated disclosure: after remediation, possibly with the researcher

4. Report requirements:
   □ Type of vulnerability (e.g., SQL injection, SSRF)
   □ Affected URL / endpoint
   □ Impact description
   □ Step-by-step reproduction (PoC)
   □ Optional: Recommendation for remediation
   □ Your contact information (for follow-up questions)

Bug bounty platforms

HackerOne:
  Market leader: 3,000+ companies, 500,000+ researchers
  Models: Private program + Public program
  Features: Triage-as-a-Service, Pentest-on-demand
  Costs: 20,000+ EUR/year platform fees + bounties
  Notable programs: Twitter, Uber, GitHub, DOD (U.S. Government), Lufthansa

Bugcrowd:
  Competitor to HackerOne, focus: Enterprise + Government
  Crowdcontrol: Managed triage service
  Notable programs: Tesla, Mastercard, Twilio

Intigriti (European):
  GDPR-compliant: Data stored in the EU
  Strong presence in the DACH region and the UK
  Cost: More affordable than US platforms
  Notable programs: European banks, Siemens, BMW
  Recommended for EU companies!

YesWeHack (French):
  EU-based, GDPR-compliant
  Notable clients: OVHcloud, Société Générale
  Good for smaller European companies

In-house program (no platform):
  Advantages: no platform fees, full control
  Disadvantages: no triage support, manual processing, limited researcher reach
  Suitable for: Startups, SMEs with a limited budget

Scope Definition and Bounty Structure

Define the scope correctly:

Asset types:
  Wildcard: *.example.com (all subdomains, inclusive!)
  Specific: api.example.com (only this subdomain)
  Mobile: iOS app "com.example.app"
  Binaries: API client, desktop application

Scope tips:
  → Be cautious with "all domains belonging to example.com"!
    → Acquisitions may introduce unpatched systems
  → Explicitly specify IP ranges if testing is permitted
  → Explicitly and completely define "Out of Scope"

Payout structure (Bounty Table):

  Severity │ CVSS Score │ Bounty Range (Example)
  ────────────┼────────────┼────────────────────────
  Critical    │ 9.0-10.0   │ 5,000 - 25,000+ EUR
  High        │ 7.0-8.9    │ 1,000 - 5,000 EUR
  Medium      │ 4.0-6.9    │ 250 - 1,000 EUR
  Low     │ 0.1–3.9    │ 100–250 EUR
  Informational│ -         │ No bounty (optional: swag)

Common report categories:
  → Critical: RCE, SQL injection with data exfiltration, admin authentication bypass
  → High: SSRF, IDOR involving sensitive data, XSS on admin panel
  → Medium: CSRF, missing rate limiting, information disclosure
  → Low: Missing security headers, self-XSS, open redirect
  → OOS: CVSS-based bugs without proof of impact, SPF configuration alone

Non-bounty-eligible reports (common):
  → "Missing security headers" without proof of impact
  → "SSL 3.0 available" (if no actual attack is demonstrated)
  → CSRF on logout
  → "Password can be as short as 6 characters" (Low, not High)

Triage Process

Processing incoming reports:

Triage workflow:
  1. Acknowledgment of receipt (automatic, within 24–72 hours)
  2. Initial assessment (5–7 business days):
     → Is the report understandable? (Reproducible?)
     → In scope?
     → Duplicate? (Already known?)
     → Initial CVSS assessment
  3. Reproduction (internal):
     → Recreate security issue in test environment
     → Verify impact
  4. Status update to reporter (10 business days)
  5. Patch development (internal)
  6. Payment (after patch or immediately)
  7. Public disclosure (coordinated)

Report quality criteria:
  A good report includes:
  □ Affected URL/endpoint
  □ Step-by-step reproduction
  □ Evidence (screenshot, HTTP request/response, video)
  □ Impact description (what can an attacker do?)
  □ Suggested fix (not mandatory, but valuable)

  Why bad reports fail:
  → "Your website is insecure" (no concrete finding)
  → Missing steps to reproduce
  → Theoretical vulnerability without PoC
  → Out of scope (scanner output submitted)

CVSS Rating:
  AV (Attack Vector):  N=Network, A=Adjacent, L=Local, P=Physical
  AC (Complexity):       L=Low, H=High
  PR (Privileges Required): N=None, L=Low, H=High
  UI (User Interaction): N=None, R=Required
  S (Scope):             U=Unchanged, C=Changed
  C/I/A (Impact):        N=None, L=Low, H=High

  Example (IDOR with data access):
  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N → 6.5 (Medium)

Escalation Matrix:
  CVSS 9-10: IMMEDIATELY! Emergency patch, notify CTO
  CVSS 7-8.9: High-priority ticket, 30-day fix
  CVSS 4-6.9: Normal ticket, sprint planning
  CVSS 0-3.9: Backlog, next maintenance cycle

Difficult report types:
  "Informational" (not actually a bug):
  → SPF record missing → no direct exploit → Informational
  → HTTP header recommendation → Informational
  → Action: Close with explanation, no bounty

  Out-of-scope:
  → Third-party software, physical, DoS
  → Action: Close + explain why out-of-scope

Hall of Fame and Researcher Communication

Maintain researcher relationships:

Hall of Fame:
  → Security researchers are proud of their findings
  → Hall of Fame = strong motivational factor
  → Dedicated page: https://example.com/security/acknowledgments
  → Entry: Name/Handle + Year + Type of finding

Communication:
  → Always polite, even with duplicates or out-of-scope reports
  → Provide a reason for rejection (Researchers want to understand!)
  → Status updates: Don’t leave researchers in the dark
  → Upon fix: Proactively inform + payout timeline
  □ Never: Ignore a report, don’t give a response!

Incentive programs:
  → Swag (T-shirts, stickers): Inexpensive, researchers appreciate it
  → CVE assignment: More valuable to researchers than money!
  → Letter of Appreciation (for researchers not eligible for a bounty)
  → Early access to beta features: especially for regular researchers

Metrics and Program Health

KPIs for VDP/Bug Bounty Programs:

Volume Metrics:
  Total Reports: Incoming reports/month
  Valid Findings: % of reports that are genuine and in-scope
  Duplicates: % of duplicate reports (>50% duplicates → known issue!)

Quality Metrics:
  Time to Triage: Hours from report to triage decision
  Time to Resolution: Days from confirmation to fix
  Resolution Rate: % of findings that were resolved

Budget Metrics:
  Average Bounty: Average payout per finding
  Cost per Finding: Total cost / Number of valid findings
  ROI: "What would a professional penetration test have cost for these findings?"

Community Metrics:
  Active Researchers: Researchers who have been active in the last 90 days
  Researcher Retention: Do top researchers return?

Program maturity levels:
  Level 1 (VDP): Policy in place, email submission
  Level 2: Triage process, 72-hour acknowledgment
  Level 3: Platform (HackerOne/Intigriti), tracking
  Level 4: Bug bounty, monetary reward
  Level 5: Private → Public program, Hall of Fame, CVEs

Legal Situation in Germany

The Problem: Section 202a StGB

Section 202a StGB ("Data Espionage") is broadly worded: "Whoever, without authorization, gains access for themselves or another person to data that is not intended for them and that is specially secured against unauthorized access..."

Theoretically, a security researcher who discovers a vulnerability in a third-party system—even without malicious intent—could fall under §202a.

Summary of the legal situation in Germany:
  Hacking provision §202a StGB: "Data espionage"
  → Punishable: Bypassing access security without authorization
  → NOT punishable: Testing with explicit permission (Safe Harbor)
  → Safe Harbor clause in VDP policy = legal basis for researchers!

  Important:
  → Safe Harbor in policy is NOT a legal guarantee!
  → Recommendation: Declaration of consent + explicit authorization
  → Involve an IT law attorney when drafting the policy!
  → BugBounty DE: Consortium of German companies for clear framework conditions

Vulnerability Disclosure for Your Own Systems: Recommendations

For Companies:

1. Set up security.txt (10 minutes)
2. Set up a Security@ email address (with PGP key)
3. Define internal processes:
   • Who receives reports? (Security Officer)
   • Who decides on acknowledgment/patch priority?
   • Who communicates with the researcher?
4. Acknowledgments page ("Hall of Fame") – shows appreciation
5. Communicate realistic response times (e.g., 7 days for acknowledgment, 90 days for a patch)
6. Plan a base bounty for critical findings (even for very small programs)

For security researchers:

1. Check the company’s scope (is there a bug bounty program?)
2. Test only on authorized systems
3. Do not exfiltrate data—only prove the existence of the vulnerability
4. Provide written documentation (screenshot, proof-of-concept)
5. Report via encrypted email (PGP) to security@ or CERT-Bund
6. Wait for a reasonable period (at least 90 days)