Files
gh-greyhaven-ai-claude-code…/skills/security-analysis/templates/security-report.md
2025-11-29 18:29:28 +08:00

7.2 KiB
Raw Blame History

Security Vulnerability Report

Report ID: VULN-YYYY-### Date: YYYY-MM-DD Severity: [Critical | High | Medium | Low] CVSS Score: X.X Status: [Open | In Progress | Resolved | Verified] Reporter: [Name or Team]


Executive Summary

For non-technical stakeholders

Brief description of the vulnerability in business terms (2-3 sentences). Focus on impact to users, data, or business operations.

Example:

A critical SQL injection vulnerability was discovered in the user search endpoint that allows attackers to extract all customer data from the database, including names, emails, and payment information. This vulnerability affects all users of the application and could result in a significant data breach if exploited.


Vulnerability Details

Description

Technical description of the vulnerability. What is broken and why?

Affected Systems:

  • Component: [API endpoint, database, authentication system, etc.]
  • Version: [Software version number]
  • URL/Location: [https://api.greyhaven.io/users/search]
  • Environment: [Production | Staging | Development]

Attack Vector: [Network | Adjacent | Local | Physical]

OWASP Category: [A03:2021 - Injection]

CVSS v3.1 Scoring

Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Metric Value Justification
Attack Vector (AV) [N/A/L/P] How is it exploited?
Attack Complexity (AC) [L/H] Difficulty of exploitation
Privileges Required (PR) [N/L/H] Authentication needed?
User Interaction (UI) [N/R] Victim must act?
Scope (S) [U/C] Affects other components?
Confidentiality (C) [H/L/N] Data disclosure?
Integrity (I) [H/L/N] Data modification?
Availability (A) [H/L/N] Service disruption?

Base Score: X.X ([Critical | High | Medium | Low])


Proof of Concept

Exploitation Steps

  1. Step 1: Description

    # Command or code
    
  2. Step 2: Description

    # Command or code
    
  3. Step 3: Description

    # Expected result
    

Evidence

Screenshots, logs, or output demonstrating successful exploitation

[Paste actual output or attach screenshot]

Affected Code

File: path/to/vulnerable/file.ts Lines: 42-58

// Vulnerable code snippet
export async function searchUsers(query: string) {
  // ❌ VULNERABLE: String concatenation in SQL query
  const sql = `SELECT * FROM users WHERE username LIKE '%${query}%'`;
  return await db.query(sql);
}

Business Impact

Risk Assessment

Likelihood: [High | Medium | Low]

  • How likely is exploitation in the wild?

Impact: [Critical | High | Medium | Low]

  • What is the worst-case outcome?

Overall Risk: [Critical | High | Medium | Low]

  • Likelihood × Impact

Potential Consequences

  • Data Breach: Description of data exposure (e.g., 500K user records)
  • Financial Loss: Estimated monetary impact (e.g., $500K in GDPR fines)
  • Reputational Damage: Impact on brand trust
  • Regulatory Compliance: Which regulations violated (GDPR, PCI DSS)

Affected Users

  • User Count: [X users affected]
  • User Types: [All users | Admin users | Specific tenant]
  • Geographic Scope: [Global | EU | US only]

Remediation

Immediate Mitigation (Temporary Fix)

Timeline: Implement within [X hours]

Quick workaround to reduce risk while developing permanent fix

Steps:

  1. Temporary mitigation step 1
  2. Temporary mitigation step 2

Code Example (if applicable):

// Temporary workaround
export async function searchUsers(query: string) {
  // ✅ TEMPORARY: Input validation regex
  if (!/^[a-zA-Z0-9_-]+$/.test(query)) {
    throw new Error('Invalid query');
  }
  const sql = `SELECT * FROM users WHERE username LIKE '%${query}%'`;
  return await db.query(sql);
}

Permanent Fix

Timeline: Deploy within [X days]

Complete solution that eliminates the vulnerability

Steps:

  1. Implementation step 1
  2. Implementation step 2
  3. Testing step
  4. Deployment step

Code Example:

// ✅ SECURE: Parameterized query with Drizzle ORM
import { eq, like } from 'drizzle-orm';

export async function searchUsers(query: string) {
  // ✅ Input validation
  if (query.length > 100) {
    throw new Error('Query too long');
  }

  // ✅ Parameterized query (SQL injection safe)
  return await db.query.users.findMany({
    where: like(users.username, `%${query}%`)
  });
}

Testing & Verification

Test Cases:

  • Normal input: alice → Returns matching users
  • Malicious input: '; DROP TABLE users-- → Rejected/escaped
  • SQL injection attempt: ' OR '1'='1 → No unauthorized access
  • Automated test: bun test security/sql-injection.test.ts

Verification Steps:

  1. Deploy fix to staging
  2. Run penetration test suite
  3. Verify vulnerability no longer exploitable
  4. Code review by security team
  5. Deploy to production
  6. Monitor for 48 hours

Timeline

Date Event Responsible
YYYY-MM-DD Vulnerability discovered [Name]
YYYY-MM-DD Security team notified [Name]
YYYY-MM-DD Initial assessment completed Security Team
YYYY-MM-DD Temporary mitigation deployed DevOps
YYYY-MM-DD Permanent fix developed Engineering
YYYY-MM-DD Fix deployed to production DevOps
YYYY-MM-DD Vulnerability verified fixed Security Team
YYYY-MM-DD Report published (if public) Security Team

References

CVE/CWE

  • CVE: [CVE-YYYY-XXXXX] (if assigned)
  • CWE: [CWE-89: SQL Injection]
  • OWASP: [A03:2021 - Injection]

Documentation

Similar Incidents

  • Link to similar vulnerabilities in your organization
  • External references to similar attacks (if applicable)

Compliance Mapping

Affected Compliance Requirements:

  • PCI DSS 4.0: Requirement 6.2 (Secure Development)
  • GDPR: Article 32 (Security of Processing)
  • SOC 2: CC6.1 (Logical Access Controls)

Lessons Learned

Root Cause Analysis

What caused this vulnerability to exist?

Example:

The vulnerability was introduced in commit abc123 when developers implemented user search without using the ORM. Code review did not catch the SQL injection vulnerability because security review was not part of the PR checklist.

Prevention Measures

How can we prevent this class of vulnerabilities in the future?

  • Add SQL injection test cases to CI/CD
  • Enforce Drizzle ORM usage (eslint rule)
  • Security training on parameterized queries
  • Mandatory security review for database changes
  • Run bun audit and bandit in CI/CD

Sign-Off

Reported by: _______________________ Date: ___________

Verified by: _______________________ Date: ___________

Approved for Closure: _______________________ Date: ___________


Template Version: 1.0.0 Last Updated: 2025-01-06