Skip to content

Security Vulnerability Response

Process for handling reported security vulnerabilities. See also SECURITY.md for the public-facing policy.

Response Timeline

Step SLA Action
Acknowledge < 48h Confirm receipt to the reporter
Assess < 7 days Determine severity (Critical / High / Medium / Low)
Fix < 14 days (Critical), < 30 days (other) Develop and test the fix
Release Same day as fix Publish patched version
Disclose After release Publish GitHub Security Advisory

Severity Assessment

Severity Criteria Example
Critical Remote exploitation, data breach, no auth required SQL injection in upload endpoint
High Significant impact, some conditions required Path traversal on file download
Medium Limited impact or requires authenticated access XSS in analysis results display
Low Minimal impact, theoretical only Information disclosure in error messages

Fix Process

  1. Create a private branch — never push vulnerability details to a public branch before the fix is released
  2. Develop the fix — include a regression test
  3. Run the security audit — docs/audit/audits/08-security.md
  4. Review — at least one maintainer must review the fix
  5. Release — tag, build, deploy (see deployment checklist)
  6. Publish advisory — GitHub Security Advisory with CVE if applicable

Advisory Template

# Security Advisory: [Title]

**Severity**: Critical | High | Medium | Low
**Affected versions**: < X.Y.Z
**Fixed in**: X.Y.Z
**CVE**: CVE-YYYY-NNNNN (if assigned)

## Description

[What the vulnerability is, without providing exploitation details]

## Impact

[What an attacker could do]

## Mitigation

[Upgrade to X.Y.Z or apply workaround]

## Credit

[Reporter name, unless they prefer anonymity]

Dependency Vulnerabilities

Run regular dependency audits:

# Backend
cd document-parser && pip audit

# Frontend
cd frontend && npm audit

For known vulnerabilities in dependencies: - Critical/High: Update immediately, release a patch version - Medium/Low: Include in the next planned release