Published in draft, pending legal counsel review, and subject to change.
← All Policies
Powered by Keel · Platform policy

EOL Software Management 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 versions, infrastructure components, and third-party services in the Keel fund management platform.

1. Purpose

End-of-life (EOL) software no longer receives security patches, leaving the fund and its limited partners exposed to vulnerabilities the vendor will never fix. This policy defines how we inventory dependencies, monitor for EOL announcements, and decide between upgrading, replacing, or accepting documented residual risk.

2. Scope

This policy covers:

  • Application dependencies declared in package.json and resolved to specific versions in package-lock.json.
  • Language runtimes: Node.js (declared in .nvmrc / Vercel build config), Prisma generator versions.
  • Database engines and platform services: PostgreSQL (Neon), Vercel platform features, Vercel Blob, Resend, Anvil, Anthropic API, Plaid.
  • CI/CD tooling: GitHub Actions runner versions and action versions (managed via Dependabot — see Patch SLA Policy).
  • Browser support targets for the consumer-facing app and investor portal.

3. EOL Detection

We rely on multiple signals so a single missed feed doesn't leave us blind:

1. GitHub Dependabot security advisories — fire when a CVE is published for a resolved dependency. EOL packages that no longer receive patches typically generate an unresolved advisory (no fixed version available).

2. endoflife.date — monitored for the runtime tier (Node.js LTS calendar, PostgreSQL major version support, browser versions). Engineering owner checks the relevant pages quarterly.

3. Vendor announcements — Vercel, Neon, Resend, Anvil, Plaid, Anthropic each publish their own deprecation timelines. Engineering owner subscribes to the announcement channels (changelog RSS, account-bound email notifications).

4. NPM deprecation flags — npm install surfaces deprecation warnings on packages whose maintainers have marked them deprecated. Build logs are reviewed monthly for new warnings.

4. Risk Assessment

When a dependency or component is announced EOL, the engineering owner records the following within 10 business days:

  • Component name and version range affected.
  • EOL date (last supported patch date from the vendor).
  • Exposure tier: Critical / High / Medium / Low. Tier matches the Patch SLA classification with one adjustment — any component handling banking data, LP personally identifiable information, payment processing, or authentication is escalated one tier higher than its baseline.
  • Reachability: is the EOL code path actually executed by our deployment, or is it dead weight bundled by a transitive dependency? Reachable code is treated at full tier; unreachable code may be downgraded.
  • Remediation options: upgrade-in-place (drop-in newer version), replace (switch to a different package), or accept-and-document (no fix available, residual risk justified).

5. Decision Criteria

Decisions are time-boxed against the Patch SLA tiers:

TierRequired action by EOL date
CriticalUpgrade or replace BEFORE EOL date. No exceptions for new acquisitions of EOL stack.
HighUpgrade or replace within 30 days of EOL date.
MediumUpgrade or replace within 90 days of EOL date.
LowUpgrade or replace within 180 days of EOL date, or formally accept risk.

Upgrade-in-place is preferred when the new version is drop-in compatible and tested upstream. Major-version upgrades that introduce breaking changes require a migration plan reviewed by the engineering owner.

Replace is preferred when (a) the vendor has unbundled or sunset the product, (b) upstream development has stalled (no release in 18+ months and unresolved security issues), or (c) total cost of ownership of upgrading exceeds replacement.

Accept-and-document is permitted only at the Low tier and only when no fix is feasible within the review window. The exception must be reviewed quarterly until closed.

6. Documentation Requirements

Every EOL action is logged in the engineering log with:

  • Component, version, EOL date, action taken, action date.
  • For upgrades: PR number, diff summary, smoke-test result.
  • For replacements: comparison of replaced and replacement components, migration steps, deprecation timeline for the old code.
  • For accepted risk: compensating controls, residual-risk rationale, review date.

For components touching LP data or banking flows, the log entry also lists which audit events (AuditEvent.action) were affected so future LP due diligence can trace the change.

7. Inventory Refresh

The engineering owner runs a full inventory refresh every six months. The refresh produces:

  • A list of every direct and transitive dependency with current version and known EOL date.
  • A list of platform/service vendors with their current support level.
  • A list of language runtimes and database versions with their EOL dates.

The inventory is committed to the repository at docs/policies/eol-inventory.md (created during the first refresh).

8. Browser Support

The investor portal and admin app support evergreen versions of Chrome, Edge, Safari, and Firefox. We do not commit to supporting browsers that have themselves reached EOL or that no longer receive security updates from their vendors. The list of supported browsers is reviewed annually as part of this policy review.

9. Roles and Responsibilities

  • Engineering owner: maintains the inventory, monitors detection feeds, executes upgrade/replace actions, files exceptions, runs the six-month refresh.
  • Fund manager: receives the quarterly summary, signs off on accepted-risk exceptions, approves replacement of any vendor critical to LP-facing functionality.

10. Reporting

A quarterly summary is produced jointly with the Patch SLA quarterly summary and covers: components reaching EOL in the next 12 months, completed actions in the prior quarter, open exceptions with review dates, and any SLA breaches.

11. Policy Review

Reviewed annually. Material changes require fund manager approval. The change history below is updated with each material revision.

Change history

  • 2026-05-27 — Initial version (v1.0). Authored alongside Plaid attestation work; pairs with the Patch SLA Policy.