Vulnerability disclosure — report security flaws responsibly

What Is Vulnerability Disclosure?

Vulnerability Disclosure is the process of responsibly reporting discovered security flaws to the software vendor or system owner, allowing time for remediation before public disclosure. Models include: Responsible Disclosure (90 days), Coordinated Disclosure (researcher-vendor collaboration), and Full Disclosure (immediate publication).

Model	Description	Typical Timeline
Responsible Disclosure	Report → time to fix → publication	90 days
Coordinated Disclosure	Researcher + vendor + CERT collaboration	45-90 days
Full Disclosure	Immediate public disclosure	0 days
Bug Bounty	Reporting for compensation within a program	Per program

The industry standard is 90 days (Google Project Zero), after which the researcher may publish details regardless of vendor’s patch status.

Why Disclosure Matters

For researchers:

Legal path to reporting (vs “quietly” or “black market”)
Building reputation in security community
Potential compensation (bug bounty)
Contributing to ecosystem security

For companies:

Learn about flaws before criminals exploit them
Time to fix before public disclosure
Relationships with researcher community
Avoiding 0-days in attacker hands

For users:

Vendors fix vulnerabilities
Risk information (if vendor doesn’t fix)
Safer software

📚 Read the complete guide: Testy Penetracyjne: Testy penetracyjne - rodzaje, metodologie, przebieg

Vulnerability Disclosure Models

Responsible Disclosure (90 Days)

The most common model. Researcher reports privately, gives time to fix, then may publish.

Process:

Researcher discovers vulnerability
Reports privately to vendor (email, form)
Vendor acknowledges receipt (ideally within 24-72h)
Vendor fixes (deadline: 90 days)
Vendor releases patch and advisory
Researcher may publish writeup

Key principles:

90 days is the standard (Google Project Zero, Microsoft)
Extension possible if vendor actively working on fix
Early publication if vendor ignores or vulnerability actively exploited
Credit for researcher in vendor advisory

Who uses it: Google Project Zero, most independent researchers, CERT/CC

Coordinated Vulnerability Disclosure (CVD)

More formal process with coordinator (CERT) involvement.

Participants:

Researcher (finder) — discovers and reports
Vendor — fixes
Coordinator (CERT/CC, national CSIRT) — mediates, coordinates timeline
Users — informed at appropriate time

When CVD instead of simple responsible disclosure:

Vulnerability affects multiple vendors (e.g., protocol flaw)
Vendor not responding
Critical infrastructure (ICS/SCADA)
International coordination needed

Standards:

ISO/IEC 29147:2018 — Vulnerability disclosure
ISO/IEC 30111:2019 — Vulnerability handling processes

Full Disclosure

Immediate public disclosure of vulnerability details.

Arguments FOR:

“Sunlight is the best disinfectant”
Pressure on vendors to patch quickly
Users can protect themselves (workarounds)
History: vendors ignored reports for years

Arguments AGAINST:

Attackers get exploit before patch
Users exposed
Destroys vendor relationships
May be illegal (in some jurisdictions)

When to consider full disclosure:

Vendor ignores report for months
Vulnerability already actively exploited (0-day in the wild)
Vendor threatens lawyers instead of fixing
Critical flaw with no response after multiple attempts

Bug Bounty

Formal programs with compensation for reports.

Platforms:

HackerOne
Bugcrowd
Intigriti
YesWeHack

Benefits:

Clear rules (scope, rewards, safe harbor)
Financial compensation
Legal protection for researcher
Triage by platform

How to Report a Vulnerability - Step by Step

For Researchers

Step 1: Confirm the Vulnerability

Before reporting, ensure:

It’s actually a bug, not a feature or misconfiguration
You have proof (Proof of Concept)
You understand the impact (what attacker can achieve)
You didn’t cause damage during testing

Note: Only test on your own systems or within authorized scope (bug bounty, pentest).

Step 2: Find Contact

Search in order:

security.txt — /.well-known/security.txt or /security.txt
Bug bounty program — HackerOne, company website
Security email — security@example.com
Security page — /security, /responsible-disclosure
CERT — if vendor doesn’t respond

How to check security.txt:

curl https://example.com/.well-known/security.txt
curl https://example.com/security.txt

Step 3: Prepare Your Report

A professional report increases chances of quick fix and reward.

Report template:

Subject: [Security] SQL Injection in /api/search endpoint

## Summary
SQL injection vulnerability in the search API allows authenticated
users to extract arbitrary data from the database.

## Affected Product/Version
- Product: Example App
- Version: 2.3.1 (latest)
- URL: https://app.example.com/api/search

## Vulnerability Type
- CWE-89: SQL Injection
- CVSS 3.1: 8.6 (High)

## Steps to Reproduce
1. Login to app.example.com
2. Navigate to Search feature
3. Enter the following payload in search field:
   ' OR '1'='1' --
4. Observe that all records are returned

## Proof of Concept
[Screenshot showing SQL error]
[Burp request/response - sanitized]

## Impact
An authenticated attacker can:
- Read all data from the database (including other users' data)
- Potentially write data (tested limited, did not exploit further)
- Possible RCE via xp_cmdshell if MSSQL (not confirmed)

## Suggested Remediation
- Use prepared statements / parameterized queries
- Example fix (Python/SQLAlchemy):

  # Vulnerable
  query = f"SELECT * FROM products WHERE name LIKE '%{search}%'"

  # Fixed
  query = select(Product).where(Product.name.like(f"%{search}%"))

## Timeline
- 2026-01-15: Vulnerability discovered
- 2026-01-15: Report submitted
- Disclosure deadline: 2026-04-15 (90 days)

## Researcher Contact
- Name: [Your name]
- Email: [your@email.com]
- PGP: [key ID if available]

## Request
Please acknowledge receipt within 72 hours.
I am happy to provide additional details if needed.

Step 4: Send Encrypted (If Possible)

If vendor provides PGP key in security.txt, use it:

gpg --encrypt --recipient security@example.com report.txt

Step 5: Establish Timeline

Standard: 90 days from report
Extension: +14-30 days if vendor actively working
Shortened: if vulnerability exploited in the wild

Clearly communicate deadline in report.

Step 6: Document Communication

Keep:

All emails (with timestamps)
Response screenshots
Ticket numbers

Useful if: vendor claims they didn’t receive report / timeline dispute / need proof for CV.

Step 7: Publication (Optional)

After fix or deadline, you may:

Publish writeup on blog
Request CVE (if no number assigned)
Present at conferences
Add to portfolio

Publication best practices:

Wait until patch is available
Give users time to update (e.g., +7 days after patch)
Don’t publish working exploits (PoC yes, weaponized exploit no)
Credit vendor if they cooperated well

How Companies Should Handle Reports

Vulnerability Disclosure Policy (VDP)

Every company should have a public vulnerability disclosure policy.

VDP elements:

# Vulnerability Disclosure Policy

## Introduction
[Company] welcomes security researchers who find vulnerabilities
in our systems. This policy describes how to report vulnerabilities
and what you can expect from us.

## Scope
### In-Scope
- *.example.com (production)
- Example Mobile App (iOS, Android)
- Example API (api.example.com)

### Out-of-Scope
- Third-party services (AWS, Cloudflare)
- Social engineering attacks on employees
- Physical attacks
- DoS/DDoS testing

## How to Report
- Email: security@example.com
- PGP Key: [link to key]
- Alternative: HackerOne.com/example

## What to Include
- Description of vulnerability
- Steps to reproduce
- Proof of concept
- Impact assessment

## What We Promise
- Acknowledge within 48 hours
- Provide status update within 14 days
- No legal action if you follow this policy
- Credit in security advisory (if desired)

## Timeline
- We aim to fix critical vulnerabilities within 30 days
- High: 60 days
- Medium/Low: 90 days
- We will coordinate disclosure date with you

## Safe Harbor
We will not pursue legal action against researchers who:
- Act in good faith
- Do not access data beyond what is necessary
- Do not disrupt our services
- Do not disclose publicly before agreed timeline
- Do not exploit the vulnerability for personal gain

## Recognition
We maintain a Hall of Fame at [url] for researchers who help us.
We do not currently offer monetary rewards (but thank you!).

## Contact
security@example.com
PGP: 0xABCD1234

security.txt - RFC 9116 Standard

The /.well-known/security.txt file is a standard informing researchers how to report vulnerabilities.

Example security.txt:

# Example Corp Security
Contact: mailto:security@example.com
Contact: https://hackerone.com/example
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/vdp
Acknowledgments: https://example.com/security/hall-of-fame
Hiring: https://example.com/careers/security

Fields:

Contact — where to report (email, URL) — required
Expires — when file becomes invalid — required
[Encryption](/en/glossary/encryption/) — PGP key for encrypting reports
Preferred-Languages — preferred languages
Policy — link to full VDP
Acknowledgments — Hall of Fame
Hiring — security job openings

Generators:

Best Practices for Companies

DO:

Respond quickly (24-72h acknowledgment)
Be transparent about fix timeline
Thank researchers (Hall of Fame, swag, bounty)
Treat researchers as partners, not enemies
Provide regular status updates

DON’T:

Don’t ignore reports
Don’t threaten with lawyers
Don’t lie about timeline (“almost ready” for 6 months)
Don’t try to get researcher data to prosecute them
Don’t trivialize vulnerabilities (“that’s not a bug”)

Legal Aspects

Is Vulnerability Reporting Legal?

US Computer Fraud and Abuse Act (CFAA): Unauthorized access to computer systems is a federal crime. However:

Reporting itself is not a crime
How you discovered it might be (unauthorized access)
Safe harbor in VDP protects researchers (agreement with company)
Without VDP — legal gray area

How to protect yourself:

Only test within authorized scope (bug bounty, VDP)
Minimize access (don’t download all data “to prove it”)
Document that you acted in good faith
Don’t extort the vendor

NIS2 and Vulnerability Disclosure

The NIS2 Directive (Art. 12) introduces requirements:

Essential and important entities shall implement coordinated vulnerability disclosure policies.

What this means:

Companies under NIS2 must have VDP
Must have a process for handling reports
Must cooperate with coordinators (CERT)

EU Cyber Resilience Act

The CRA (2024) requires:

Manufacturers must have vulnerability handling processes
Must report actively exploited vulnerabilities to ENISA
Products must have security.txt equivalent

CVE - How the Vulnerability Numbering System Works

What Is CVE?

CVE (Common Vulnerabilities and Exposures) is a global vulnerability identification system. Each known flaw gets a unique number: CVE-YYYY-NNNNN.

Example: CVE-2021-44228 (Log4Shell)

Who Assigns CVE Numbers?

MITRE — main CVE program administrator
CNA (CVE Numbering Authority) — organizations authorized to assign CVEs
- Microsoft, Google, Red Hat, Cisco… (vendors)
- CERT/CC, JPCERT, ICS-CERT… (coordinators)
- GitHub, HackerOne… (platforms)

How to Request a CVE

If vendor is a CNA:

Report vulnerability to vendor
Vendor assigns CVE themselves

If vendor is not a CNA:

Report vulnerability to vendor
After fix/disclosure, submit to MITRE: https://cveform.mitre.org/
Or through CNA partner (CERT/CC, GitHub)

Required information:

Vulnerability description
Affected product/version
Type (CWE)
Impact
References (advisory, PoC)

CVSS - Common Vulnerability Scoring System

Severity assessment scale (0.0 - 10.0).

Range	Severity	Example
0.0	None	-
0.1 - 3.9	Low	Information disclosure (limited)
4.0 - 6.9	Medium	XSS, CSRF
7.0 - 8.9	High	SQL Injection, auth bypass
9.0 - 10.0	Critical	RCE, full compromise

CVSS Calculator: https://www.first.org/cvss/calculator/3.1

FAQ

Can I report a vulnerability anonymously?

Yes, but:

Complicates communication (vendor can’t ask for details)
You won’t get credit / bounty
You can use a pseudonym or ProtonMail

What if the company doesn’t respond?

Try alternative channels (Twitter DM to security team, LinkedIn)
Report to CERT (CERT/CC, US-CERT)
After 90 days, consider public disclosure
Consult a lawyer before full disclosure

Will I get paid without a bug bounty?

Usually no. But:

Some companies pay “ad hoc” for good reports
You can negotiate (especially for critical issues)
Credit and reputation have value too

How long should I wait before publishing?

Standard: 90 days from report
After patch: +7 days (give users time to update)
Vendor actively working: consider extension
Vendor ignoring: 90 days, then your decision

Can I go to the media?