Security Bug Reporting

Security Bug Reporting Workflow

Finding Documentation Format

Every security finding must include:

### [SEVERITY] [Short Title]

| Field | Value |
|-------|-------|
| **ID** | SEC-2026-001 |
| **Severity** | Critical / High / Medium / Low / Info |
| **CVSS 3.1** | X.X (vector string optional) |
| **CWE** | CWE-79 (Cross-site Scripting) |
| **OWASP** | A03:2021 Injection |
| **Component** | auth/login.ts |
| **Affected versions** | ≤ 1.2.3 |

#### Description
[Clear explanation of the vulnerability]

#### Steps to Reproduce
1. Navigate to `/api/users/123`
2. Change ID to `124` while authenticated as user A
3. Observe user B's data returned

#### Impact
[What an attacker achieves — data breach, RCE, account takeover]

#### Evidence
\`\`\`typescript
// Vulnerable code at auth/login.ts:42
const user = await db.user.findUnique({ where: { id: req.params.id } });
\`\`\`

#### Proof of Concept (optional)
[Minimal PoC — only in private reports, not public issues]

#### Remediation
\`\`\`typescript
// Recommended fix
const user = await db.user.findUnique({
  where: { id: req.params.id, ownerId: session.user.id }
});
\`\`\`

#### References
- https://cwe.mitre.org/data/definitions/639.html

Severity Classification

CVSS Quick Reference

Base score factors:

• Attack Vector: Network (N) > Adjacent (A) > Local (L) > Physical (P)
• Attack Complexity: Low (L) > High (H)
• Privileges Required: None (N) > Low (L) > High (H)
• User Interaction: None (N) > Required (R)
• Impact: High (H) > Low (L) > None (N) on Confidentiality, Integrity, Availability

Use FIRST CVSS Calculator for precise scoring.

Responsible Disclosure Workflow

For Auditors (reporting TO a project)

1. Do not open public GitHub issues for vulnerabilities
2. Check for SECURITY.md or security@ email
3. Send encrypted report if PGP key provided
4. Allow 90 days coordinated disclosure (industry standard)
5. Do not exploit beyond minimal PoC
6. Agree on disclosure timeline with maintainer

Email Template

Subject: [Security] [Severity] — [Brief description] in [Project]

Hello [Security Team],

I am reporting a security vulnerability in [project] version [X.Y.Z].

**Summary:** [One sentence]

**Severity:** [Critical/High/Medium/Low]

**Affected component:** [file/module/endpoint]

**Description:**
[Detailed description]

**Steps to reproduce:**
1. ...
2. ...

**Suggested fix:**
[Brief remediation guidance]

I will not disclose this publicly before [date + 90 days] to allow time for a fix.

[Your name / handle]

For Project Maintainers (receiving reports)

1. Acknowledge within 48 hours
2. Triage severity within 5 business days
3. Develop and test fix on private branch
4. Release patched version
5. Publish security advisory (GitHub Security Advisories)
6. Credit reporter (with permission)
7. Update CHANGELOG with security fix note

GitHub Security Advisory Template

## Summary
[One paragraph]

## Severity
[Critical/High/Medium/Low] — CVSS X.X

## CVE
CVE-YYYY-NNNNN (if assigned)

## Affected Versions
- < 1.2.4

## Patched Versions
- ≥ 1.2.4

## Description
[Technical details]

## References
- [CWE-XXX](link)

Audit Report Aggregation

When combining multiple findings:

# Security Audit — Findings Report

**Project:** [name]
**Auditor:** [name/tool]
**Date:** YYYY-MM-DD
**Scope:** [commit hash / branch / paths]

## Summary
| Severity | Count |
|----------|-------|
| Critical | 0 |
| High | 2 |
| Medium | 5 |
| Low | 3 |

## Critical/High Findings
[Full write-ups]

## Medium/Low Findings
[Table format for brevity]

## Remediation Priority
1. [SEC-001] Fix IDOR — 2 hours
2. [SEC-002] Upgrade lodash — 30 minutes

What NOT to Include in Public Reports

• Working exploit code for RCE
• Real user data from production
• Unpatched 0-day details before fix is available
• Internal infrastructure details beyond what's necessary