Patch SLA Policy [DRAFT]
STATUS: DRAFT v1.0 — pending legal counsel review.
Operative for internal use; [DRAFT] will be removed once counsel sign-off is recorded.
Owner: Keel — Engineering
Effective: 2026-05-27 (interim; final effective date confirmed at counsel sign-off)
Review cadence: Annual (next review by 2027-05-27)
Applies to: All software dependencies, runtime environments, and infrastructure components of the Keel fund management platform (keel.fund and associated staging environments).
1. Purpose
This policy defines the maximum time allowed between identification of a security vulnerability and deployment of the corresponding patch to production. The goal is to bound exposure for the fund, its limited partners, and connected service providers (banking integrators, e-signature providers, cloud infrastructure) when new CVEs or vendor advisories surface.
2. Severity Classifications
We classify every vulnerability into one of four tiers using CVSS v3.1 base score as the primary signal, with vendor advisory severity as a tie-breaker when CVSS is unavailable.
| Tier | CVSS Range | Examples |
|---|---|---|
| Critical | 9.0 – 10.0 | RCE without authentication, exposed secrets, auth bypass in primary path |
| High | 7.0 – 8.9 | Authenticated RCE, SQL injection on protected endpoint, sandbox escape |
| Medium | 4.0 – 6.9 | Stored XSS, CSRF on non-financial endpoints, denial of service |
| Low | 0.1 – 3.9 | Information leak with negligible PII, dev-only dependencies |
Vulnerabilities affecting components that handle banking data, LP personally identifiable information, or fund finances are escalated one tier higher than the base CVSS would indicate.
3. Time-to-Patch Service Levels
The clock starts at the earlier of: (a) the timestamp of the first GitHub Dependabot alert / vendor advisory the engineering team receives, or (b) the timestamp the issue is first reproduced internally.
| Tier | Time-to-Patch in Production |
|---|---|
| Critical | 7 calendar days |
| High | 30 calendar days |
| Medium | 90 calendar days |
| Low | 180 calendar days |
"Patched" means the fix has been deployed to the production branch and confirmed via post-deploy verification (release notes, monitoring sanity check, or successful re-scan).
4. Process
1. Detection. GitHub Dependabot scans the repository weekly and on every push for npm dependency vulnerabilities. Security advisory alerts are surfaced via GitHub's Security tab and via email to the engineering owner. CISA KEV catalog entries affecting our stack trigger an out-of-band review even if Dependabot has not yet caught them.
2. Triage. Within five business days of detection, the engineering owner records the vulnerability in the engineering log with: CVE identifier, affected component, CVSS score, applicable tier, target patch date (per the SLA table above), proposed remediation.
3. Remediation. Patches are merged via pull request against staging, run through the standard build (Prisma generate, Next.js type-check, build) and a smoke test, then promoted to main via merge. For dependency upgrades that span major versions, the PR may include a targeted regression test or a release-note review.
4. Verification. After production deploy, a re-scan confirms the vulnerability is closed. The engineering log is updated with the resolution date.
5. Audit. Every patch action writes an AuditEvent row capturing actor, timestamp, package name, version delta, and vulnerability identifier. Audit events are retained indefinitely (see Data Retention Policy).
5. Exceptions
A vulnerability MAY exceed its SLA only when one of the following applies, documented in writing in the engineering log:
- Not applicable: the vulnerable code path is provably unreachable in our deployment (e.g., a vulnerable dev-server feature in a production-only environment).
- No upstream fix available: the maintainer has not released a patch. The engineering owner must monitor the upstream issue weekly and apply mitigations (configuration changes, WAF rules, feature disablement) where possible until a fix is published.
- Compensating control in place: an alternative mitigation reduces residual risk below the original tier. The mitigation and residual-risk rationale must be documented.
Any exception older than 30 days is escalated to fund manager review.
6. Roles and Responsibilities
- Engineering owner: triages, schedules, and merges patches; maintains the engineering log; ensures audit events are written.
- Fund manager: reviews exception cases monthly; receives summary report of patch activity quarterly.
- External counsel (when applicable): notified for vulnerabilities with potential LP disclosure implications.
7. Reporting
The engineering owner produces a quarterly patch summary covering: number of vulnerabilities detected by tier, mean time-to-patch by tier, count of exceptions opened/closed, and any SLA breaches with root cause. The summary is retained for at least three years and made available to Plaid and to LP-side due diligence on request.
8. Policy Review
This policy is reviewed annually. Changes require fund manager approval and are recorded with a version note at the top of this file.
Change history
- 2026-05-27 — Initial version (v1.0). Authored alongside Plaid attestation work; pairs with the Vulnerability Scanning policy and the Information Security Policy.