Vulnerability Management
Owner: Backend Lead Last Edited: April 2, 2026 Last Reviewed: April 2, 2026
1. Intake Sources
| Source | What it covers | Who reviews |
|---|---|---|
| GitHub Dependabot alerts | Vulnerable Go modules and npm packages | Backend Lead (weekly) |
| GitHub dependency review | New vulnerable deps introduced in PRs | Enforced in CI — blocks merge on high/critical |
| GitHub CodeQL | SAST — code-level vulnerabilities in Go and TypeScript | Backend Lead (weekly, or on PR alerts) |
| GitHub secret scanning | Accidentally committed secrets | Immediate — push protection blocks at commit time |
| Manual security review | Architecture, auth model, new feature risk | Per major feature or quarterly |
| External report | Reported by user, partner, or researcher | Incident response (see docs/security/incident-response.md) |
Automated scanning is configured in .github/workflows/codeql.yml, .github/workflows/dependency-review.yml, and .github/dependabot.yml.
2. Severity Definitions
Use GitHub's CVE CVSS score as the baseline for dep vulnerabilities. For code findings, use the CodeQL severity label.
| Severity | CVSS range | Description |
|---|---|---|
| Critical | 9.0–10.0 | Remotely exploitable with no authentication; direct data exposure or RCE |
| High | 7.0–8.9 | Exploitable with limited preconditions; significant impact |
| Medium | 4.0–6.9 | Requires specific conditions; moderate impact |
| Low | 0.1–3.9 | Limited exploitability or impact |
3. Patch SLAs
| Severity | SLA from detection |
|---|---|
| Critical | 24 hours |
| High | 7 days |
| Medium | 30 days |
| Low | Next scheduled sprint |
SLAs apply to production-reachable vulnerabilities. If a vulnerable code path is confirmed unreachable in production (e.g. a dep used only in tests), the SLA applies to the next tier down.
4. Triage Process
When a Dependabot alert or CodeQL finding appears:
- Read the advisory. Understand what the vulnerability is and what conditions trigger it.
- Assess reachability. Is the vulnerable code path actually called in production? Is the vulnerable version actually in use?
- Assign severity using the table above or the advisory CVSS score.
- Check for a fix. Is a patched version of the dep available?
- Act per SLA. Open a fix PR, or document an exception with justification if no patch exists.
- Log it in the vulnerability log below.
5. Exception Process
If a vulnerability cannot be patched within the SLA (no fix available, breaking change):
- Document the exception: vulnerability ID, reason for exception, compensating controls, expected resolution date.
- Get sign-off from Backend Lead.
- Re-review at the next sprint to check for an available fix.
Store exceptions in docs/audit/vuln-exceptions/.
6. Vulnerability Log
Track all confirmed findings and their resolution here.
| Date found | Source | CVE / Finding ID | Severity | Affected dep/file | Status | Resolved date | Notes |
|---|---|---|---|---|---|---|---|
| — | — | — | — | — | — | — | — |
7. Security Review Schedule
| Activity | Frequency | Owner |
|---|---|---|
| Dependabot alert review | Weekly | Backend Lead |
| CodeQL finding review | Weekly (or on alert) | Backend Lead |
| Access review | Monthly | Admin |
| Manual code security review | Per major feature | Backend Lead |
| External penetration test | Annually (target) | Backend Lead — deferred until SOC 2 prep or first enterprise customer requires it |
8. Related Docs
.github/dependabot.yml— automated dep update config.github/workflows/codeql.yml— SAST scanning.github/workflows/dependency-review.yml— PR dep review enforcementdocs/security/incident-response.md— for critical/actively exploited vulnsdocs/security/secrets-management.md— for secret exposure findings